Monero Research Lab Meeting - Wed 31 July 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. Potential measures against a black marble attack.

5. Research Pre-Seraphis Full-Chain Membership Proofs.

6. Any other business

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

#1044

[Rucknium]

Logs

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

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

< v​tnerd:monero.social > Hi

< j​effro256:monero.social > howdy

< rbrunner > Hello

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

< 0​xfffc:monero.social > Hi everyone

< j​berman:monero.social > waves

< r​ucknium:monero.social > Meeting issue: #1048

< k​ayabanerve:matrix.org > 👋

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

< r​ucknium:monero.social > me: Comments on some tx broadcast PRs. Reading papers on gossip protocols and their privacy, bandwidth, and speed.

< v​tnerd:monero.social > I'm working (right now) on jeffro256 pr for blockchain syncing - hopefully we can get this shipped today. Also doing LWS frontend stuff atm

< 0​xfffc:monero.social > Reading and familiarizing myself with my broadcast mechanisms. I have started implementing this: monero-project/monero#9334 (comment)

< 0​xfffc:monero.social > Reading and familiarizing myself with broadcast mechanisms. I have started implementing this: monero-project/monero#9334 (comment)

< j​effro256:monero.social > Me: writing the carrot doc. Draft is here https://github.com/jeffro256/carrot/blob/master/release/carrot_0.1.md

< 0​xfffc:monero.social > Reading the erlay paper and familiarizing myself with broadcast mechanisms. I have started implementing this: monero-project/monero#9334 (comment)

< k​ayabanerve:monero.social > I've been preparing crates for auditing, once our current reviews wraps up.

< r​ucknium:monero.social > 0xfffc: Looks like we are looking at a similar area

< j​berman:monero.social > me: working on adding fcmp++'s to the cryptonote::transaction class

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

< s​gp:monero.social >_ Hello

< r​ucknium:monero.social > spackle created a new release version for stressnet. It pulled in everything that is in the new monero master plus the invalid blocks fix and jeffro256 's PR to reduce tx writes from 2 to 1.

< r​ucknium:monero.social > Things seem to be running smoothly with the new release so far

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

< o​ne-horse-wagon:monero.social > Rucknium: Is there any projected date as to when stressnet will end?

< r​ucknium:monero.social > That's still being discussed.

< o​ne-horse-wagon:monero.social > My feelings are to keep it going until every stress idea has been exhausted.

< 0​xfffc:monero.social > Around August 8,9 spackle will leave stressnet, and me Rucknium will maintain the repo. We expect to continue stress-net but with much less nodes.

< 0​xfffc:monero.social > ( spackle did a great job so far. So hats off to his work )

< r​ucknium:monero.social > Yes that's the loose plan now

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

< r​ucknium:monero.social > A group claimed responsibility for the suspected spam transactions earlier this year: https://antidark.net/board/viewtopic.php?t=10

< r​ucknium:monero.social > They said that their objective was not to launch an anti-privacy black marble attack, but to congest the txpool to try to exploit some mechanisms in some services' withdrawal logic.

< r​ucknium:monero.social > Anyone want to share opinions about this?

< k​ayabanerve:matrix.org > When I first read it, there was no evidence of their claims, and it didn't completely make sense. I wouldn't care too much about it. I'm unsure if they've added more detail though to justify their story.

< j​effro256:monero.social > Agreed: As of yet it is unverified. Might be a mistake to assume that a black marble attack did not occur because some rando on a forum said so

< r​ucknium:monero.social > I basically concur. But they did say something that a person who prepared spam txs would know: wallet2 does not perform well when 200,000 accounts are created.

< j​effro256:monero.social > This looks to be a followup (maybe): https://antidark.net/board/viewtopic.php?t=15

< b​asses:matrix.org > There are some discussion from antidark members https://monero.town/post/3785880

< b​asses:matrix.org > yes

< r​ucknium:monero.social > In the followup they answer a comment about why won't they release the spam wallet(s) view keys. They said that they would not release it.

< r​ucknium:monero.social > It would be bad for user privacy if the suspected spammer actually released the spam wallet(s) view key(s).

< r​ucknium:monero.social > Releasing the view keys would prove that they actually were responsible for the spam (or at least that the entity that was responsible gave them the view keys.

< rbrunner > I guess it doesn't change much for us overall whether it really was this group or not.

< k​ayabanerve:matrix.org > I'd rather such a theoretical view key not float around.

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

< k​ayabanerve:matrix.org > I don't have much more to say than my initial comment. Veridise is moving forward with the R1CS gadget for evaluating this week, and there's preliminary opinions on the GBP proof review.

< r​ucknium:monero.social > I saw this paper: https://distributedlab.com/whitepaper/Bulletproofs-Construction-and-Examples.pdf "This document introduces some clarification and corrections to Bulletproofs++ [Eag+23] paper."

< r​ucknium:monero.social > The paper probably isn't very relevant for Monero right now since BP++ is not going forward in the Monero protocol AFAIK.

< k​ayabanerve:matrix.org > I saw the note it existed. I wouldn't change the perception of BP++, as Aaron reviewed it, at this time.

< k​ayabanerve:matrix.org > If this leads to a new revision of BP++, then that may be eligible for rereview, but...

< r​ucknium:monero.social > Any more topics anyone wants to discuss?

< j​effro256:monero.social > Who would be some good auditors for the new addressing protocol ?

< j​effro256:monero.social > Whether that be Jamtis or Carrot or something else

< a​aron:cypherstack.com > FYI the Cypher Stack review of the Veridise report should be released to kayabanerve today as an initial draft for comment

< a​aron:cypherstack.com > Very curious on the GBP opinion :D

< k​ayabanerve:monero.social > :D

< r​ucknium:monero.social > That reminds me that Cypher Stack reviewed a protocol that seemed to add return addresses to Monero-like txs, which has been on getmonero.org's roadmap for a while: https://github.com/cypherstack/salvium-review/releases/download/final/final.pdf

< a​aron:cypherstack.com > We did that review, yes

< k​ayabanerve:monero.social > jeffro256: You'd need to define the desired properties.

< k​ayabanerve:monero.social > Presumably, a variety of indistinguishability properties.

< j​effro256:monero.social > I have a list of informal security and indistinguishability properties that I plan to add later. Also working on writing a condensed abstraction of FCMP++ requirements for Carrot (i.e. O = x G = y T, C = z G + a H, 0 <= a < 2**64, L = x Hp(O), sender needs knowledge of x, y, z, a, outgoing view wallet needs knowledge of x, etc)

< j​effro256:monero.social > Is this the right path?

< j​effro256:monero.social > *O = x G + y T

< r​ucknium:monero.social > kayabanerve: What do you think ^ ?

< rbrunner > Seems to me if Cypher Stack reviews something like this Salvium, they are in a good spot to review our "stuff" as well. Looks pretty ambitious, by the way, that Salvium project.

< a​aron:cypherstack.com > I can't speak for Cypher Stack, but I would certainly advocate that the company put in a bid for such a review (for the addressing, I mean)

< k​ayabanerve:matrix.org > I'd have to see the document to properly comment, sorry.

< j​effro256:monero.social > Aaron Feickert: thanks !

< j​effro256:monero.social > kayabanerve: fair enough, will try to do later today

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

< j​effro256:monero.social > Thanks everyone !