Monero Research Lab Meeting - Wed 09 October 2024, 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. Updates. What is everyone working on?

3. Stress testing monerod

4. Research Pre-Seraphis Full-Chain Membership Proofs. Reviews for Carrot.

5. Any other business

6. 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: Rucknium

Previous meeting agenda/logs:

#1086

[Rucknium]

Logs:

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

< j​effro256:monero.social > I'm attaching a document from Trail of Bit

< j​effro256:monero.social > It's from their Statement of Work and describes who would work on the Carrot audit

< j​effro256:monero.social > Those on IRC, if you want a copy, email me at jeffro256⊙tc

< j​effro256:monero.social > https://matrix.monero.social/_matrix/media/v1/download/monero.social/wJNcQpFYWVQwITphJvOSQhEo

< geonic > link works on irc too

< j​effro256:monero.social > Ok, sweet. TIL

< r​ottenwheel:kernal.eu > Nice jeffro256!

< s​yntheticbird:monero.social > So, do we expect an Audit arena once again in this meeting? (Will all auditors from last meeting be present?)

< j​effro256:monero.social > Nope

< j​effro256:monero.social > Well, I guess I can't stop them from being present ;). But they weren't explicitly invited to this meeting

< s​yntheticbird:monero.social > ack

< r​euben:firo.org > Jim Miller worked on our earlier Lelantus audit

< j​effro256:monero.social > How did that go?

< r​euben:firo.org > While I think they did a good job, they did miss a fiat-shamir thing (which was exploited) which lead to his article :)

< j​effro256:monero.social > Was it the Bulletproof Fiat-Shamir issue?

< r​euben:firo.org > I got feedback from others to say it should have been caught

< r​euben:firo.org > I think so I'm not technical so yeah but thought it was worth pointing out

< k​ayabanerve:matrix.org > FCMP++s mirrors Orchard and kills it accordingly.

< r​euben:firo.org > https://github.com/trailofbits/publications/blob/master/reviews/zcoin-lelantus-summary.pdf

< k​ayabanerve:matrix.org > Proofs are an opaque byte buffer. Any item read is automatically transcripted. You can't have a proof element not transcripted accordingly.

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

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

< rbrunner > Hello

< j​effro256:monero.social > Howdy

< r​ucknium:monero.social > Reuben: Thanks for the info!

< j​effro256:monero.social > Yes, thanks for the input, Reuben

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

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

< v​tnerd:monero.social > Hi

< k​ayabanerve:matrix.org > 👋

< v​tnerd:monero.social > Nearing completion on a separate span update patch in monerod, and testing the LWS to boost::beast conversion

< k​ayabanerve:matrix.org > Discussed next step of divisors is moving forward. I'm still working on tidying FCMP++ for the next steps of integration.

< r​ucknium:monero.social > me: Finished Dulmage-Mendelsohn decomposition analysis of the suspected black marble attack. The DM decomposition increased the number of rings with effective ring size zero from 0.57 percent to 0.82 percent (an increase of 44 percent). Also finished analysis of tx fluff phase log data. Will post the write-up after the meeting.

< j​effro256:monero.social > me: Carrot balance recovery integration, still. I'm trying to tie it into jberman's async scanning framework as well

< j​berman:monero.social > waves, continuing work on wallet syncing the tree for fcmp++ with minimal data stored, so full wallets can construct fcmp++ referencing updated owned output paths in the tree

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

< r​ucknium:monero.social > The current streessnet is scheduled to be deprecated in two days (unless someone makes a compelling argument to not deprecate it). I think we will set up a new stressnet when FCMP++ is testnet-ready.

< r​ucknium:monero.social > Deprecation = I'll stop sending spam and shut down a few of my nodes

< j​effro256:monero.social > Rucknium rules the stressnet with an iron fist

< r​ucknium:monero.social > 4) Research Pre-Seraphis Full-Chain Membership Proofs. Reviews for Carrot. https://www.getmonero.org/2024/04/27/fcmps.html https://github.com/jeffro256/carrot/blob/master/carrot.md

< j​effro256:monero.social > It would be nice to make a decision today for Carrot auditing so we can set up the CCS / MAGIC, etc and get the ball rolling

< j​effro256:monero.social > I have an opinion, but I'll save it until after others get their chance to chime in

< r​ucknium:monero.social > Here is my rank (1 being most preferred). 1 Cypherstack. 2 Quarkslab. 3 Veridise. 4 Trail of Bits. 5 Zellic. I post this to be provocative so that others who are more knowledgeable tell me why I am wrong.

< s​yntheticbird:monero.social > Yeah that was pretty obvious with Zellic being last.

< r​ucknium:monero.social > I looked at the example reviews/audits that some of the firms provided. I looked for the level of cryptographic review and how similar the work was to what Carrot requires.

< rbrunner > That's interesting. I found that Zellic company and their people quite interesting, and would find it interesting having them work for us. Why definitely last, for all things?

