00:45:12 <PrivacyNinja[m]> Greetings,
01:08:01 * Isthmus waves at @PrivacyNinja[m]
01:09:31 <PrivacyNinja[m]> Oh, thats mostly IRC proxy right ?
01:11:40 <PrivacyNinja[m]> https://www.monerujo.io/recources/crazy_secure_passphrase.pdf, my android's GUI died, but able to adb shell to get  into the console of the phone via twrp recovery. I suppose the whole android keystore system should be intant correct?
01:12:00 <PrivacyNinja[m]> I got files, tried restorting on other phone, then just realized about this amazing crazypass thingy )
02:35:39 <PrivacyNinja[m]> Since, i also made full backup of the old device, along with - /data/misc/keystore/user_0 (where  10112_USRCERT_MonerujoRSA and 10112_USRPKEY_MonerujoRSA is located).. and copy of /data/media/0/monerujo with 3 files (main main.address.txt main.keys)
06:39:14 <endogenic> koe hmu
07:42:53 <koe> endogenic email me ukoe⊙pc (don't pay for irccloud any more)
08:03:20 <koe> it sounded like within an input's mixin duplicates are disallowed by the standard output selection algorithm; are duplicates allowed between different rings of the same transaction?
08:13:35 <koe> nvm will put to stackexchange
09:43:26 <moneromooo> Yes.
09:58:27 <PrivacyNinja[m]> moneromooo: You sound like you know what you taking about, any thoughts on my crazypass idea ? )
09:58:40 <PrivacyNinja[m]> I mean on my crazypass issue.
09:59:33 <koe> can you help dear moneromooo by clearly describing the issue?
10:00:36 <PrivacyNinja[m]> Oh, sure thing.
10:00:40 <koe> and actually your reddit post is probably enough
10:00:42 <PrivacyNinja[m]> I actually have it whooole written
10:00:44 <PrivacyNinja[m]> down )
10:00:58 <PrivacyNinja[m]> Yea, I thought i would point him out to the reddit page
10:00:59 <PrivacyNinja[m]> a bit )
10:01:03 <koe> this irc channel not a great place; #monero-dev better
10:01:05 <PrivacyNinja[m]> incase he has some thoughts on it :p
10:01:15 <PrivacyNinja[m]> oh, apoligies.
10:01:30 <PrivacyNinja[m]> probbably not reddit either,
10:01:35 <PrivacyNinja[m]> github issue would of been better
10:01:35 <PrivacyNinja[m]> ))
10:01:41 <koe> yeah
10:02:24 <PrivacyNinja[m]> I can't it do it twice now, ( Yea, was bit stressfull last 48 hours )
10:02:29 <PrivacyNinja[m]> so havent really thought it all tru
10:07:08 <koe> afaik monerujo is not related to moneromooo anyway ^.^
10:08:04 <PrivacyNinja[m]> ah right, he's monero world guy
10:08:05 <PrivacyNinja[m]> right ?
10:08:41 <PrivacyNinja[m]> Actually, no.
10:08:50 <PrivacyNinja[m]> Probabbly not, cause of mistaken identitty
10:08:51 <PrivacyNinja[m]> )
10:08:58 <PrivacyNinja[m]> Happens to brightest of us
10:09:05 <koe> I see
10:16:33 <moneromooo> I have no idea.
10:18:06 <PrivacyNinja[m]> Yeah, There probably are just handful guys who actually know without doing the research/reading the code. For some reason i mistaken you that you worked on monerujo code, espcially the crazypass function.
10:19:51 <PrivacyNinja[m]> Whole whitepaper thingy about crazypass was written by m2049r, as it was most of the app's code i guess )
10:20:08 <PrivacyNinja[m]> Hope will catch his attention.
10:20:09 <PrivacyNinja[m]> Thanks, no worries.
17:04:10 <suraeNoether> sarang, i have a few comments about triptych multi
17:04:13 <suraeNoether> and a request
17:04:19 <suraeNoether> sending by PM
17:25:36 <sarang> Thanks suraeNoether; I'm still working through your IACR version suggestions
18:13:57 * Isthmus waves at MRL
18:14:04 <Isthmus> Research day!
18:14:09 <sarang> hello Isthmus
18:15:12 <Isthmus> What're thoughts around plugging info leaks from high-precision fees?
18:15:12 <Isthmus> https://github.com/monero-project/monero/issues/5711
18:15:18 <Isthmus> Maybe something to discuss at next MRL meeting
18:16:01 <moneromooo> If you really want to out yourself, there are plenty of ways we can't fix.
18:16:15 <Isthmus> True, it's just our job to stop the ones we can :- )
18:16:22 <moneromooo> I think we should first know why those people are using those fes.
18:16:37 <moneromooo> I dunno. I'd stop the ones that are our fault.
18:16:39 <sarang> This was discussed a while back too
18:16:40 <sarang> IIRC
18:17:13 <Isthmus> We discussed it briefly a few months ago, but it was too close to the code freeze so we tabled it to circle back
18:17:25 <sarang> I think it's good to discuss
18:18:35 <sarang> Definitely bring it up at Wednesday's meeting, Isthmus
18:18:43 <Isthmus> 👍
18:19:38 <Isthmus> Two apparent reasons are fee sniping (paying 1.1x standard fee to jump ahead of the core software usesrs without paying up to the next fee tier) and some odd implementations that have hardcoded fixed round numbers (0.002500000 XMR)
18:20:40 <Isthmus> Eyeballing, those two account for ~80% of the weird fees, and can both be mitigated (e.g. by coarser resolution)
18:24:29 <Isthmus> Also, other privacy coins have the same information leak and need to patch it. It'd be cool if Monero was leading the pack on that anti-heuristic design feature.
18:26:08 <moneromooo> It's sad. I find myself close to not caring anymore.
18:26:38 <moneromooo> People will just find all sorts of ways to make things worse for others for just a tiny benefit to themselves.
18:26:49 <moneromooo> Sometimes not even measurable.
18:40:10 * Isthmus offers mooo a hug. 
18:40:13 <Isthmus> Let's not allow 2020 be the year that the R&D team for the world's leading privacy coin gets burned out and gives up.
18:43:56 <moneromooo> I'd understand laziness. But here, it's actual effort expended to make things worse.
18:45:04 <Isthmus> It's natural to feel defeatist when we're perpetually plauged by 3% of users that will somehow stick out despite some privacy feature (e.g. coarse fees). :- /
18:45:09 <Isthmus> I try to remind myself to focus on the 97% of people that we *can* keep safe, who have no clue that their exchange's home-rolled software or phone wallet is [probably unintentionally] marking their transactions.
18:45:14 <Isthmus> But it's definitely frustrating.
18:45:28 <nioc> it is not for you to finish the task but neither are we allowed to lay it down
19:11:01 <endogenic> i figure it's part of the very game of cryptocurrencies that people are trying the break them
19:14:40 <moneromooo> That's not even trying to break them. That's the equivalent of pissing over a wall because you didn't even care there could be others below.
19:15:40 <moneromooo> Now, if you knew there were others and that was the point, then fair enough.
19:16:04 <moneromooo> At least you used your brain.
19:16:30 * moneromooo should probably not use irc again till tomorrow
19:19:28 <endogenic> so just to confirm i understood, this is people sniping to get into blocks rather than them using their own fee code which could be mitigated by factorization?
19:20:57 <endogenic> fingerprintability is definitely mitigated by shared client code
19:21:29 <endogenic> the fee code is trivial to extract too, fwiw. mymonero-core-cpp has it pulled our
19:21:31 <endogenic> our
19:21:33 <endogenic> out
19:33:30 <endogenic> i looked up etymology of "pissing over/on a wall".. after getting past the pornhub results, a bible reference explanation made a point of saying only guys can do so.. i guess that puts them in a fungibility puddle ?
19:43:36 <Isthmus> Yeah @endogenic, I think they're calculating the standard fee, then tweaking it up by a hair
19:43:38 <Isthmus> https://usercontent.irccloud-cdn.com/file/EAQmqJJi/image.png
19:44:45 <Isthmus> Sure it's a greedy maneuver, but to be fair, probably most or all of its practitioners don't realize the privacy implications
19:45:06 <Isthmus> It definitely wasn't on my radar until 2019
19:46:52 <Isthmus> Likewise for people coding fixed absolute fee (e.g. 0.002 XMR) or fixed fee per weight (e.g. 0.01 XMR / kB).
19:46:53 <Isthmus> An exchange dev might have thought it was the correct decision to harcode a fixed fee to push through their users' transactions rather than working with a more complex dynamic algorithm that may be intimidating in a high-stakes production environment.
19:48:06 <moneromooo> You don't even have to do anything. The wallet will do it for you.
19:54:05 <smooth> one potential mitigation of fee sniping would be for the standard wallet to randomize fees a bit
19:54:33 <endogenic> fmpov tech, product interfaces shouldnt allow people to do things that mess up the state or violate assumptions.. i figure randomization could be easy to fake .. sniping could still happen and skew the distribution
19:54:49 <endogenic> but im not sure if consensus to fix fees in brackets makes sense.. *backs out of room slowly*
19:56:07 <smooth> not sure what you mean by 'fake' randomization. yes sniping would skew the distribution but thats probably less bad than the status quo. probably
19:57:10 <moneromooo> People would just cancel and try again. I think Isthmus' suggestion is the best, though it'll likely need to be careful not to break the smooth curves vs block size.
19:57:37 <smooth> most people would not cancel and try again for a tiny amount of fee randomziation
19:57:53 <smooth> the existing fees are mostly arbitrary already, and most people dont care
19:58:32 <endogenic> smooth what i meant was not easy or possible to detect randomization on verification side
19:58:42 <smooth> yes i agree
20:00:34 <Isthmus> If I'm a fee sniper currently, I already have custom software that takes the default fee D and adds some extra amount E.
20:00:36 <Isthmus>  If randomness was added in the core wallet, then I'd just change one line of code and broadcast my transactions with D + E + max_randomness.
20:00:59 <smooth> you probably wouldn't
20:01:03 <moneromooo> Most no, but probably a large portion of those people Isthmus pointed to would.
20:01:25 <smooth> well, max randomness is wasteful right?
20:01:39 <smooth> you could get away with a bit less and still be ahead of the crowd, and cheaper
20:01:54 <Isthmus> Depends on whether your priority is speed or savings
20:02:14 <Isthmus> And your tolerance for the occasional transaction getting stuck for a few blocks
20:02:19 <smooth> your priority ois clearly both otherwise you wouldn't be doing this
20:02:42 <smooth> if you want to be 100% sure of not getting stuck you woudln't snipe, you would add a healthy margin
20:03:06 <smooth> snipe = optimize for both cost and time
20:03:07 <Isthmus> Yes, so the fee snipers today must have some tolerance for the occasional transaction delay.
20:03:37 <moneromooo> Having hard fee levels will also mean you can't make a tx and broadcast it more than a few minutes later, or the block size might have changed, making your fee a non multiple of the "correct" fee.
20:03:48 <smooth> IMO fixed fees are ultimately non-viable. we should really expect to abandon it eventually
20:03:52 <moneromooo> Doesn't matter now, but would when bllocks are > 300000.
20:04:08 <smooth> helpful mitigations are okay, but lets not double down on serious effort to preserve the doomed concept
20:04:30 <Isthmus> Discrete fee would need to be applied to absolute fee *not* relative fee
20:04:53 <smooth> once there is a serious fee market, you won't be able to read anything from fees except the urgency of the sender, which is inherent (can't be removed)
20:04:55 <moneromooo> If you do that, doesn't it fuck up the dynamic block sizing algorithm ?
20:05:13 <Isthmus> The dynamic block size algorithm is *designed* to work with 4 discrete fees
20:05:15 <moneromooo> Unless you always highball it I guess. But then it'll be expensive for all
20:05:22 <Isthmus> If it's being held together by the few people being outliers, then we have bigger issues :- P
20:05:51 <Isthmus> I would definitely want to hear @ArticMine's input
20:05:51 <moneromooo> It's designed to work with 4 variable fees.
20:07:10 <Isthmus> That's true, but I think as long as the fee bins are on the order of the spacing of the dynamic fees, the same properties carry
20:07:34 <Isthmus> The risk of delayed broadcast causing fee to be below other txns in the mempool is the case whether continuous or discrete fees
20:09:41 <smooth> discrete fees are bad. they will cause higher volume transactors and potentially wallet developers to make deals with pools to get their transactions prioritized independent of fee, which will then also be detectable
20:10:01 <smooth> (by transactions which don't 'belong' in the block on account of fees, but end up there anyway)
20:10:30 <smooth> also is centralizing
20:12:50 <Isthmus> In that case,🤔 we should start considering other ways to mitigate this
20:13:06 <gingeropolous> randomized fees can't be enforced. I don't see how anything unenforced can stop outliers. stupidexchange X will still just use 0.2 xmr per tx because mah speed
20:13:18 <smooth> yes, you can't fix stupid
20:13:38 <smooth> you can mitigate against the intelligent behavior being harmful though
20:14:41 <Isthmus> We gotta watch out for slippery slope, lol.
20:14:42 <Isthmus> Why bother building seatbelts when there will always be *somebody* who won't buckle up? :- /
20:14:44 <smooth> one way would be to introduce a measure of fee sniping into the standard algorithm, thereby removing its advantaage. but that's complicated. small degree of randomization is easy
20:14:46 <gingeropolous> why are fixed fees nonviable? because the blockchain isn't aware of value?
20:15:19 <smooth> because of side deals with miners/pools
20:15:25 <gingeropolous> ah
20:15:27 <endogenic> is tx extra of constant size now btw?
20:15:29 <smooth> as i said above
20:15:33 <moneromooo> No.
20:16:45 <smooth> to expand a bit, the response of the standard algorithm currently is to increase fee by some big jump (2x or 4x was it?)
20:16:56 <smooth> it should be obvious that people will find that unattractive and seek ways to bypass it
20:17:19 <smooth> the root cause of this is the standard algorithm doing something people find worthy of bypassing
20:17:55 <Isthmus> Side deals with miners/pools are already an option, and make rational sense for anybody who makes frequent transactions and has an in-house mining algorithm
20:18:11 <Isthmus> We might incentivize it slightly more, but it's not like we'd be opening that up as a new attack surface
20:18:44 <Isthmus> "the root cause of this is the standard algorithm doing something people find worthy of bypassing" << interesting point
20:19:21 <Isthmus> I think right now it's:
20:19:25 <Isthmus> Slow = 0.25x
20:19:29 <Isthmus> Normal = 1x
20:19:31 <Isthmus> Fast = 5x
20:19:36 <Isthmus> Fastest = 41.5x
20:19:55 <Isthmus> So maybe what we're getting signal on from users is that they desire more intermediate levels
20:20:13 <moneromooo> They desire no fees at all.
20:20:41 <gingeropolous> which is also possible.... or wait, was min fee made part of block consensus? or is it still just relay?
20:21:41 <smooth> Isthmus: incentivizing it is the attack surface. Right now there is NO incentive for side deals. whatever you would pay to the miner as a side deal you can add as a small fee sniping increment and get the benefit of all miners accepting your txs
20:22:13 <smooth> But yes, the signal we are getting (I'm ignoring the purely stupid ones, as I don't think they are signalling) is that users dont want discrete fees
20:22:22 <selsta> I have not read a single complaint about about fees since BPs
20:22:39 <smooth> selsta: from the observed behavior
20:23:15 <moneromooo> OTOH it could be software made a while back that's working so no need to change it from their pov.
20:23:38 <smooth> also possible, even likely (given price decline, etc.)
20:23:57 <smooth> but then these same issues would likely return in the future if/when blocks fill up and/or the price goes up
20:27:03 <Isthmus> There may or may not be side deals between *different* parties right now, but for companies like exchanges that have mining *in-house*, I think it's probably already rational to use that block space to mine transactions with lower fees than market.
20:29:34 <gingeropolous> agreed. which isn't good. this will create institutional fingerprints and non-institutional fingerprints
20:31:01 <Isthmus> At least "this transaction was mined too early considering what was in the mempool at the time" requires analyzing the blocks against memory pool activity archives with sub-block resolution
20:31:56 <Isthmus> Which is already a more complex analysis and less provable link than just leaving ridiculous fees straight on the chain
20:32:29 <Isthmus> And there's plausible deniability... Was it "mined too early" or did the miner receive and include the low-fee transaction before receiving higher-fee transactions
20:32:37 <Isthmus> Since mempool is not global or provable
20:33:14 <gingeropolous> im more concerned it will evolve to "institution x uses y fee, institutional n uses m fee"
20:33:26 <Isthmus> That's exactly what we have right now
20:33:40 <Isthmus> I just haven't done the deanonymizing back to exchange identities
20:34:09 <gingeropolous> i mean, is it worth revisiting fees? they're primary purpose is to prevent spam. secondary is to create a priority system. tertiary (for monero at least) is mining incentive.
20:36:41 <moneromooo> And to allow the block size to grow.
20:42:20 <gingeropolous> well u know me. i always think PoW is the answer. here, just use PoW with min diff requirements for publishing a transaction to the network. dunno how the rest of the function of fees would work out, but its almost enforcable randomness for data that gets published.
20:46:10 <moneromooo> Well, the fee only goes to the miner anyway, so I suppose we could make feeless txes and have pay-for-service to miners. But then you'd get designated miners, which is likely brittle.
20:46:31 <moneromooo> And degradres privacy.
20:51:21 <gingeropolous> yeah i guess that disincentives any tx inclusion at all don't it
20:51:38 <gingeropolous> disincentivizes
22:15:16 <smooth> Isthmus: 'this transaction was mined early' doesn't require analyzing the real time mempool, although that could help. But it can be visible from other transactions in blocks
22:18:21 <Isthmus> Yes, it can be inferred but not proven (you'd have to make assumptions about what the miner's mempool contained at the time of the block)
22:18:41 <smooth> Well, nothing can be proven really
22:19:06 <smooth> Some idiot uses 0.05 as the tx fee. But when you see a tx doing that, it could be ANOTHER idiot doing the same thing
22:19:23 <smooth> But it is an inference. It's all inferences pretty much
22:22:08 <Isthmus> Yeah.
22:22:10 <Isthmus> I think of transaction graph matching as a giant inference problem.
22:23:40 <Isthmus> Just gotta work incrementally and chip away at information leaks that give the matching algorithm traction for linking transactions or sets of transactions.
22:29:07 <smooth> Maybe disentangle the issue of fee sniping from stupid fees. I feel they are quite different.
22:29:30 <smooth> Stupid fees could be addressed by not relaying anything outside of a plausoble range constructed from the last 24 hours of blocks.
22:29:59 <smooth> People using stupid fees might find their txs no longer propagate and stop doing it
22:30:07 <Isthmus> Good idea to separate sniping from stupid
22:30:22 <smooth> After all there is a real feature that pretty much does exactly what they want (specify elevated priority)
22:30:38 <smooth> They just need an incentive to use it instead of what they are doing now which still works
22:31:21 <smooth> Or alternately change the specification of priority to something like N blocks the way bitcoin wallets do
22:31:32 * Isthmus taps chin and ponders
22:31:45 <smooth> "I want my tx in the next block if possible" is pretty much what we call higher priority now
22:32:29 <smooth> Lower priority is "hopefuly some time in the next N blocks"
22:42:27 <Isthmus> "Stupid fees could be addressed by not relaying anything outside of a plausoble range constructed from the last 24 hours of blocks."
22:42:29 <Isthmus> ^^ Interesting idea, and I think I have an idea for how this could be formalized and implemented.
22:42:41 <Isthmus> Let F(H,P) be the fee in XMR/kB from the official dynamic algorithm at height H with priority P (1,2,3,4). This is a completely deterministic function of height, right?
22:42:51 <Isthmus> We pick some heigt window W (e.g. 24 hr, then W = 720). Each node can just keep a rolling buffer with W*(number of priority level) elements and keep track of the allowed fee/weight values over the desired timeframe.
22:44:52 <Isthmus> This would not stop fee sniping (unless the fees were ~monotonically decreasing over W) but would block the super obvious outliers
22:46:48 <Isthmus> Oh and interestingly, fee sniping would be constrained by the volatility over W
22:47:36 <Isthmus> Woah, it would disguise fee sniping as delayed broadcast xD
22:48:12 <Isthmus> (well, depending on ages of ring members)
22:51:33 <smooth> Isthmus: yes the fee algorithm is determinisitic. i'll have some more comments later
22:53:53 <sarang> Brief update: lots of great updates on Triptych today
22:54:11 <sarang> Pretty sure the multi-input version is now sound
22:54:22 <sarang> and therefore we can update the preprint to include it
22:54:30 <sarang> This is great for size and time optimization
22:55:19 <sarang> The single-input preprint is also ready too, but is less interesting :)
22:56:38 <moneromooo> Sounds as in you worked out the proofs for the fast version ?
22:58:24 <sarang> Yeah, we're finalizing that now
22:58:52 <moneromooo> That is most excellent news, congratulations ^_^
22:59:03 <sarang> So we can either post the single-input version now and update later for multi-input, or just jump to multi-input right away
22:59:35 <sarang> Single-input is useful as a multi-input linkable ring signature independently
22:59:56 <sarang> Multi-input is useful for incorporating balance computations and all spends within a single proof
23:00:51 <sarang> IACR archive doesn't clearly show updates, FWIW, only the initial posting (but it keeps all versions available for reference)
23:26:55 <sarang> Based on my earlier analysis, the updated Triptych construction produces transactions 25% smaller than Lelantus (for ring sizes 128 and 1024)
23:27:13 <sarang> For N=128 verification is 11% faster
23:27:31 <sarang> For N=1024 it's 5% slower
23:27:45 <sarang> But it fixes the tracing and one-time addressing issues from Lelantus
23:28:03 <sarang> I'll send the updated version to Aram and see if he has any notes or suggestions
23:28:15 <sarang> (Aram came up with Lelantus)
23:29:03 <sarang> Worth noting that for updated Triptych, you can speed up verification by sacrificing proof size, and vice versa
23:29:11 <sarang> the numbers I shared were for the space-optimized version
23:29:26 <sarang> ^ suraeNoether
23:31:30 <selsta> Does Triptych work with multisig?
23:32:29 <sarang> Yes, using the inversion MPC
23:32:52 <selsta> Cool, are there any problems left to solve?
23:33:13 <selsta> Wasn’t there this thing that every one of new schemes had one problem or so
23:33:16 <sarang> Multisig draft: https://github.com/SarangNoether/skunkworks/blob/inverse-mpc/triptych-aggregate-mpc.md
23:34:14 <sarang> Requires Paillier encryption, which is less convenient
23:34:46 <sarang> or some equivalently-functional homomorphic public-key construction
23:35:44 <selsta> Convenient as in?
23:35:54 * selsta trying to understand :D
23:36:28 <sarang> It requires many-to-many communication, more general crypto requirements