Monero Research Lab Meeting - Wed 16 August 2023, 17:00 UTC

[Rucknium]

Location: Libera.chat, #monero-research-lab | Matrix

Join the Monero Matrix server if you don't already have a Matrix account.

Time: 17:00 UTC Check in your timezone

Main discussion topics:

1. Greetings

2. Discuss: Reducing 10 block lock: Investigate possibility of reducing 10-blocks lock research-lab#102 (comment)

3. Discuss: Exploring Trustless zk-SNARKs for Monero's payment protocol. What are the bottlenecks for potential implementation?

4. Improvements to the decoy selection algorithm ( Decoy Selection Algorithm - Areas to Improve, Binning PoC, OSPEAD ) @j-berman @Rucknium

5. Seraphis. ( UkoeHB's Seraphis Proof of Concept work, Seraphis repo ).

6. MRL Meta: "Cat herding", i.e. prioritization of research areas and features. Active recruitment of technical talent, MRL structure, funding (@Rucknium & others) MoneroResearch.info repository of Monero-related research papers, Reddit discussion

7. Any other business

8. Confirm next meeting agenda

Please comment on GitHub in advance of the meeting if you would like to propose an agenda item.

Logs will be posted here after the meeting.

Meeting chairperson: UkoeHB

Previous meeting agenda/logs:

#876

[plowsof]

Logs

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.

Automated by this