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

<r​ucknium:monero.social> Meeting time! monero-project/meta #1041

<0​xfffc:monero.social> Hi everyone

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

<v​tnerd:monero.social> Hi

Hello

*waves*

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

me: working on the migration of existing cryptonote outputs into the curve trees merkle tree so they can be used in fcmp's

<v​tnerd:monero.social> Finally reviewing jeffro256 pr that really needs shipping

<r​ucknium:monero.social> me: Helping with stressnet. Researching the fluff phase of the Dandelion++ protocol.

<j​effro256:monero.social> me: Jamtis-RCT testing

<0​xfffc:monero.social> Basically did spend most of my time debugging this: spackle-xmr/monero #13

<0​xfffc:monero.social> There is one simple issue (by nature) that stuck. I have to disconnect the node before going to validation. But the core object doesn’t have any access to t_protocol_handler. So I am trying to find a way to fix this issue. Otherwise the PR is ready.

<0​xfffc:monero.social> I am going to decide to add it as a flag (—sync-then-verify) or propose it as default way of monerod start up.

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

<r​ucknium:monero.social> I tried jeffro256 's "Blockchain: fix temp fails causing alt blocks to be permanently invalid" monero-project/monero #9395 . I didn't see any of the patched nodes get stuck because of incorrectly marking blocks as invalid. Two of my nodes that didn't have the patch got stuck.

<j​effro256:monero.social> Nice. Thanks for testing!

<r​ucknium:monero.social> Stressnet is back to a lower tx volume, which makes the original bug harder to reproduce. Eventually the stressnet tx volume will rise back to the 3+MB block size where the issue was triggered a lot

<r​ucknium:monero.social> No more comments on stressnet? Moving on:

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

<r​ucknium:monero.social> I have been looking at the fluff phase of the Dandelion++ protocol. In "Fix embargo timeout in dandelion++" monero-project/monero #9295 vtnerd notes that Monero's D++ implementation sets the time between fluffing to a Poisson-distributed random timer. The D++ paper assumed that the fluff phase would use BTC's diffusion protocol that used an exponential distribution.

<r​ucknium:monero.social> In 2022 BTC Core developers changed the name of the random timer from Poisson to exponential because the name was misleading: "Rename and move PoissonNextSend functions" bitcoin/bitcoin #24021

<r​ucknium:monero.social> Why it's confusing:

<j​effro256:monero.social> Ahh that would explain why vtnerd used a Poisson dist

<r​ucknium:monero.social> A random variable may be a _Poisson process_ if the arrival times between the values have an exponential distribution. The distribution of the number of arrivals in a fixed time period, e.g. one hour, is a Poisson distribution.

<r​ucknium:monero.social> I don't know for sure what, if any, the privacy impact of this discrepancy may be (positive or negative).

<r​ucknium:monero.social> Remember that this is the fluffing phase, which provides low privacy anyway

<r​ucknium:monero.social> I could try to guess the impact. The best comparison I have is in Fanti and Viswanath (2017) "Anonymity Properties of the Bitcoin P2P Network" arxiv.org/abs/1703.08761

<r​ucknium:monero.social> Fanti is also the lead author of the D++ paper.

<j​effro256:monero.social> I don't know much about the technical details of D++. Is the embargo timeout the delay from when you receive a fluffed tx to when you rebroadcast it?

<r​ucknium:monero.social> Fanti and Viswanath (2017) analyze both the diffusion protocol (which has an exponentially-distributed timer) and "trickle", which was the pre-2015 BTC tx propagation protocol.

<b​oog900:monero.social> IMO we should move to the exponential distribution, however I don't think we have actually found the cause of nodes OOMs yet, right?

<b​oog900:monero.social> If the cause is the fluff queue, using the exponential distribution could make the problem worse as connections could go a lot longer without fluffing

<r​ucknium:monero.social> AFAIK, the "Embargo" in PR #9295 was the "last defense" against a black hole attack when a defective node didn't send during the stem phase

<v​tnerd:monero.social> no embargo timeout starts when you receive a stem tx.

<v​tnerd:monero.social> Each stem node chooses a unique timeout randomly

<r​ucknium:monero.social> boog900: Something I noticed: for a given mean (i.e. given rate lambda), an exponential distribution has a much higher variance than a poisson distribution. That could support your point

<v​tnerd:monero.social> Ideally you cannot determine the order in the stem based on how the embargos timeout

<j​effro256:monero.social> Ah I see, thanks. Does the originating node have an embargo timeout, or does it just try stem again after a certain time period in the current impl? I cam imagine a scenario om which the first node of the stem drops the tx, and then it nevers gets broadcasted

<r​ucknium:monero.social> BTC's pre-2015 trickle protocol randomly ordered a node's peers and then sent them with a 200ms delay one after the other. This is not the same as a Poisson distribution, but maybe we could get a rough idea of the privacy of the Poisson-distributed timer if we think that its privacy is somewhere between diffusion (true exponential) and trickle.

