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

<r​ucknium:monero.social> Meeting time!

<r​ucknium:monero.social> 1) Greetings

<c​haser:monero.social> hello

Hello

<0​xfffc:monero.social> Hi everyone

<j​berman:monero.social> *waves*

<r​ucknium:monero.social> 2) Updates. What is everyone working on?

<o​ne-horse-wagon:monero.social> Hello

<r​ucknium:monero.social> me: I read a few p2p network privacy papers so I can give feedback about proposed changes to tx propagation protocol. Prepping a new stressnet fork.

<j​effro256:monero.social> howdy

<j​effro256:monero.social> me: carrot doc

<j​effro256:monero.social> me: I found a weird indistinguishability issue with the ephemeral pubkeys that I'm still trying to sort out

<0​xfffc:monero.social> Mostly did spend time on these: (a) reviewed a bunch of different PRs. (b) erlay [1] R&D is almost finished. I am trying to start coding. ( monero-project/monero #9334 )

<0​xfffc:monero.social> 1. arxiv.org/abs/1905.10518

<j​berman:monero.social> me: about to submit a WIP PR for fcmp++ integration that presently includes the Rust FFI, curve trees merkle tree, `grow_tree` & `trim_tree` algos, growing the tree in the db as the node syncs, db migration of outputs into the tree, and changes to `cryptonote::transaction` for fcmp's, with a fairly detailed PR description for all components

<j​berman:monero.social> Aiming to finish my current CCS this week and open another one to continue on fcmp++ integration

<r​ucknium:monero.social> Is the consensus to implement Erlay or just implement the more bandwidth-efficient tx propagation in #9334?

<0​xfffc:monero.social> A bandwidth-efficient tx propagation is the plan so far. Because it is easier. But after some review / coding I will talk to boog about the final decision. ( and of course we have to plan something that we can merge to master eventually )

<r​ucknium:monero.social> 3) Stress testing monerod monero-project/monero #9348

<j​effro256:monero.social> Are we sure Erlay doesn't impede Dandelion++'s effectiveness at network level privacy?

<r​ucknium:monero.social> We plan to continue stressnet for two more months. The stressnet room voted to re-fork testnet from scratch to keep the storage requirements lower. An unpruned stressnet node is about 65GB now.

<0​xfffc:monero.social> Very Good question. There are some side effects from erlay on dandelion++ ( and privacy, generally speaking ). About the bandwidth-efficient tx propagation there is a discussion on that GitHub link I sent.

<r​ucknium:monero.social> IIRC the Erlay paper does a privacy analysis for diffusion (i.e. the fluff phase), but it wasn't too detailed.

<b​oog900:monero.social> Erlay claims it shouldn't as it will only change the fluff phase

<0​xfffc:monero.social> Yes. And IIRC they don’t have dandelion++ . They just privacy test on bitcoin stack. Which is some-case provided better privacy and somecases worse privacy. ( worse privacy case was not real world imho. It provides worse privacy when substantial portions of the attackers nodes are private node. Which generally does not make sense )

<0​xfffc:monero.social> I have to talk to boog more about this though. To verify I have understood it correctly.

<r​ucknium:monero.social> IMHO, with issue #9334, the changes should be implemented in a way to not provide a way of querying the fluff phase txpool with zero delay. Only give the transaction in "push" mode. And the notify_txpool_complement that already exists could be changed to add some delay.

<v​tnerd:monero.social> Hi, sorry late

<r​ucknium:monero.social> There is at least one privacy risk if malicious nodes can query fluff phase txpools at will. That was my purpose for reading some of the tx proagation papers.

<b​oog900:monero.social> we would also have to change fluffy blocks ...

<0​xfffc:monero.social> My apologies. It seems I have missed it. Can you send me few of those tx propagation papers? I am interested in reading more about it.

<b​oog900:monero.social> what would be the issue with querying the fluff phase txpool with zero delay?

<0​xfffc:monero.social> ( in your spare time of course )

<r​ucknium:monero.social> boog900: An adversary can more easily learn the edges in the p2p network graph.

<r​ucknium:monero.social> And an adversary that knows the edges can use more powerful attacks against D++ privacy

