Monero Research Lab Meeting - Wed 15 January 2025, 17:00 UTC

[Rucknium]

Location: Libera.chat, #monero-research-lab | Matrix

Time: 17:00 UTC Check in your timezone

Main discussion topics:

1. Greetings

2. Updates. What is everyone working on?

3. Generalized Bulletproofs implementation audit.

4. FCMP++ tx size and compute cost. On MAX_INPUTS and MAX_OUTPUTS. Monero FCMP MAX_INPUTS/MAX_OUTPUTS empirical analysis. LATEST BENCHMARKS

5. Discussion: Post-quantum security and ethical considerations over elliptic curve cryptography

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:

#1138

[Rucknium]

Logs

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

< s​agewilder:unredacted.org > Is this meeting open to external attendees?

< r​ucknium:monero.social > sagewilder: Yes, always :)

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

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

< s​yntheticbird:monero.social > Hi

< s​yntheticbird:monero.social > first

< v​tnerd:monero.social > hi

< j​effro256:monero.social > Howdy

< rbrunner > Hello

< j​berman:monero.social > waves

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

< j​effro256:monero.social > Carrot integration & benchmarking, FCMP++ benchmarking, reviewing FCMP++ integration

< j​berman:monero.social > me: constructing and verifying FCMP++ proofs over the FFI is working, cleaning it up and organizing functions now, aiming to roll up wallet sync + FCMP++ prove/verify into the WIP PR

< v​tnerd:monero.social > bug fixes for monerod

< r​ucknium:monero.social > me: Submitted Milestone 2 of OSPEAD to the review panel. That's the initial improved decoy selection algorithm with all the code to statistically estimate it. Probably I will post it publicly in about a month. In the meantime, if any devs or researchers want a copy, let me know. I may discuss preliminary results next meeting.

< r​ucknium:monero.social > 3) Generalized Bulletproofs implementation audit. https://github.com/cypherstack/generalized-bulletproofs-code

< r​ucknium:monero.social > Anything to say about the audit?

< c​haser:monero.social > it was a Christmas present to MRL.

< j​berman:monero.social > The audit highlighted areas that could have more tests, I figure it would be nice if someone wanted to pick that up

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

< r​ucknium:monero.social > 4) FCMP++ tx size and compute cost. On MAX_INPUTS and MAX_OUTPUTS. Monero FCMP MAX_INPUTS/MAX_OUTPUTS empirical analysis. LATEST BENCHMARKS: https://github.com/jeffro256/clsag_vs_fcmppp_bench

< j​effro256:monero.social > From the results that I obtained on an AMD CPU and Intel CPU that I own, plus the results that other people have sent me, the speed for an 8-input FCMP++ transaction is the same as a 47-52 input CLSAG. Likewise, a 16-input FCMP++ transaction is the same as a 94-101 input CLSAG

< r​ucknium:monero.social > From my read of the benchmarks, FCMP input proofs with a larger number of inputs are actually more efficient to verify than those with a smaller number of inputs. Am I missing something?

< r​ucknium:monero.social > More efficient per input I mean

< j​effro256:monero.social > Yes, but the effect seems start to to taper off after 8-input and they don't get much more efficient per-input after that

< r​ucknium:monero.social > So the only issue is the initial verification for txpool and relay, which can be large for a tx with many inputs. The verification of a block with these txs would actually be more efficient with large number of inputs instead of breaking up the enote consolidation

< r​ucknium:monero.social > And the main issue with txpool/relay is a malicious actor trying to DDoS a node with bad proofs, right?

< j​effro256:monero.social > I'd have to check multi-tx batch times. I don't know if it improves the per-tx verification time or not.

< j​effro256:monero.social > But yes the main goal with this whole affair of limiting input counts is to prevent DoS attacks with bad proofs

< r​ucknium:monero.social > Does sech1 want to say something about this?