< rbrunner > Working in very different areas?

< r​ucknium:monero.social > Trail of Bits did a Stealth Address review, but the team that did that review is not the same as who would work on Carrot.

< rbrunner > Beside finding Zellic, I only have an opinion about 1 other company: Cypherstack, because known quantity, track record and "closeness" to our ecosystem

< rbrunner > *Beside finding Zellic interesting

< r​ucknium:monero.social > The examples that Zellic gave analyzed code more than the cryptography and were basically smart contract audits AFAIK.

< rbrunner > Alright, I did not look that closely.

< rbrunner > Maybe code reviews would be more appropriate giving to them, later on?

< r​ucknium:monero.social > I like that Quarkslab analyzed BP+ and found at least one issue in its mathematical proof. On Veridise, maybe it's unfair, but their divisor proof we commissioned them for was not tight enough, so that lowers their rating IMHO.

< r​ucknium:monero.social > kayabanerve: Do you plan to give an opinion on Carrot reviews? I would like to hear from more cryptographers on this.

< k​ayabanerve:matrix.org > I'd endorse CS personally. They're the best priced on a reasonable timeline and completely trusted.

< s​yntheticbird:monero.social > Not a cryptographer, but I've heard of Zellic (and perfect blue team) reputation before even joining the Monero community. I think they may be the most inclined to think out of the box. But again, not a cryptographer and no data to back it.

< r​ucknium:monero.social > jeffro256: Can you share your opinion?

< k​ayabanerve:matrix.org > The only reason not to go with CS is a limited availability argument or we want to build relationships with other groups at cost IMO

< j​effro256:monero.social > Not to be a copycat, but my ranking was very similar to Rucknium's: 1. Cypherstack 2. QuarksLabs 3. Veridise, and then a tie between Trail of Bits and Zellic. Cypherstack was the most affordable and would have Surae, a coauthor of CLSAG overseeing the audit. That means that they would be able to being over their knowledge of RingCT composition to apply in many ways to FCMP++ compo<clipped messag

< j​effro256:monero.social > sition. QuarksLabs is also a great candidate because they are very familiar with Pederson commitment related cryptography and rerandomization, making their previous knowledge applicable to FCMP++ composition. As for Trail of Bits, they were on the higher end of price, but tend to produce decent results consistently. Zellic was somewhat of a wild card, as their main focus AFAICT ha<clipped messag

< j​effro256:monero.social > s mainly been smart contract code, but they seem exceedingly capable at finding High and Critical level vulnerabilities, if their published track record is to be believed. They are also the only firm who hasn't worked with Monero yet, AFAIK. As was mentioned earlier, they might be a better candidate for the reviewing a concrete implementation.

< j​effro256:monero.social > If Cypherstack can confirm that the turnaround time would be <= 6 weeks, then that would be on par with the rest, and I would recommend that we go with them

< r​ucknium:monero.social > Diego Salazar: Question for you ^

< d​iego:cypherstack.com > ye

< d​iego:cypherstack.com > damn I really need to raise my prices

< d​iego:cypherstack.com > yes turnaround time will be 6 weeks or less

< r​ucknium:monero.social > I think we are close to loose consensus in favor of contracting Cypher Stack to perform the Carrot review.

< rbrunner > Yeah, still waiting for a dissenting voice :)

< k​ayabanerve:matrix.org > I also vote we no longer publicize prices so CS cannot learn how 'competitive' they are or are not /s

< d​iego:cypherstack.com > As a bonus I can have one of my illustrators draw Monero Chan holding a carrot

< r​ucknium:monero.social > Does anyone want to suggest another plan of action?

< d​iego:cypherstack.com > I say this every time but never do for you guys at MRL. Just love you guys too much.

< s​yntheticbird:monero.social > Diego. The community answered yes to your illustration proposal.

< r​ottenwheel:kernal.eu > Please do not. 😅

< r​ucknium:monero.social > I see loose consensus in favor of contracting Cypher Stack to perform the Carrot review. Thanks all for reviewing the reviewers and especially jeffro256 for writing the Carrot specification and working with firms to get quotes, etc.

< r​ottenwheel:kernal.eu > 🤨👎

< d​iego:cypherstack.com > ok, and to understand a separate CCS is being opened for this, yes?

< s​yntheticbird:monero.social > Cypherstack theory and Zellic on code seems to be a balance plan of action.

< d​iego:cypherstack.com > That's what I recall after the last meeting

< r​ucknium:monero.social > Diego Salazar: Yes. AFAIK jeffro256 will handle bureaucracy from here.

< d​iego:cypherstack.com > Sounds good.

< j​effro256:monero.social > Yes. Carrot wasn't defined as part of the scope for kayabanerve FCMP++ CCS, so it shouldn't thrown in now IMO even though it is applicable