<r​ucknium:monero.social> I am working on a write-up to put as a comment to the GitHub issue

<r​ucknium:monero.social> 0xfffc: Here are the papers I read recently (D++ is a re-read):

<r​ucknium:monero.social> Fanti & Viswanath (2017) "Anonymity properties of the bitcoin p2p network"

<r​ucknium:monero.social> Venkatakrishnan, Fanti, & Viswanath (2017) "Dandelion: Redesigning the bitcoin network for anonymity"

<r​ucknium:monero.social> Fanti et al (2018) "Dandelion++: Lightweight Cryptocurrency Networking with Formal Anonymity Guarantees"

<r​ucknium:monero.social> Franzoni & Saza (2022) "Clover: An anonymous transaction relay protocol for the bitcoin P2P network"

<r​ucknium:monero.social> They are all on moneroresearch.info

<r​ucknium:monero.social> Any comments or questions or about stressnet?

<r​ucknium:monero.social> The original Dandelion paper is worth reading since it has theorems on fundamental bounds on the precision and recall of an adversary with any message propagation system.

<0​xfffc:monero.social> Thanks a lot for the list. Particularly the 2022 one. I will read it ( and skim all the papers cited that paper or by that paper ).

<r​ucknium:monero.social> And it also contains the calculation for the 10 minute D++ epochs.

<0​xfffc:monero.social> I read dandelion paper like 7,8 months ago. I need a re-read to remember exact details.

<r​ucknium:monero.social> IMHO, the clover paper didn't do as deep of an analysis as D++. The Clover paper says D++ and Clover have similar privacy, but it needs more analysis IMHO. The main benefit of clover is that it works for nodes with closed ports. D++ doesn't really work for those nodes.

<r​ucknium:monero.social> 4) Potential measures against a black marble attack. monero-project/research-lab #119

<r​ucknium:monero.social> Anything on this? If not, we can move on.

<r​ucknium:monero.social> 5) Research Pre-Seraphis Full-Chain Membership Proofs. getmonero.org/2024/04/27/fcmps.html

<r​ucknium:monero.social> kayabanerve, kayabanerve , jeffro256 , Things to discuss on FCMP?

<j​effro256:monero.social> Not too much to mention, just that I'm continuing to work on the Carrot paper

<j​effro256:monero.social> @jberman is more involved in FCMP development

<j​berman:monero.social> I think the incoming PR will yield some more discussion, but nothing for now from me

<r​ucknium:monero.social> Anything more to discuss? AFAIK, hinto 's question about deprecating binary JSON contents is being put in the Seraphis workgroup and/or in a bigger #monero-dev meeting.

Yes. Is it ok I bring up now the meta-issue of re-establishing something like dev meetings?

<a​aron:cypherstack.com> AIUI kayabanerve is fine with Cypher Stack releasing the recent divisor review report

<r​ucknium:monero.social> Sounds good to me :)

Alright

<a​aron:cypherstack.com> but will wait for another confirmation on this

We have Monero dev related topics and questions every now and then that are not a natural fit for the MRL meeting, nor for the Seraphis wallet workgroup meetings on Mondays in the form and scope those two meetings currently have.

Like that issue of hinto you mentioned

As that issue came up here last Monday, later that day in the workgroup meeting I asked people what they would think about broadening those meetings and turn them into something more general like the dev meetings of yesteryears.

<0​xfffc:monero.social> Apologies for asking unrelated question in the middle of meeting.

<0​xfffc:monero.social> Do we have specific group to follow fcmp integration / dev? I am very interested to follow their work too. (Eventually I want to get involved there too.)

<a​aron:cypherstack.com> kayabanerve kayabanerve: if you could confirm this, would be very helpful! Then we can get it posted to a GH repo within the hour

<j​effro256:monero.social> Closest thing is #no-wallet-left-behind:monero.social

<0​xfffc:monero.social> Thanks.

Anyway: The attending people mostly found "dev meetings again, same day and time as the workgroup meetings so far" a good idea. What do people here think about this?

Yeah, those meetings, for lack of a Seraphis wallet push, have more or less mutated into FCMP meetings now :)

