17:01:40 _UkoeHB> MRL meeting time (https://github.com/monero-project/meta/issues/621)
17:01:40 _UkoeHB> 1. greetings
17:01:40 _UkoeHB> hi
17:02:00 _isthmus> Salutations
17:02:03 _rbrunner> hello
17:02:10 _jberman[m]> hiya
17:02:11 _Rucknium[m]> Hello
17:02:19 _h4sh3d> Hi
17:02:19 _carrington[m]> I guess I didn't mean completely deterministic. Just that the distribution amongst bins would be deterministic
17:02:26 _carrington[m]> Hello
17:04:56 _SerHack> Hi
17:06:24 _UkoeHB> Today I'd like to nail down ring size for next hard fork, since it is... a blocker for next hard fork. I like 15 (less than 50% rise in input size/verification costs), or 17 (aesthetics: prime number).
17:06:28 _dartian[m]> Salutations
17:06:35 _UkoeHB> This is agenda item 2.
17:07:01 _carrington[m]> Regarding ringsize increase, I think 16 is the way to go unless binning is implemented in the next upgrade in which case it should be 22
17:07:40 _UkoeHB> Reasoning?
17:07:50 _jberman[m]> In last dev meeting we discussed going with a number that would smooth the binning implementation so no remainder in a bin
17:08:08 _carrington[m]> There was discussion about binning with two outputs from each bin, so 22 gives you a bin for each current output
17:08:22 _jberman[m]> 22 was tossed as ideal since it maintains the current gamma selection + yields the benefit of binning
17:08:27 _carrington[m]> A number with many factors basically was said to be good for binning options
17:08:29 _jberman[m]> when you have 11 bins + 2 members per bin
17:08:48 _UkoeHB> Ok, jberman[m] can you update us on status of binning proposal?
17:09:08 _carrington[m]> I have not yet had time to look over the binning PoC
17:09:09 _Halver[m]> hello
17:09:30 _jberman[m]> I found a flaw yesterday in my proposed wallet-side binning algorithm that is fixable: basically trying to randomly select an output from a block in the final step for each output can cause a situation where an output is guaranteed to be a decoy
17:09:40 _isthmus> Good catch
17:09:44 _jberman[m]> Working on the fix
17:10:35 _jberman[m]> the reason it randomly selects an output from a block in the final step is to mitigate a miner re-ordering a block to their advantage (e.g. ordering a bunch of outputs into a bin)
17:10:55 _carrington[m]> Articmine also stated that if ringsize goes beyond 24 with CLSAG, there would need to be some changes to the dynamic block size system
17:11:42 _Rucknium[m]> From a decision making point of view, isn't it the case that the exact state of the binning PoC isn't too important, as long as we believe that there are not fatal flaws with binning as a concept?
17:12:19 _UkoeHB> Yes that's true, my brain is still warming up on this subject.
17:12:25 _Rucknium[m]> One scenario: We go to an even number of ring size in the next hard fork. Then, later, binning is released in a new wallet release -- it requires no hardfork.
17:13:10 _rbrunner> Log of the dev meeting in question is here, btw: https://github.com/monero-project/meta/issues/614#issuecomment-933010683
17:13:18 _isthmus> There aren't many even primes :/
17:13:29 _gingeropolous> hrm, but doesn't that also get into the whole enforcing of ring member selection thing.
17:13:36 _gingeropolous> u could end up with wallets that bin and those that don't
17:13:41 UkoeHB> We have hard from: UkoeHB, carrington[m], jberman[m] about ring sizes. Does anyone else have things they want to say? sgp ?
17:13:57 _gingeropolous> ringsize a bajillion
17:14:37 _jberman[m]> A switch to binning in the wallet is guaranteed to cause rings to have a clear different distribution of rings from older rings, so it would be nice to have it in place for a hardfork to try and get as many people as possible using the updated algorithm, though not strictly necessary
17:14:55 sgp> hi. nothing changes from me; I still recommend 16-17 absent binning
17:15:21 _Rucknium[m]> gingeropolous: Yes, that would almost 100% happen -- or a least there would be a lag as other wallet implementations adopt it.
17:15:34 _UkoeHB> To be clear: an increase from 11 to 22 ring size will double per-input size/verification costs.
17:15:37 _selsta> 16-17 seems good to me too, I would rather not go too high due to verification time
17:16:15 _Rucknium[m]> My not-completely-thought-out suggestion is ring size 16 since it would allow 2-output bins later.
17:16:37 _rbrunner> Well, if there is a later 🙂
17:16:49 _wfaressuissia> Hello
17:16:50 sgp> with binning would be 8x2, seems reasonably acceptable but a little low
17:16:56 _rbrunner> Or better said, another hardfork between the coming one and Seraphis ...
17:17:22 _carrington[m]> Whether 8 2-ouput bins is better than 4 4-output bins, I'm not so sure
17:18:16 Rucknium[m]> sgp: I agree with "seems low". I would want a substantial overhaul of the decoy selection algorithm to be in place before or at the same time as 8x2 binning.
17:18:38 _gingeropolous> i like 22 mainly because its the largest number that seems acceptable at this time, and allows for simple binning that seems acceptable by all
17:18:44 _atomfried[m]> with BP+ how much bigger would a 16-17 ring tx be compared to a current one?
17:19:31 sgp> 22 is quite large but indeed has no downside compared to current with binning turned on
17:19:34 _Rucknium[m]> gingeropolous: If 22 is feasible, that would be nice. It seems to be outside of the range that people have typically thrown around, however.
17:20:17 sgp> the highest I realistically want to go is 18
17:21:47 _selsta> vtnerd wanted to add ASM speedup for syncing
17:21:50 _gingeropolous> its literally been 3 years since ringsize 11 enforced. tech has advanced since then to accommodate.
17:21:52 _carrington[m]> Doesn't BP+ lower txn size by a flat 96 bytes?
17:22:03 _selsta> with that added, it might allow for a bit higher ring sizes, depending on the speedup
17:22:41 sgp> yeah tech hasn't advanced 100% though :p
17:22:44 _UkoeHB> Let's look at just 16 vs 22.
17:22:44 _UkoeHB> 16: conservative, avoid 2xing size/verification costs per-input
17:22:44 _UkoeHB> 22: optimistic about binning
17:23:17 _gingeropolous> 22: also puts the gas on the pedal for seraphis
17:23:24 _isthmus> (and 22 = more statistical noise to lower the power of heuristic analyses intended to deanonymize ring signatures)
17:23:26 _gingeropolous> wait i messed up that metaphor
17:23:34 _UkoeHB> lol
17:23:38 _isthmus> haha
17:24:08 _jberman[m]> _carrington[m]> "Whether 8 2-ouput bins is better..." _- the Moser paper recommends bin sizes of 2, but need to review the math a bit deeper. their reasoning is basically that bins of size 2 provide mitigation for the worst of any potential problems with pure gamma selection, while still allowing for many gamma-selected outputs in the ring
17:24:38 _UkoeHB> In my view, the pattern/precedent of conservative design choices in Monero favors 16 over 22.
17:24:43 _carrington[m]> So... 18 is the happy medium? Also allows bin sizes of 3
17:24:52 _gingeropolous> ah ha, there's the compromise. 16 now, but include in code that ringsize grows by 2 every year for some n years
17:24:55 sgp> just to ground everyone in reality, most of the targeted heuristics don't care about ringsize 11 v 22. It doesn't make those twice as hard
17:25:49 sgp> I'm by no means a "small ringsize-r", but going for 22 only makes sense to me if we want to do 11x2 binning
17:25:50 _carrington[m]> Automatic ringsize increase sounds unnecessarily complicated
17:26:12 _gingeropolous> re: sgp, does that include binning bonuses?
17:26:13 _carrington[m]> As presumably the decoy selection would need to change at the same time
17:26:25 _rbrunner> And one would really hope that a next-gen protocols is not several years out
17:27:16 sgp> gingeropolous: probably, if you assume 2+ poisioned outputs
17:27:49 _gingeropolous> i just dunno if the heuristics have been done against binning
17:28:56 _UkoeHB> Once again, I feel us going in circles on this subject.
17:29:00 sgp> we're getting off topic, but that's not the relevant test at play here for 2+ poisoned outputs
17:29:18 _gingeropolous> yep. im fine with 16,17,22. anything >11 is fine
17:29:36 _rbrunner> The dev meeting participants seemed to grativate towards 16, so ...
17:29:46 _rbrunner> gravitate
17:29:57 _carrington[m]> Maybe we file this question under "awaiting more binning research"
17:30:03 sgp> I'm good with 16
17:30:13 _gingeropolous> nah, one of the goals is to nail down a number
17:30:17 _gingeropolous> no more can kicking
17:30:30 _h4sh3d> seems like no one is against 16 so...
17:30:41 _UkoeHB> Imo if binning were to be enforced by consensus, then the case for 22 would be stronger.
17:31:08 sgp> 11 -> 16 is the largest increase ever (not by % obv)
17:31:45 _UkoeHB> Ok how about tentatively 16 ring size for next hf. Any objections? We can revisit this again if anyone wants to before go-live.
17:32:11 _isthmus> 👍
17:32:23 _gingeropolous> ^
17:32:23 sgp> no objections
17:32:27 _wfaressuissia> "Once again, I feel us going in circles on this subject." right, especially considering undelivered triptych with 100+
17:32:31 _jberman[m]> none from me
17:32:47 _isthmus> Well, except the fact that it's not prime :- P
17:32:52 _gingeropolous> ^^
17:32:53 * isthmus is superstitious
17:33:01 _UkoeHB> isthmus: at least it's a power of 2!
17:33:15 _h4sh3d> power of 2 and prime would be good :p
17:33:41 _rbrunner> 16 will probably make also possible nice displays in block explorers and such
17:34:15 _UkoeHB> Let's move on to other agenda items. This part is open-ended.
17:35:22 _rbrunner> I have a question regarding Seraphis that may be of common interest and also came up recently on Reddit:
17:35:22 _UkoeHB> I'll just add my update for the log: yesterday I ran the first performance tests for one design variant of my Seraphis PoC. As expected, it is similar in verification cost to Triptych, and smaller size scaling on inputs.
17:36:20 _rbrunner> If I understand correctly Seraphis has the potential to offer better view-only wallets, even in more than 1 variant
17:36:27 _rbrunner> The Seraphis draft whitepaper seems to speak about "design choices" regarding this
17:36:34 _rbrunner> Does this mean we can freely choose among several possibilities, as a community, and the "loose consensus" can get implemented?
17:37:02 _UkoeHB> Yes the consensus can be implemented
17:37:18 _isthmus> Sounds good to me
17:37:27 _UkoeHB> Technically addressing are all 'conventions', not enforced by consensus.
17:37:40 _UkoeHB> addressing schemes
17:38:18 _rbrunner> Do addresses change in length depending on the choice of the "power" of view-only wallets?
17:38:26 _UkoeHB> Yes
17:38:38 _UkoeHB> Some variants require 3 key addresses
17:39:00 _rbrunner> What must be result in a new record length for all coins 🙂
17:39:50 _isthmus> I'm intrigued. I think that the limits on our current view key system really lower the practical utility
17:40:24 _h4sh3d> Does 2 key addresses remain compatible?
17:42:24 _UkoeHB> here is a summary of address schemes https://usercontent.irccloud-cdn.com/file/fhZ3XPcM/seraphis_address_schemes_4.png
17:42:35 _UkoeHB> h4sh3d: no there is no variant that remains compatible
17:44:03 _rbrunner> Very interesting. Is that from a text that also explains what a "tier" is?
17:44:34 _UkoeHB> no it's just a summary; I just call a 'tier' a different level of authority
17:44:55 _isthmus> I like Janus A
17:45:36 _rbrunner> Depending on how many private keys one holds?
17:45:44 _isthmus> I like Janus A
17:45:49 _UkoeHB> rbrunner: more or less
17:45:52 _isthmus> oops sorry for the dupe, connectivity issues
17:46:33 _rbrunner> I see
17:46:40 sgp> what does Janus mean if it's in the table under a tier?
17:46:48 _UkoeHB> you can check section 4.6.2 in the seraphis draft paper
17:47:00 UkoeHB> sgp: you can detect janus attacks with that tier
17:47:16 _isthmus> I think there's value in having view received and view spent separately
17:47:16 _isthmus> In the case of a charity that publishes their view key, it might be better to just share the show received, since it's undesirable to publicly reveal a large number of spends
17:47:16 _isthmus> But for a company running audits on internal wallets, having view spend is desirable
17:48:18 _UkoeHB> isthmus: the problem is you can usually detect spends by looking at change outputs
17:48:32 _rbrunner> "Plain B" looks interesting because it does not yet seem to require a third key
17:48:37 _UkoeHB> so it is of questionable utility to separate the tiers
17:48:59 _UkoeHB> separate the capabilities*
17:49:05 sgp> Janus A seems the best then. Janus B would be cool for minimizing info known to lightweight wallets, but not being able to observe Janus is a downside
17:49:18 _UkoeHB> However, if ring size is expanded to 'all the outputs', then the distinction can be useful.
17:49:28 _isthmus> Well, my accounting department isn't going to want to heuristically infer spends from change outputs :- P
17:49:34 _isthmus> But yea, that is a bummer for the charity use case
17:50:18 sgp> even so, the distinction is useful from an auditability perspective
17:50:59 sgp> using key images to confirm guesses is terrible UX
17:51:01 _isthmus> Yea, with Monero's current setup, the ONLY way for accounting to get a full view of wallet activity is if they have access to sensitive keys
17:51:08 _UkoeHB> To be clear: a tier 2 wallet has all the capabilities of a tier 1 wallet
17:51:23 _isthmus> Whereas with e.g. Janus A, they could have a full dashboard to monitor all wallet activities, without ever needing access to a sensitive key
17:51:25 _isthmus> Which is sweet
17:51:37 _isthmus> (from a secure systems design perspective)
17:51:41 _carrington[m]> Couldn't change outputs be sent to a different subaddress? That way, you couldn't infer the full flow of funds with a "view incoming" key for a specific address
17:52:10 _carrington[m]> Maybe a bit convoluted, and possibly completely wrong
17:52:19 _isthmus> 🤔
17:52:23 _moneromooo> Apologies if this was said, I just popped in, but why does plain B have three distinct tiers with only two keys ?
17:52:25 _UkoeHB> isthmus: you get the same thing with all the other variants except Plain A
17:52:32 _isthmus> Yea
17:52:49 _rbrunner> Aren't keys address-independent?
17:52:53 _isthmus> They're all improvements over Plain A
17:53:21 _UkoeHB> moneromooo: there are actually 3 private keys in Plain B, but only 2 public keys in the address
17:53:34 _rbrunner> Sounds quite clever
17:53:39 _moneromooo> Thanks
17:54:17 _rbrunner> So it seems we can start discussion and let any future hardfork to Seraphis come nearer in a relaxed way because the design can be finalized quite quickly
17:54:38 _UkoeHB> I suppose so
17:54:51 _jberman[m]> "Janus" types wouldn't leave an additional 16 bytes of data on chain, but require larger addresses in order to protect against Janus?
17:55:00 _UkoeHB> jberman[m]: correct
17:55:36 _UkoeHB> Even if you use 16 bytes to mitigate janus, the janus address variants still need 3 keys to get the more versatile permissions
17:55:45 sgp> how long we talking
17:56:04 _isthmus> It would be a kind of cool UI feature if I could export / import the view keys as mnemonic word lists
17:56:27 _jberman[m]> got it
17:56:35 UkoeHB> sgp: until what?
17:57:13 sgp> long in size, 50% longer?
17:57:31 _UkoeHB> yes the Janus variants would be 50% longer
17:58:01 _UkoeHB> One last minute question: is anyone working on Drijvers attack mitigation? wfaressuissia ?
17:58:29 _carrington[m]> Longer addresses are better than more data on chain
17:58:57 _h4sh3d> UkoeHB: I had a look at your technical note. Was surprised to not see reference to MuSig2 work, is it intentional?
17:59:17 _wfaressuissia> yes
17:59:31 _UkoeHB> h4sh3d: I did not read that paper
17:59:45 _UkoeHB> Since I guess the other papers are sufficient
17:59:55 sgp> carrington: agree 100%, quite a minor downside
18:00:14 _h4sh3d> worth having a quick look at 1.3 Concurrent Work then, just to get an idea, https://eprint.iacr.org/2020/1261.pdf
18:01:32 _sethsimmons> Users just copy-paste and verify first and last few characters, so longer addresses don't really matter in any way I can think of, and Monero's addresses are already dauntingly long lol
18:01:34 _h4sh3d> yes FROST cover the same
18:03:28 _UkoeHB> wfaressuissia: great thank you! 🙂
18:03:47 _UkoeHB> Ok we are at the end of the meeting. Let's do another meeting same time next week. Thanks for attending everyone.
18:03:49 _carrington[m]> Worth noting for the logs: Haveno are offering a $2500 bounty for fixing the Wagner/drijvers attack
18:04:17 _isthmus> Productive meeting
18:04:25 _isthmus> I’ve made some progress in a little side project inspired by the transaction volume excess I could share too, but I forgot to add to the agenda
18:05:46 _isthmus> Should I brain dump now or save it for next week's episode? :- P
18:06:21 _carrington[m]> Rucknium are we any closer to reviewers deciding if your hackerone disclosure should be published? Haven't seen mention in a while
18:08:36 _gingeropolous> i guess u should save it for next week isthmus
18:08:43 _carrington[m]> Isthmus I can add that to the top of the next agenda, if you give me a title to hype it up.
