Monero Research Lab Meeting - Wed 15 May 2024, 17:00 UTC

Logs:

< rucknium:monero.social > Meeting time! https://github.com/monero-project/meta/issues/1007

< rucknium:monero.social > 1) Greetings

< tevador > Hi

< chaser:monero.social > hello

< rbrunner > Hello

< articmine:monero.social > Hi

< jeffro256:monero.social > Howdy

< jberman > hello

< kayabanerve:matrix.org > :wave\

< rottenwheel:kernal.eu > Hola.

_< sgp:monero.social >__ hello

< hinto:monero.social > hi

< rucknium:monero.social > 2) Updates. What is everyone working on?

< kayabanerve:matrix.org > Continued work on FCMPs, met with various auditors and got various quotes.

< jberman > me: implementing the curves tree tree in C++ for fcmp's

< tevador > Jamtis specs, mainly forward-secrecy improvements and some updates based on recent discussions.

< rucknium:monero.social > me: Estimating tx verification time with different ring sizes and inputs/outputs. Monitoring a recent increase of 1in/16out txs on the blockchain.

< articmine:monero.social > Working on scaling and fees for ~ 3000 bytes 2/2 tx and 1/2 tx weight

< articmine:monero.social > I do have a question. How does the number of inputs impact tx size under FCMP?

< tevador > I heard ~2.2 KB per input.

< kayabanerve:monero.social > It depends if we power of two structure or not.

< tevador > Btw, we could restrict inputs to powers of two with dummy inputs.

< chaser:monero.social > tevador explained this in more detail here, and I think it's a neat idea, though not sure how it plays out re: scalability: https://github.com/monero-project/research-lab/issues/96#issuecomment-2107521580

< kayabanerve:matrix.org > Additional inputs can only add an extra few hundred bytes, or each power of two we must sum to equal the input qulity may add that 2.2-2.5kB mark.

< kayabanerve:monero.social > matrix.org has notable latency for sent messages :/

< kayabanerve:matrix.org > It practically depends on if we want to limit inputs to 16, like we do outputs due to the aggregate range proof.

< kayabanerve:matrix.org > And if the performance of any wasted inputs is acceptable.\

< rucknium:monero.social > Ah, sorry. I had a problem.

< tevador > The consensus limit would be 64 inputs, ~145 KB size. Most transactions would fit into the 2/2 envelope, so the overhead would be reasonable.

< rucknium:monero.social > 3) Potential measures against a black marble attack

< kayabanerve:monero.social > I'll respond to that during the proper section.

_< sgp:monero.social >__ The most common number of inputs are: 1, 2, and max for filling the max transaction size ~146

< rucknium:monero.social > Transactions with 1 input and 8-16 outputs produced about 15% of outputs recently. Then starting on May 11 the number of these types of transactions started rising. By yesterday (May 14), they were producing 52% of outputs. But in the first twelve hours of today (May 15) their share of outputs was 33%.

< rucknium:monero.social > These transactions could be related to Local Monero's cessation of operations. Maybe these are batched withdrawals.

< rucknium:monero.social > I tried to set up koe's Seraphis performance test for CLSAG verification time estimates: https://github.com/UkoeHB/monero/blob/seraphis_perf/tests/performance_tests/main.cpp

< rucknium:monero.social > I was mostly successful. koe's code only allows ring size in powers of two. Maybe that could be changed easily, but I don't know C++. My plan, which seems to be working, is to interpolate the verification time for different ring sizes by Ordinary Least Squares (OLS) regression. We need to estimate verification time for the 2in/2out reference transaction and for a diverse set of in<clipped message

< rucknium:monero.social > /out tx types in a realistic "average" block.

< rucknium:monero.social > I think by Monday I will have a draft for feedback of the different options for fee and ring sizes, effective ring size when a black marble flooder has different budgets, users' cost to send txs, the one year blockchain growth estimates, verification time, etc.

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

< rucknium:monero.social > By the way, thanks to nioCat for noticing the 1in/16out tx increase first.

< tevador > kayabanerve: any comments on FCMP++ inputs?

< kayabanerve:matrix.org > If we do a pow-two system, there's no wasted work. If we do an aggregate system (lowest overall bandwidth), 33 inputs causes 64 inputs of work to be completely clear there.

< rbrunner > How do those p2pool payout transactions with 150 outputs fit there? Are they still outside, so to say, because different type of transaction?

