<r​ucknium:monero.social> MRL meeting in this room in 2 hours.

Meeting time: monero-project/meta #880

1) Greetings

Hi

Heya

<c​ompdec:matrix.org> hola

2) Updates, what is everyone working on?

Sorry I haven’t been around much. Super busy year, only a few free hours here and there.

I’ve been slowly refactoring pieces of the NRL data pipeline, replacing legacy components originally written in haskell and C++.

Along the way, running some simple analyses to surface outputs that have shown up in too many rings. The distribution of output references is:

25 percentile: 3.0

50 percentile: 8.0

75 percentile: 11.0

90 percentile: 14.0

99 percentile: 20.0

99.9 percentile: 30.0

99.99 percentile: 56.0

However, there is an output that has been used 11,000+ times! And many that have been used thousands of times.

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 pypi.org/project/ringxor/#description

For a concrete example, here’s the infamous `6d22` ring which always has ring members [6d22…, 0d02…, 7751…, (...), 4fa4…, <true spend>]

xmrchain.net/search?value=79ba8cd9c…68987776fe6374da6dd28f09884c701cb50

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.

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.

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. github.com/Mitchellpkt/isthmus_indi…s_dev/blob/main/demo_notebook.ipynb

But that’s a whole other story for another day

Otherwise I've mostly just been lurking

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.

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.

hi

<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

Thanks, isthmus

not a lot to report for me, Im leaning towards SSL over Noise for p2p and been trying to track a few bugs

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: usenix.org/conference/usenixsecurity23/presentation/campanelli

3) Discussion.

<c​ompdec:matrix.org> not sure if my messages are getting seen

I saw three.

Yes, they are seen on the IRC side now through the temporary bridge. Thanks.

<c​ompdec:matrix.org> thanks

compdec: Do you want to discuss anything about your research project now or wait until you have the draft ready to share?

<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

<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

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...

<c​ompdec:matrix.org> there were a number of figures added to the git repo, not sure if anyone had a look

-Or_ Seraphis could be implemented with full chain membership proofs based on Curve Trees. In that case, rings would be obsolete

I haven't looked at the git repo recently. I can check it out.

@compdec link to repo?

<c​ompdec:matrix.org> rings would be obsolete? can you explain that a little bit? there are decoys about still I take it?

compdec: basically it becomes a signature were all prior coins are in the possibly spent set

Basically, no. Change to a Zcash-like model, except with no trusted setup. It would be based on Bulletproofs.

<c​ompdec:matrix.org> github.com/nborggren/MoneroAna, it is private at the moment, but if you give me your git handle I'll add you.

<c​ompdec:matrix.org> (or anyone else interested)

github.com/Mitchellpkt thanks

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:

<c​ompdec:matrix.org> curious how that will look in a block explorer, very interesting though.

"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."

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.

<c​ompdec:matrix.org> figures are in docs/images

We don't know if Curve Trees is a secure cryptographic protocol yet.

It's going to take a lot of review.

It will also increase transaction sizes and probably transaction verification time.

Zcash eliminated their trusted setup in the most recent shielded pool protocol released last year, by the way.

<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

<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

Yeah. Full Chain Membership Proofs will eliminate a lot of statistical attacks on privacy if implemented.

<c​ompdec:matrix.org> my new ones are deterministic, but yeah, they'll be eliminated

<c​ompdec:matrix.org> (mostly) deterministic

Anything else to discuss?

<c​ompdec:matrix.org> not unless anyone has questions for me

No questions now but I'll try to take a look at your work when I get a free minute

<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

Thank you. Looking forward to reading it :)

Let's end the meeting here. Thanks everyone.

<c​ompdec:matrix.org> it'll still be in progress, but ready for some communication. Thanks everyone

hi