<v​tnerd:monero.social> The originating node also has a timeout, due to the problem you identified

<r​ucknium:monero.social> On a realistic simulation of the BTC network graph (Figure 8 of Fanti and Viswanath (2017)), the probability of correctly guessing the true originating node was 30% for diffusion and 60% for trickle when the adversary had one connection to each honest node.

<r​ucknium:monero.social> ^ That's without any type of D++ stem protocol

<r​ucknium:monero.social> Fanti and Viswanath (2017) didn't think diffusion with exponential delays was very good, anyway. That's why they (with others) wrote the D++ paper.

<r​ucknium:monero.social> But in a practical attack scenario diffusion worked better than trickle at defense

<r​ucknium:monero.social> By the way, I'm only looking at their results for the first-seen estimator instead of the graph-centrality-based estimators. The latter can be more powerful, but AFAIK we believe that it is not feasible to estimate Monero's p2p network graph after this patch: "p2p: add a reference to Cao, Tong et al. for the last_seen changes" monero-project/monero #5682

<r​ucknium:monero.social> That's as far as I've gotten. It may be difficult to directly compute the probability of detection for the diffusion protocol when the timer is Poisson-distributed. Fanti and Viswanath (2017) complain about it a little even when it is the easier exponential distribution. (AFAIK, the computation is much easier with exponential because it is memoryless. Many of the terms in the formulas simplify.)

<r​ucknium:monero.social> My guess: It would be better to use the exponential distribution from the original diffusion protocol, but I cannot be 100% sure about it at this time.

<r​ucknium:monero.social> Anything more on this agenda item?

<r​ucknium:monero.social> 5) Research Pre-Seraphis Full-Chain Membership Proofs. Brandon Goodell has submitted a quote for doing review of the GBP security proofs: repo.getmonero.org/-/project/54/upl…32276aa40d2858366607/monero-gbp.pdf

<r​ucknium:monero.social> kayabanerve , kayabanerve

<k​ayabanerve:monero.social> Above quote is above, I believe we should move forward.

<k​ayabanerve:monero.social> > Their estimate is less than Cypher Stack's quote for the Bulletproofs++ review (my closest comparable, though they're not really the same). Since the hours should be budgeting for the worst case, I personally endorse it

<r​ucknium:monero.social> I read it. It looks good to me.

He does not mention payment in XMR?

Not sure that means much ...

<r​ucknium:monero.social> I noticed that, too. How is he going to be paid?

But yeah, having him working again for Monero would certainly be nice

<k​ayabanerve:monero.social> They did assume a stablecoin 🤔 Sorry, I didn't think much of that. I'll confirm XMR is viable, else we can ping [@sgp_](matrix.to/#/@sgp_:monero.social) to see if MAGIC makes sense, so long as we do want to move forward.

<k​ayabanerve:monero.social> *they didn't explicitly state an option, leaving the examples as stablecoins.

<j​effro256:monero.social> I agree. Brandon accepting XMR would be preferable, especially for the stated rate

<j​effro256:monero.social> I guess the other approach to reviewing GBPs would be to have him not look at the security proofs and instead writing his own proofs, seeing if he reaches the same conclusion. What would be the upsides/downsides of this approach?

<k​ayabanerve:monero.social> That was considered. [@Aaron Feickert](matrix.to/#/@aaron:cypherstack.com) spoke against the idea unless an independent methodology was used.

<j​effro256:monero.social> Brandon has probably already looked at the paper I assume, which would bias his thought process

<k​ayabanerve:monero.social> Since practically, proofs will be derived from the existing BP AC proof, we won't actually get such a methodology.

<k​ayabanerve:monero.social> Reviewing the currently stated proofs should be less work and still cause proper evaluation.

<k​ayabanerve:monero.social> Are there objections to moving forward and working out XMR/MAGIC after the meeting *if there's not objections to the quote itself*? Or is the financial aspect something considered critical to work out prior to general consensus?

<a​aron:cypherstack.com> Just saw the mention, so I haven't checked the backlog...

<a​aron:cypherstack.com> The GBP work makes changes to the protocol as well, which any independent proof would need to account for

<a​aron:cypherstack.com> But yes, in this case I think a more efficient and useful approach would be to have a qualified reviewer conduct a review of Cypher Stack's modified protocol and security proof

<j​berman:monero.social> the approach and price point of Brandon's proposal LGTM, agree XMR is preferable, and I'm fine with MAGIC as a backup for the stablecoin route

I also think payment will work out somehow, so no objection from me to move right after it does

<j​effro256:monero.social> Speaking of audits, I wanted to throw the idea up of auditing the addressing protocol for legacy Cryptonote addresses as detailed in the Jamtis-RCT document, so that we can use this protocol as soon as FCMPs hit (to leverage forward secrecy and so that there isn't a fingerprinting problem when we switch to Jamtis-RCT)

<r​ucknium:monero.social> IMHO, there is rough consensus in favor of repo.getmonero.org/-/project/54/upl…32276aa40d2858366607/monero-gbp.pdf

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