< kayabanerve:monero.social > On-chain limit is 16 outputs.

< kayabanerve:monero.social > So I'm unsure what P2pool is or isn't doing.

< tevador > So the choice is basically between wasted work or wasted space. Wasted space would come with the benefit of quantizing transaction shapes, leading to better uniformity.

< rucknium:monero.social > kayabanerve: For coinbase outputs when FCMP++ is implemented, the limit is 16 outputs?

< chaser:monero.social > miner reward payouts are a different tx type, aren't they? I've seen 16+ output payouts from p2pool.

< tevador > Coinbase txs have no limit because they have no range proofs.

< rucknium:monero.social > A coinbase tx can have a huge number of outputs now.

< articmine:monero.social > Yes. If I understand correctly they are in the clear.

< articmine:monero.social > Coinbase

< jeffro256:monero.social > Let's say you have 15 inputs. Is there any verify time wasted doing a 8 + 4 + 2 + 1, versus adding 1 dummy to make 16?

< tevador > IIUIC, 8+4+2+1 is only for storage. The work is still 16.

< kayabanerve:matrix.org > Oh, I have no ideas/comments on coinbase outputs.

< kayabanerve:matrix.org > FCMP++ only affects the input side of things.

< rbrunner > 23 outputs: https://p2pool.io/explorer/tx/8bf3108a0ac267ca0e5d5ab4c622f05f816b1139f5ed1f9feae7e28445c3fe9a

< kayabanerve:matrix.org > jeffro256: 15 (256 + 128) gates vs 16 (256 + 128) gates

< tevador > Dummy inputs have some compute overhead due to the need to update the tree root.

< kayabanerve:matrix.org > BUT you also have the overhead of the multiple proofs.

< kayabanerve:matrix.org > No, 8 + 4 + 2 + 1 does multiple 'setups' (being mutiple proofs) but doesn't waste any multiplication gates.

< jeffro256:monero.social > kk thank you

< kayabanerve:matrix.org > Shall I move to discussing audits now?

< rucknium:monero.social > I don't know how to evaluate the bandwidth (bytes) tradeoff with the verification time bandwidth until we have more certain numbers about verification time.

< kayabanerve:matrix.org > Er, review/research/audits

< kayabanerve:matrix.org > Rucknium: Currently at ~35ms for one, 12ms per in a batch of ten, 10ms per in a batch of one hundred, without tailored field implementations.

< kayabanerve:matrix.org > Those are all 1-input proofs.

< articmine:monero.social > When it comes to verification time we need to consider parallel processing.

< jberman > It would be a nice to get a table up with columns for # of inputs, tx size, verification time (for both approaches pow-2 / not). Similar to how koe did it for Seraphis here: https://github.com/monero-project/research-lab/issues/91

< articmine:monero.social > There is a very significant amount of underutilized CPU and GPU power here

< rucknium:monero.social > If we can, when code audits are done we should try to audit parallelized implementations so they can be deployed confidently on mainnet.

< articmine:monero.social > Yea!

< tevador > Beware of scope screep.

< tevador > creep*

< kayabanerve:matrix.org > I don'

< rbrunner > One after the other :)

< kayabanerve:matrix.org > *I don't believe current perf mandates parallelization, and you'd arguably only want to parallelize circuit instantiations (not the BP verifying proper, as that'll give you multiple multiexps)

< kayabanerve:matrix.org > If you do want full parallelization, with multiple multiexps, wherever the TX verifies a list of proofs, it'd just make 4 proofs and do verification on 4 threads

< kayabanerve:matrix.org > *4 lists and do verification...

< kayabanerve:matrix.org > So it's quite trivial to so parallelize.

< articmine:monero.social > I am talking of verification of different transactions in parallel

< kayabanerve:matrix.org > Regarding audits and review, we've collected 4 quotes and are waiting on 2 re: divisor review.

< rbrunner > Quick ELI5 explanation what is a "divisor", maybe?

< rbrunner > Or is it "complicated" anyway

< kayabanerve:matrix.org > eli5: something mathemeticians made up, even I don't understand them

< rbrunner > :)

< jberman > thumbs up will parallelize verification of FCMP's where trivial as described there, including across txs

< kayabanerve:matrix.org > Tbf, I also haven't learned how BP works internally, solely how to use it.

< rbrunner > If they just work, and provably so, who cares :)