< rbrunner > We had people asking on Reddit how they can donate, and I mentioned that probably soon a "Carrot" CCS will go up

< r​ucknium:monero.social > Do we have more items to discuss on FCMP? Or any other agenda items?

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

< k​ayabanerve:matrix.org > 1) It isn't in-scope

< k​ayabanerve:matrix.org > 2) I wasn't involved with quote solicitation

< k​ayabanerve:matrix.org > 3) Adding extraneous scopes risks budget exhaustion

< k​ayabanerve:matrix.org > 4) carrot is great yet extraneous

< k​ayabanerve:matrix.org > I have nothing beyond my already provided update.

< r​ucknium:monero.social > I took the 10 block lock off of the agenda for now. I posted the cleaned-up version of my double-spend attack success tables on the relevant MRL issue: monero-project/research-lab#102 (comment)

< r​ucknium:monero.social > I think we can end the meeting here. Thanks everyone!

< s​yntheticbird:monero.social > Delicious meeting. Thanks

< j​effro256:monero.social > Thanks, everyone! Great input and feels great to make a decison finally

< r​ucknium:monero.social > The Dulmage-Mendelsohn decomposition results and analysis of p2p tx relay logs is at https://github.com/Rucknium/misc-research/blob/main/Monero-Black-Marble-Flood/pdf/monero-black-marble-flood.pdf . The new additions are page 14, lines 183-203 and pages 19-25, lines 310-434, figures 14-16, tables 1-2.

< r​ucknium:monero.social > The p2p tx logs analysis may be interesting to people who work with the p2p code (e.g. vtnerd and boog900 ). This was a case of making lemonade out of lemons since originally I wanted to use the logs submitted by community members (thank you!) to try to find the node origin of the spam. I changed the scope to producing a statistical profile of p2p transaction relay behavior under <clipped message

< r​ucknium:monero.social > normal conditions.

< r​ucknium:monero.social > Main findings: Total number of IP addresses in the p2p log data was about 13,600, which backs up the estimates of the number of nodes on the network from monero.fail/map . The average duration of a peer connection is 23 minutes, shorter than I would have expected. The probability that a node relays a transaction to two different peers at the same time is higher than what is expect<clipped message

< r​ucknium:monero.social > ed with the theoretical distribution.

< b​oog900:monero.social > Nice work!

< b​oog900:monero.social > Yeah I was wrong about the amount of time between rebroadcasts here are some actual timings: monero-project/monero#8326 which follows the data.

< b​oog900:monero.social > I had a quick look at the code and I couldn't see anything obvious for why the time between when a txs is sent drops so low after the 7th time

< b​oog900:monero.social > Do you know if there are still a lot of txs being sent every 2 to 4 minutes from the 2nd to 7th time, which aren't showing in the median?

< b​oog900:monero.social > > The probability that a node relays a transaction to two different peers at the same time is higher than what is expected with the theoretical distribution

< b​oog900:monero.social > If you have multiple Poisson-distributed independent random variables and took the smallest output out of all of them, the output would no longer be Poisson-distributed, right?

< b​oog900:monero.social > If you had multiple connections all with a tx waiting for their Poisson-distributed timer to fire, then the distribution of the time to receive the tx would be skewed downwards due to taking the smallest value from all the timers.

< b​oog900:monero.social > Just to be clear there I was talking about this from the last section of that paper:

< b​oog900:monero.social > > If a node is following the protocol, we should observe two data patterns when we compute

< b​oog900:monero.social > the difference between the arrival times of a transaction between two logging nodes. First, the differences

< b​oog900:monero.social > should usually be in quarter second intervals. Second, the difference should follow a Skellam distribution,

< b​oog900:monero.social > which is the distribution that describes the difference between two Poisson-distributed independent random

< b​oog900:monero.social > variables

< b​oog900:monero.social > If that did mean from the same origin node then ignore what I said.

< r​ucknium:monero.social > IMHO, it's misbehaving nodes. I looked at some of the raw log data and some nodes were just re-broadcasting every 2-4 minutes. I will make some histograms to show the full distribution at each re-broadcast iteration for you.

< r​ucknium:monero.social > Same origin node. Sorry that it wasn't clear. By chance, some of the listening nodes connected to the same node occasionally. So we could see what a node was doing on two of its connections.

< r​ucknium:monero.social > Maybe I should make a little diagram to show clearly the situation I was talking about.

< r​ucknium:monero.social > Do you know why connections last for about 23 minutes? Is there a timer in the code?

< b​oog900:monero.social > ah my bad yeah that makes sense

< b​oog900:monero.social > We do once synced, drop a single outbound peer when on_idle is called here: https://github.com/monero-project/monero/blob/9866a0e9021e2422d8055731a586083eb5e2be67/src/cryptonote_protocol/cryptonote_protocol_handler.inl#L1787

< b​oog900:monero.social > on_idle seems to be called every 1 to 2 minutes looking at my logs