< j​effro256:monero.social > If 100-input CLSAGs are acceptable now, I'd say we should allow 16-input FCMP++s

< rbrunner > How limiting is that really? If I want to attack, and I am only allowed 4 inputs instead of 8, can't I simply send twice the number of transactions for the same effect?

< sech1 > I can only repeat that comparing (supposedly) unoptimized FCMP++ code with an optimized production CLSAG code can be misleading

< sech1 > I expect FCMP++ will get faster

< r​ucknium:monero.social > Probably. Maybe could go even higher to 32.

< j​effro256:monero.social > rbrunner: it does increase the latency between the time you sent the first one, and the time that we decide that we can ban you for X amount of time

< r​ucknium:monero.social > rbrunner: I guess your node would get banned after the first bad tx

< j​effro256:monero.social > Yes, I only expect FCMP++ to get faster, especially with high-performance field arithmetic

< r​ucknium:monero.social > If FCMP verification gets faster, it should be worked on soon because the audits should audit optimized code.

< rbrunner > Hmmm, but if you block me possibly after only a few bad apples, it again does not matter much how long that takes? Or do you think of attackers with hundreds of nodes at hand?

< r​ucknium:monero.social > I don't like the idea of auditing an unoptimized implementation and deployed an optimized, unaudited one. But maybe others disagree.

< rbrunner > I agree, auditing first and then tinker with the code further does not sound like the best of ideas ...

< s​yntheticbird:monero.social > what about releasing unoptimized and next hard fork deploy the optimized + audited one

< c​haser:monero.social > IMHO that could erode the margin of safety, as well as miss the opportunity to gradually decrease the number of possible tx shapes as part of the longer-term goal of increasing tx uniformity.

< sech1 > It needs to be reasonably optimized before the audit. Reasonable = no crazy optimizations that hurt readability/maintainability, and no assembly code

< j​berman:monero.social > The "unoptimized" part of the code expected to be sped up (via a contest, ideally) is sectioned off from other sections slated for immediate auditing I'm pretty sure. I'm generally content with putting more pressure on optimizing sooner rather than later though, the contest has been on the back of my mind

< r​ucknium:monero.social > Should the contest be set up? Any issues holding it up?

< s​agewilder:unredacted.org > Well it was supposed to be KayabaNerve organizing it, before the stepping back

< s​agewilder:unredacted.org > I was interested. But no news since.

< rbrunner > Was the idea to get the "award money" through a CCS? Or out of some already existing fund?

< j​berman:monero.social > I can come back next week with a stronger fleshed out proposed next steps

< r​ucknium:monero.social > jberman: Great. Thanks!

< s​yntheticbird:monero.social > 0xfffc got competition

< s​agewilder:unredacted.org > There were others known to be interested ?

< s​yntheticbird:monero.social > Yes

< r​ucknium:monero.social > I guess where we are in the MAX_INPUTS discussion is being thankful that jeffro256 set up the benchmark repo, then the code optimizations can be easily put into the repo when they are ready. Then a decision can be made based on the new benchmarks.

< r​ucknium:monero.social > I could re-run my empirical analysis https://gist.github.com/Rucknium/784b243d75184333144a92b3258788f6 with the new jeffro256 benchmarks, too.

< j​effro256:monero.social > Thanks for doing those calculations, having optimal consolidation times laid out like this is helpful

< rbrunner > I wonder how far wallet app implementers will go supporting automatic consolidations, at least in early FCMP++ supporting versions

< r​ucknium:monero.social > Probably "DAEMON: Transaction rejected" :P

< r​ucknium:monero.social > As in, some of them won't realize there is a limit

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

< rbrunner > Lol

< s​yntheticbird:monero.social > none that contribute

< r​ucknium:monero.social > 5) Discussion: Post-quantum security and ethical considerations over elliptic curve cryptography monero-project/research-lab#131

< s​yntheticbird:monero.social > It's maths time!