<v​tnerd:monero.social> I'm in support of a more general -dev meeting, primarily because the bulk of my reports would be more appropriate there

If yes, the proposal was also made to relocate the meeting to the monero-dev channel. To make things clear, so to say.

If people are ok with me, I am ready to continue to moderate

<j​effro256:monero.social> Right now reviews are lagging pretty hard behind development (primarily IMO because so many people are focused on the upcoming upgrade, myself included). General -dev meetings *might* help that

<j​berman:monero.social> I think it makes sense to relocate NWLB meetings to -dev meetings at this point

<a​aron:cypherstack.com> \

<a​aron:cypherstack.com> Ugh, sorry... cat walked on my keyboard

Ok. I will announce next Monday's meeting as such, and if no surprising opposition or alternative arrives, we will have a "dev meeting 2.0" then :)

<r​ucknium:monero.social> We can end the meeting here. Thanks everyone.

<j​effro256:monero.social> Thanks everyone. (Especially Aaron's cat)

<a​aron:cypherstack.com> Alas, it is not sarangcat, who sadly passed away last year. It is one of his successors, whom we fostered-to-adopt from a nearby shelter!

<k​ayabanerve:monero.social> Apologies for not being present. I don't have anything to add other than my work on prepping libs for auditing, assuming review passes.

<k​ayabanerve:monero.social> AaronFeickert: If you're fine with it and have made any presentation changes you want.

<k​ayabanerve:monero.social> Though I'll note it likely opens its own discussion to have within a MRL meeting.

<a​aron:cypherstack.com> OK, will post to GH shortly

<j​berman:monero.social> RIP sarangcat

<a​aron:cypherstack.com> Thanks jberman; was a very very sad day

<a​aron:cypherstack.com> I like to think that his kitty spirit lives on in his successors, who are very delightful little demons

<a​aron:cypherstack.com> Fortunately sarangcat lived to the ripe old age of 17

<j​effro256:monero.social> Wow

<o​frnxmr:monero.social> Perfectly on topic, no worries

<o​frnxmr:monero.social> My condolences

<a​aron:cypherstack.com> Much appreciated! May I recommend supporting local animal shelters

<a​aron:cypherstack.com> One of his successors was found wandering a neighborhood, and was brought in to keep him safe. The other successor was abandoned in a carrier at a big-box store

<a​aron:cypherstack.com> But I am happy to report that both are doing well and living their best cat lives :D

<a​aron:cypherstack.com> Divisor report: github.com/cypherstack/divisor-report/releases/tag/final

<a​aron:cypherstack.com> ^ kayabanerve

<k​ayabanerve:monero.social> My summary is the technique is agreed to be sound, yet there's questions about how to derive an actual efficient proof from it. Veridise is currently reviewing my derived R1CS gadget premised on divisors. That at least gets their signature, even if it doesn't let people trivially do their own review. There's an open question of if we want to have Veridise expand their work (expand<clipped mess

<k​ayabanerve:monero.social> ing their hours) and what additional review we'd like on the gadget.

<r​ucknium:monero.social> ...The main benefit of clover is that it works for nodes with closed ports. D++ doesn't really work for those nodes. <<>> does this mean that D++ doesn't really work without inbound connections open?

<0​xfffc:monero.social> nioCat Can you expand on “closed ports”?

I guess that's the question I was asking :)

<v​tnerd:monero.social> D++ stem phase uses outbound connections only. If a node has closed incoming ports, the first/next hop could theoretically determine that a tx originated at the prior node, assuming they can determine closed port vs full incoming p2p table (which I believe is possible)

<v​tnerd:monero.social> One is at the OS/router level, and the other is a policy of monerod

<v​tnerd:monero.social> Although, if node has tor/i2p setup, they could be relaying a tx received over those networks, so the check isn't foolproof

<v​tnerd:monero.social> The main issue is that the node is never participating in d++ stem phase

<k​ayabanerve:monero.social> cc AaronFeickert to agree/disagree/expand on the above

<k​ayabanerve:monero.social> (my above message, not the D++ commentary, sorry)