< rucknium:monero.social > Thanks, jberman :)

< kayabanerve:matrix.org > Anyways, I solicited 1 quote from Cypher Stack regarding the composition.

< kayabanerve:matrix.org > I did not mass request quotes for that as it was not specified for just anyone to review the work. It does need someone familiar with Monero to 'run with it'

< kayabanerve:matrix.org > (verify it achieves the desired properties, unlinkable, unforgeable, non-malleable linking tags, a correct composition, etc)

< kayabanerve:matrix.org > https://gist.github.com/AaronFeickert/c24d42d9180ddba515462d4468f25831 2.5 weeks, 175 XMR was the quote from Diego Salazar

< kayabanerve:matrix.org > I'd endorse moving forward with that, and given jberman and MRL oversight, such moving forward is allowed to occur per the earmarked fund.

< kayabanerve:matrix.org > > kayabaNerve and jberman are the people primarily expected to find such parties, with the actual agreement on parties and amount to be by their endorsement, and a general agreement within MRL that the proposed expenditure is reasonable. The word choice of reasonable means that the proposed parties are reasonably trusted to be able to adequately perform the work proposed, the amou<clipped message

< kayabanerve:matrix.org > nt to be paid is understandable and amenable, and if there are other potential parties, none are clearly, completely, and definitively better choices.

< kayabanerve:matrix.org > For the relevant paragraph

< jberman > I'm in favor of moving forward with CS for composition review

< rbrunner > Only 2.5 weeks sounds pretty attractive, for whatever this is

< rucknium:monero.social > What does "review" mean in the gist?

< kayabanerve:matrix.org > And a steal at just 175 XMR! Buy now and get a copy of Diego's 10 best hits, including their Christmas songs, free!

< diego:cypherstack.com > I've published two novels.

< kayabanerve:matrix.org > The composition composes already proved proofs. The only necessity is to verify they compose as expected to the intended effects. I'd leave Aaron Feickert to comment in more detail though.

< diego:cypherstack.com > One MRL member gets a free novel if we move forward on this proposal. ;)

< rucknium:monero.social > Will we get a security proof of the composability of this system?

< tevador > Forward secrecy should be among the properties to be audited.

< rucknium:monero.social > (I barely understand composability on a surface level 😬)

< kayabanerve:matrix.org > Diego Salazar: no kickbacks

< kayabanerve:matrix.org > It;d be a proof of the composition, not of the composability. I'd agree to including F-S if it wasn't for the fact I wrote a script effectively proving F-S

< kayabanerve:matrix.org > (if it was a proof tbc)

< rucknium:monero.social > Well, I have proven that I don't know the difference between composition and composability ;)

< tevador > kayabanerve: your script/proof should be reviewed.

< rucknium:monero.social > kayabanerve: Is your goal to get loose consensus at this MRL meeting about this expense? Would the work schedule be delayed if we review this quote for another week? AFAIK this meeting is the first time we have this quote and scope of work to review.

< kayabanerve:matrix.org > I don't mind including F-S again if Aaron Feickert or Diego Salazar want to chime in there.

< rbrunner > So, strongly simplified, security should be ok if the proofs that get composed are all ok, because what could go wrong when composing? ...

< kayabanerve:matrix.org > No, my goal is for the MRL to agree it reasonable. Presumably, yes, Diego will not work on this without the contract in hand, so this would delay work.

< diego:cypherstack.com > we at CS would appreciate getting to work on this

< kayabanerve:matrix.org > Considering CS also submitted a distinct quote, their time is in demand and waiting an extra week does impact other milestones.

< kayabanerve:matrix.org > If composed correctly, hence the explicit review towards the desired properties.

