14:58:21 <m-relay> <r​ucknium:monero.social> MRL meeting in this room in 2 hours.
17:01:14 <Rucknium> Meeting time: https://github.com/monero-project/meta/issues/880
17:01:23 <Rucknium> 1) Greetings
17:02:03 <Rucknium> Hi
17:02:07 <isthmus_> Heya
17:02:08 <m-relay> <c​ompdec:matrix.org> hola
17:02:49 <Rucknium> 2) Updates, what is everyone working on?
17:03:06 <isthmus_> Sorry I haven’t been around much. Super busy year, only a few free hours here and there. 
17:03:08 <isthmus_> I’ve been slowly refactoring pieces of the NRL data pipeline, replacing legacy components originally written in haskell and C++. 
17:03:17 <isthmus_> Along the way, running some simple analyses to surface outputs that have shown up in too many rings. The distribution of output references is:
17:03:17 <isthmus_> 25 percentile: 3.0
17:03:17 <isthmus_> 50 percentile: 8.0
17:03:17 <isthmus_> 75 percentile: 11.0
17:03:17 <isthmus_> 90 percentile: 14.0
17:03:17 <isthmus_> 99 percentile: 20.0
17:03:17 <isthmus_> 99.9 percentile: 30.0
17:03:18 <isthmus_> 99.99 percentile: 56.0
17:03:18 <isthmus_> However, there is an output that has been used 11,000+ times! And many that have been used thousands of times.
17:03:37 <isthmus_> Most of these are rings that differ by exactly one element (the true spend), so it makes chainanalysis trivial. I have a different project from last year whose readme contains a more thorough explanation https://pypi.org/project/ringxor/#description
17:03:40 <isthmus_> For a concrete example, here’s the infamous `6d22` ring which always has ring members [6d22…, 0d02…, 7751…, (...), 4fa4…, <true spend>] 
17:03:44 <isthmus_> https://xmrchain.net/search?value=79ba8cd9c8fedaeb1f23cc758235568987776fe6374da6dd28f09884c701cb50 
17:03:50 <isthmus_> Easy to click through true spends and do chain-analysis by eye on xmrchain. Even when you get to multi-input txns, one of them is the 6d22 ring. Individual chains of 6d22 can run several deep, and there are thousands of them. 
17:03:54 <isthmus_> It took 19 minutes on my laptop to process 12,870,955 rings, and identify at least one input with an obvious spend for 820,000 transactions (millions of rings). I’ve shared the list with Ruck, as one way to flag and discard some rings not generated by correct use of wallet2.
17:03:58 <isthmus_> It’s such a massive and frustrating info leak that I started developing a toy method for describing rings without the degrees of freedom necessary to enable catastrophic misuse like above. https://github.com/Mitchellpkt/isthmus_indices_dev/blob/main/demo_notebook.ipynb 
17:04:02 <isthmus_> But that’s a whole other story for another day
17:04:08 <isthmus_> Otherwise I've mostly just been lurking
17:04:23 <Rucknium> Me: Working on forecasting for OSPEAD to evaluate long-term accuracy. Maybe just taking the mean is good enough. Also worked with isthmus to develop another way to explain the dependence between Monero ring members.
17:05:10 <Rucknium> If anyone is disatisfied with the original explanation "Gambler's fallacy except the Gambler is right", then we can make a short write up to explain more.
17:05:34 <vtnerd> hi
17:06:04 <m-relay> <c​ompdec:matrix.org> I'm finishing a draft of my EAE/TDA analysis note.  I was hoping to get a copy out today, but that could be fantasy
17:06:14 <Rucknium> Thanks, isthmus
17:06:18 <vtnerd> not a lot to report for me, Im leaning towards SSL over Noise for p2p and been trying to track a few bugs
17:07:58 <Rucknium> The Curve Trees authors posted the slides from their USENIX talk and I think the version of the paper that will go in the USENIX proceedings: https://www.usenix.org/conference/usenixsecurity23/presentation/campanelli
17:08:33 <Rucknium> 3) Discussion.
17:08:57 <m-relay> <c​ompdec:matrix.org> not sure if my messages are getting seen
17:09:10 <moneromooo> I saw three.
17:09:18 <Rucknium> Yes, they are seen on the IRC side now through the temporary bridge. Thanks.
17:09:34 <m-relay> <c​ompdec:matrix.org> thanks
17:09:58 <Rucknium> compdec: Do you want to discuss anything about your research project now or wait until you have the draft ready to share?
17:11:31 <m-relay> <c​ompdec:matrix.org> There will be a lot to parse when I do share, I've added a section on how to get more paths with the same number or fewer bytes of chain that I think is interesting.  Would probably take a hard fork to implement, but increases the number of paths considerably
17:12:54 <m-relay> <c​ompdec:matrix.org> I'm still trying to clean things up so we can move to scale on the computer lab, but right now it would just make a mess
17:13:31 <Rucknium> Great. I'm not sure what will happen with the next hard fork. It could be one that implements some changes to RandomX to prevent node DDoS plus Bulletproofs++. Or it could add those two things and Seraphis, with 128+ rings...
17:13:33 <m-relay> <c​ompdec:matrix.org> there were a number of figures added to the git repo, not sure if anyone had a look
17:14:01 <Rucknium> -Or_ Seraphis could be implemented with full chain membership proofs based on Curve Trees. In that case, rings would be obsolete
17:14:40 <Rucknium> I haven't looked at the git repo recently. I can check it out.
17:15:38 <isthmus_> @compdec link to repo?
17:15:40 <m-relay> <c​ompdec:matrix.org> rings would be obsolete?  can you explain that a little bit?  there are decoys about still I take it?
17:16:35 <vtnerd> compdec: basically it becomes a signature were all prior coins are in the possibly spent set
17:16:47 <Rucknium> Basically, no. Change to a Zcash-like model, except with no trusted setup. It would be based on Bulletproofs.
17:17:07 <m-relay> <c​ompdec:matrix.org> https://github.com/nborggren/MoneroAna, it is private at the moment, but if you give me your git handle I'll add you.
17:17:19 <m-relay> <c​ompdec:matrix.org> (or anyone else interested)
17:17:30 <isthmus_> https://github.com/Mitchellpkt/ thanks
17:17:48 <Rucknium> I think there are still "decoys" in the light wallet server way of using a wallet with Curve Trees. I don't understand it yet. kayabaNerve explained it a bit:
17:18:54 <m-relay> <c​ompdec:matrix.org> curious how that will look in a block explorer, very interesting though.
17:18:54 <Rucknium> https://github.com/monero-project/research-lab/issues/100#issuecomment-1608336732
17:19:23 <Rucknium> "I'll also note that while [Decoy Selection Algorithms] aren't dead, they become limited to light wallets (instead of requesting a single path, doxxing the spent output, a ring of paths would be requested). This greatly reduces their importance and issues raised by implementation faults."
17:20:25 <Rucknium> I don't think the "decoys" in Curve Trees will appear in the block explorer. It's more for light wallets servers that have partial knowledge of a user's wallet contents.
17:20:59 <m-relay> <c​ompdec:matrix.org> figures are in docs/images
17:21:13 <Rucknium> We don't know if Curve Trees is a secure cryptographic protocol yet.
17:21:32 <Rucknium> It's going to take a lot of review.
17:22:23 <Rucknium> It will also increase transaction sizes and probably transaction verification time.
17:23:37 <Rucknium> Zcash eliminated their trusted setup in the most recent shielded pool protocol released last year, by the way.
17:24:56 <m-relay> <c​ompdec:matrix.org> some of my current efforts are going to be moot after that transition it seems, but I guess will always have the first few million blocks
17:25:07 <m-relay> <c​ompdec:matrix.org> some of my current efforts are going to be moot after that transition it seems, but I guess we'll always have the first few million blocks
17:25:57 <Rucknium> Yeah. Full Chain Membership Proofs will eliminate a lot of statistical attacks on privacy if implemented.
17:26:27 <m-relay> <c​ompdec:matrix.org> my new ones are deterministic, but yeah, they'll be eliminated
17:26:38 <m-relay> <c​ompdec:matrix.org> (mostly) deterministic
17:28:48 <Rucknium> Anything else to discuss?
17:29:56 <m-relay> <c​ompdec:matrix.org> not unless anyone has questions for me
17:30:40 <isthmus_> No questions now but I'll try to take a look at your work when I get a free minute
17:30:41 <m-relay> <c​ompdec:matrix.org> I won't be able to be here next week, but the document should be out by then.  I'll be back the week after
17:31:21 <Rucknium> Thank you. Looking forward to reading it :)
17:31:38 <Rucknium> Let's end the meeting here. Thanks everyone.
17:32:05 <m-relay> <c​ompdec:matrix.org> it'll still be in progress, but ready for some communication.  Thanks everyone
17:46:45 <vtnerd> hi