< rbrunner > Seem to wait for the next company to announce some step forward towards QC, to get to the top of people's minds again ...

< s​yntheticbird:monero.social > rbrunner im already haunted, no need to add more

< s​yntheticbird:monero.social > Kinda have to admit this section of the meeting is a little empty without Jeffro and Kayaba brainstorming

< s​yntheticbird:monero.social > god bless cryptography nerds

< j​effro256:monero.social > lol

< j​effro256:monero.social > I wanted to throw up a point for discussion as it relates to how the generate-address wallet tier and quantum migrations interact

< s​yntheticbird:monero.social > feel free

< c​haser:monero.social > rbrunner: I think we're rather waiting for better/optimized signature algorithms to be invented.

< s​yntheticbird:monero.social > chaser: kayabanerve just told let me a big NO. But i'm interested if PQ exchange can be done with KEM, because they generally have smaller sizes

< j​effro256:monero.social > Basically, if a quantum computer sees any one of your Monero addresses, then they can 1) see all incoming enotes to that account, and 2) see where those incoming enotes were spent, if 2 enotes addressed to the same subaddress were spent more than once

< c​haser:monero.social > "big NO" as to what?

< j​effro256:monero.social > The generate-address tier with a quantum computer would be able to trim that down to seeing where incoming enotes are spent if they're spent at all

< r​ucknium:monero.social > "if 2 enotes addressed to the same subaddress were spent more than once " Do not necessarily have to be spent in the same tx, right?

< s​yntheticbird:monero.social > jeffro256: They can see all incoming enotes from the moment they break your address. Or the entirety of the incoming history?

< j​effro256:monero.social > Nope, they can be spent anywhere on the chain

< j​effro256:monero.social > They entirety of the incoming history, not including change and other self-sends

< r​ucknium:monero.social > Does this mean....PQ churning defense!?!?

< s​yntheticbird:monero.social > I feel like until we get some miracle PQ DSA, wallet will need to self-send automatically on receive then

< j​effro256:monero.social > So there's a question on whether we should officially support delegated subaddress generation, since they get a more privileged look into the wallet history as compared to a normal external observer

< j​effro256:monero.social > YES

< s​yntheticbird:monero.social > Mind explaining for the mortals?

< c​haser:monero.social > ...which is not so different from tevador's Monero Checks 😔

< r​ucknium:monero.social > Churning was hypothesized to be a defense against ring signature analysis. And it may have a role even after FCMP activation, as a defense against quantum computers

< j​effro256:monero.social > This is a good mitigation that hides the flow of funds out of the account. A PQ would still know which transactions you received XMR from other and which amounts, but then the trail would go cold

< r​ucknium:monero.social > IIRC, there was s discussion on the Zcash forums about churning to defend against quantum computers, even for their shielded protocol

< s​yntheticbird:monero.social > I didn't know that. Has this been discussed before? I would like to check moredetails

< s​yntheticbird:monero.social > ah ok yes

< rbrunner > With so much larger tx sizes, and so much longer verification times, making wallets to churn anything incoming automatically? Sounds like a hard sell to me

< s​yntheticbird:monero.social > rbrunner i agree i feel the concern

< rbrunner > Imagine receiving something on a non-high-end-smartphone taking a minute

< j​effro256:monero.social > It's mentioned in the Carrot document, but I suck at writing so people didn't pick it up probably even if they read that

< s​yntheticbird:monero.social > Monero, the money for rich people because poor cannot compute

< c​haser:monero.social > jeffro: I picked it up, I think it was tangible

< s​yntheticbird:monero.social > To answer your original question jeffro256: Yes i think we should officially support it. I don't mind supporting something that relies on Trust. As long as people are aware of it.

< r​ucknium:monero.social > These posts:

< r​ucknium:monero.social > https://forum.zcashcommunity.com/t/is-zcash-actually-quantum-private/40706