< kayabanerve:matrix.org > (assuming they're picked for said distinct quote, but even if not, I have other quotes to request from them)

< tevador > FWIW, I think the audit quote is reasonable and might even result in a more efficient proof, so I'd go for it.

< kayabanerve:matrix.org > I'd be amazed if at the 2.5w mark, something didn't click into being lined up.

< rucknium:monero.social > Personally I would be OK with approving it at this meeting. In the future, if the quote and scope is available before the meeting, try to share it before the meeting.

< rbrunner > I would tend to give my own "go" given that the size is "small" in comparison to the whole "pot"

< kayabanerve:matrix.org > Heard, Rucknium.

_< sgp:monero.social >__ Generally I'm in favor of multiple quotes given how wonky audit prices can be, but this current proposal doesn't concern me

< rbrunner > Agree with Rucknium, especial if we arrive at the bigger parts

< rbrunner > I guess reviewing that "divisor" wizardry will be considerably bigger already?

< kayabanerve:matrix.org > I agree on the value of multiple quotes when I don't see a candidate clearly optimal who responds with a reasonable quote. I personally believe CS optimal for this work and the quote reasonable.

_< sgp:monero.social >__ understood, and those justifications make sense to me

< rucknium:monero.social > I don't see any objections so far for MRL loose consensus on this expense. Anyone else want to say something?

< diego:cypherstack.com > tell me where to send the book

< jeffro256:monero.social > Im okay with CS reviewing FCMP-RCT composition for 175 XMR (including F-S variant)

< tevador > ^ AFAIK only the F-S variant is on the table.

< kayabanerve:matrix.org > tevador is correct.

< jeffro256:monero.social > Even better

< rucknium:monero.social > Is tevador's F-S comment still a loose end?

< tevador > I'm unsure if the provided quote included the F-S property. If not, it should be added.

< kayabanerve:matrix.org > We'd have to ask Diego Salazar Aaron Feickert the impact of them reviewing the premise of F-S (a DLog oracle can find solutions for all components given an arbitrary output, and accordingly can't disprove arbitrary outputs) and to also review said script for sanity. That may be trivial enough, may be a few XMR more?

< aaron:cypherstack.com > If there's a particular design (related to F-S or not) that should be in scope, please ensure it's either included in the referenced technical note or specifically documented otherwise

< aaron:cypherstack.com > That way there's no scope ambiguity

< kayabanerve:matrix.org > It is the in the FCMP++ PDF, including the premise and a link to the supporting script.

< aaron:cypherstack.com > Checking, one sec

< aaron:cypherstack.com > (or if you have the section handy, please let me know)

< aaron:cypherstack.com > Do you mean the link in Section 5.5?

< aaron:cypherstack.com > Oh geez, after quickly reviewing the meeting notes, I assumed you meant Fiat-Shamir...

< aaron:cypherstack.com > you mean forward secrecy

* m-relay <aaron:cypherstack.com> flips a switch somewhere in his brain

< kayabanerve:matrix.org > 5.5

< kayabanerve:matrix.org > Sorry for the delay

< aaron:cypherstack.com > OK, so AIUI the scope, which was originally Section 3 (and anything required from Section 2), should add Section 5.5

< aaron:cypherstack.com > ?

< aaron:cypherstack.com > np

< kayabanerve:matrix.org > Ideally :)

< aaron:cypherstack.com > Sorry for the confusion on F-S :D

< kayabanerve:matrix.org > Sorry for causing it

< aaron:cypherstack.com > I'd say just add a couple of days

< aaron:cypherstack.com > Nah, I was catching up on the meeting notes too quickly :/

< kayabanerve:matrix.org > Diego Salazar: What's the + XMR for that?

< diego:cypherstack.com > Add 23 XMR

< kayabanerve:matrix.org > 198 total then. I'm fine with it, cc jberman tevador Rucknium everyone_else_here

< jberman > +1

< tevador > Looks fine to me.

< aaron:cypherstack.com > For completeness, I'll update that gist to include the relevant sections of the technical note

< aaron:cypherstack.com > Just so nothing slips through the cracks

< rucknium:monero.social > IMHO, at this MRL meeting there is loose consensus for this 198 XMR expense with the Forward-Secrecy modification: https://gist.github.com/AaronFeickert/c24d42d9180ddba515462d4468f25831

< aaron:cypherstack.com > The scope is Sections 2, 3, and 5.5

< aaron:cypherstack.com > (gist updated just now)

< kayabanerve:matrix.org > 👍 then

< rucknium:monero.social > Thank you all! More FCMP++ items to discuss?

< diego:cypherstack.com > Great! We'll start tomorrow.

< kayabanerve:matrix.org > That's it from me

< rucknium:monero.social > Any other business?

< aaron:cypherstack.com > A preview of what my notebook will look like while working on the project :D https://i.kym-cdn.com/entries/icons/original/000/022/524/pepe_silvia_meme_banner.jpg

< rucknium:monero.social > We can end the meeting here.

monero-project / meta

Monero Research Lab Meeting - Wed 15 May 2024, 17:00 UTC #1007

1003