< r​ucknium:monero.social > https://forum.zcashcommunity.com/t/churning-zcash-for-maximum-anonymity-and-privacy/40705

< s​yntheticbird:monero.social > thx u so much

< c​haser:monero.social > IMHO if removing delegated address generation hides a greater section of the tx graph from a QC, it's a worthwhile trade-off.

< r​ucknium:monero.social > I need a reminder. How is the address generation delegation wallet tier different from current view keys?

< s​yntheticbird:monero.social > Isn't delegation subaddress generation just about generating new subaddresses and thats all ?

< r​ucknium:monero.social > Would that take away useful features from merchants?

< j​effro256:monero.social > rbrunner: regarding churning costs, if you are receiving lots of inputs, you can do batch consolidation like how Rucknium laid out. You wouldn't really lose any privacy this way either since a quantum computer with your public address already knows you own all your incoming enotes

< j​effro256:monero.social > For a classical computer, giving them the generate-address secret lets them generate subaddresses for you and gain NO on-chain information about transaction history

< j​effro256:monero.social > Versus today, if you can generate addresses for them, you can also view-scan their wallet

< r​ucknium:monero.social > Isn't it better to keep the generate-address tier because it protects merchants even more from a classical computer? And quantum computer risk is still speculative?

< j​effro256:monero.social > That's a good point

< j​effro256:monero.social > The goal for the generate-address tier was to make PoS systems or invoicing systems that are more secure, not needing private key info

< j​effro256:monero.social > And using subaddresses instead of integrated addresses

< rbrunner > Which is a solid win, right?

< j​effro256:monero.social > Integrated addresses already fill this role, but they have their own issues

< s​yntheticbird:monero.social > Is there loose consensus for keeping generate address tier then ?

< rbrunner > Handling Monero is complex. Everything that simplifies is very welcome IMHO. Giving that up again for a spectre that may come to hount us in 10 or even 20 years - or maybe never?

< c​haser:monero.social > it's a win for the merchant, a lose for current-era Monero users if/when quantum adversaries look at the blockchain.

< c​haser:monero.social > and the blockchain doesn't forget

< s​yntheticbird:monero.social > a lose only if they make use of it

< s​yntheticbird:monero.social > which most users won't

< c​haser:monero.social > hmm

< r​ucknium:monero.social > Isn't it a loss only for people who use that tier and the key information in that tier falls into the hands of an adversary?

< s​yntheticbird:monero.social > Rucknium yes

< r​ucknium:monero.social > Put it in a footnote in the docs and keep it :D

< s​yntheticbird:monero.social > exactly

< s​yntheticbird:monero.social > only real users are merchants and they are already vulnerable to this since they provide public addresses to pay them

< c​haser:monero.social > ok, so it's basically a choice for the merchant as to which kind of risk to go with, and not a risk for the customer

< j​effro256:monero.social > It would be a new risk to customer if the adversary knew the customers and the merchants public address, and the customer used the generate-address tier and that tier fell into the hands of the adversary, and the customer spent their money received from somewhere else into an address with only one spent into that merchants address

< j​effro256:monero.social > Then the adversary could track the flow of funds from the customer to the mercant, whereas they wouldn't have been able to if the customer wasn't using the generate-address tier

< r​ucknium:monero.social > Let's assume independence of events and multiply probabilities of each to see how likely that is :D

< s​yntheticbird:monero.social > lmao

< r​ucknium:monero.social > Thanks for the attention to detail, jeffro

< s​yntheticbird:monero.social > yup

< r​ucknium:monero.social > But they could do that anyway with the status quo view key tier, right?

< rbrunner > It does get a bit extreme now with the scenarious :)

< r​ucknium:monero.social > I mean, they will see the txs come in without a QC if they had the view key

< j​effro256:monero.social > Well before FCMP++, all transactions will be traceable even without knowledge of any addresses

< j​effro256:monero.social > (if you have a QC)

< s​yntheticbird:monero.social > (((DLog solver under parentheses)))

< j​effro256:monero.social > haha

< j​effro256:monero.social > Yes, and also they can mainly see outgoing with ring signatures

< j​effro256:monero.social > Because of probability and such

< r​ucknium:monero.social > I mean, with a hypothetical FCMP view key without the address-generation tier. Merchants have to generate addresses somehow, unless they use integrated addresses

< r​ucknium:monero.social > Or have a static address and track payments some other way.

< j​effro256:monero.social > Yes. No QC, FCMP++, with private view-incoming key, one would be able to see all incoming enotes

< s​yntheticbird:monero.social > We should get a QC just to automatically generate the gf transparency report

< j​effro256:monero.social > What a lot of merchant software does to avoid integrated addresses and giving up that view key is to pregenerate thousands of addresses beforehand, and then load all those onto the frontend

< r​ucknium:monero.social > Then an adversary could exhaust them by creating bogus invoices. But maybe adversaries have better things to attack

< j​effro256:monero.social > Exactly

< j​effro256:monero.social > Depends on how cheap it is to spam create invoices and how much they dislike this merchant

< r​ucknium:monero.social > Let's end the meeting here. Feel free to continue discussing.

< s​yntheticbird:monero.social > delicious meeting

< v​tnerd:monero.social > late as per usual, was reading over the carrot spec again. I’m still in favor of the generate-address tier, despite the drawbacks mentioned

< v​tnerd:monero.social > the majority of users won’t really run into an issue where it will matter either

< s​agewilder:unredacted.org > Apologies if this isn't the right channel, but do you have an ETA for the FCMP++ in testnet?

< s​yntheticbird:monero.social > in between 1 to 2 months iirc

< s​yntheticbird:monero.social > if not i'll cry

< j​berman:monero.social > I think we can get to a testnet in 1 to 2 months, but not pushing for the official testnet, because I figure we'd want code review / audits completed before deploying to testnet

< j​berman:monero.social > When I say a testnet, I mean something like the stressnet

< s​yntheticbird:monero.social > seems fair

< s​yntheticbird:monero.social > I would have expected testnet to be more stressnet and stagenet to be what you call official testnet tho

< s​agewilder:unredacted.org > It won't be a long wait, then.

< j​berman:monero.social > From these docs (https://docs.getmonero.org/infrastructure/networks/), the testnet is for experimental release before mainnet (ideally I figure we want 1 testnet release, with code lined up ready to go), stagenet is supposed to be for app devs using monero (so stagenet expects mainnet parity)

< rbrunner > "in between 1 to 2 months iirc" Is that a jberman estimate? Or jberman + jeffro256? Sounds a bit optimistic to me, frankly.

< s​yntheticbird:monero.social > rbrunner you are pessimistic.

< rbrunner > Right.

< s​yntheticbird:monero.social > it's because of people like you that we stopped music in elevator

< rbrunner > ?

< s​yntheticbird:monero.social > idk something something not happy. I missed the joke sry

< rbrunner > Ok :)

< s​yntheticbird:monero.social > yeah ok make sense, another detached testnet would make sense

< rbrunner > No, I think it's ok to set ambitious goals among devs, e.g. as a motivation, but they can leak out e.g. to Reddit and rise unreasonable expectations there

< rbrunner > Unfortunately

< j​berman:monero.social > that's a me estimate, I'm not sure how long carrot integration would take but it sounds mostly ready

< s​yntheticbird:monero.social > As redditor in denial, I disagree with you (I'm in denial)

< o​frnxmr:monero.social > https://www.youtube.com/watch?v=u8Kt7fRa2Wc rbrunner

< j​effro256:monero.social > Carrot integration into wallet2, without Carrot key hierarchy migration, is definitely achievable within the next month

< rbrunner > o​frnxmr: Didn't know those "expert" videos yet, they are cool