15:14:35 <m-relay> <r​ucknium:monero.social> MRL meeting in this room in about two hours.
17:00:59 <m-relay> <r​ucknium:monero.social> Meeting time! https://github.com/monero-project/meta/issues/1007
17:01:06 <m-relay> <r​ucknium:monero.social> 1) Greetings
17:01:06 <tevador> Hi
17:01:22 <m-relay> <c​haser:monero.social> hello
17:01:23 <rbrunner> Hello
17:01:31 <m-relay> <a​rticmine:monero.social> Hi
17:02:16 <m-relay> <j​effro256:monero.social> Howdy
17:02:52 <jberman> hello
17:03:03 <m-relay> <k​ayabanerve:matrix.org> :wave\
17:04:22 <m-relay> <r​ottenwheel:kernal.eu> Hola.
17:04:26 <m-relay> <s​gp_:monero.social> hello
17:04:32 <m-relay> <h​into:monero.social> hi
17:05:12 <m-relay> <r​ucknium:monero.social> 2) Updates. What is everyone working on?
17:06:12 <m-relay> <k​ayabanerve:matrix.org> Continued work on FCMPs, met with various auditors and got various quotes.
17:06:31 <jberman> me: implementing the curves tree tree in C++ for fcmp's
17:06:34 <tevador> Jamtis specs, mainly forward-secrecy improvements and some updates based on recent discussions.
17:06:39 <m-relay> <r​ucknium: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.
17:08:38 <m-relay> <a​rticmine:monero.social> Working on scaling and fees for ~ 3000 bytes 2/2 tx and 1/2 tx weight
17:10:05 <m-relay> <a​rticmine:monero.social> I do have a question. How does the number of inputs impact tx size under FCMP?
17:10:23 <tevador> I heard ~2.2 KB per input.
17:10:30 <m-relay> <k​ayabanerve:monero.social> It depends if we power of two structure or not.
17:11:17 <tevador> Btw, we could restrict inputs to powers of two with dummy inputs.
17:12:42 <m-relay> <c​haser: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
17:12:45 <m-relay> <k​ayabanerve: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.
17:12:46 <m-relay> <k​ayabanerve:monero.social> matrix.org has notable latency for sent messages :/
17:12:47 <m-relay> <k​ayabanerve:matrix.org> It practically depends on if we want to limit inputs to 16, like we do outputs due to the aggregate range proof.
17:12:49 <m-relay> <k​ayabanerve:matrix.org> And if the performance of any wasted inputs is acceptable.\
17:16:07 <m-relay> <r​ucknium:monero.social> Ah, sorry. I had a problem.
17:16:32 <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.
17:16:32 <m-relay> <r​ucknium:monero.social> 3) Potential measures against a black marble attack
17:17:21 <m-relay> <k​ayabanerve:monero.social> I'll respond to that during the proper section.
17:17:55 <m-relay> <s​gp_:monero.social> The most common number of inputs are: 1, 2, and max for filling the max transaction size ~146
17:18:09 <m-relay> <r​ucknium: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%.
17:18:17 <m-relay> <r​ucknium:monero.social> These transactions could be related to Local Monero's cessation of operations. Maybe these are batched withdrawals.
17:18:41 <m-relay> <r​ucknium: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
17:18:49 <m-relay> <r​ucknium: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
17:18:51 <m-relay> <r​ucknium:monero.social> /out tx types in a realistic "average" block.
17:19:11 <m-relay> <r​ucknium: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.
17:20:40 <m-relay> <r​ucknium:monero.social> 4) Research Pre-Seraphis Full-Chain Membership Proofs. https://www.getmonero.org/2024/04/27/fcmps.html
17:22:14 <m-relay> <r​ucknium:monero.social> By the way, thanks to nioCat for noticing the 1in/16out tx increase first.
17:23:26 <tevador> kayabanerve: any comments on FCMP++ inputs?
17:23:57 <m-relay> <k​ayabanerve: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.
17:24:30 <rbrunner> How do those p2pool payout transactions with 150 outputs fit there? Are they still outside, so to say, because different type of transaction?
17:25:06 <m-relay> <k​ayabanerve:monero.social> On-chain limit is 16 outputs.
17:25:45 <m-relay> <k​ayabanerve:monero.social> So I'm unsure what P2pool is or isn't doing.
17:25:45 <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.
17:25:52 <m-relay> <r​ucknium:monero.social> kayabanerve: For coinbase outputs when FCMP++ is implemented, the limit is 16 outputs?
17:26:15 <m-relay> <c​haser:monero.social> miner reward payouts are a different tx type, aren't they? I've seen 16+ output payouts from p2pool.
17:26:16 <tevador> Coinbase txs have no limit because they have no range proofs.
17:26:21 <m-relay> <r​ucknium:monero.social> A coinbase tx can have a huge number of outputs now.
17:26:25 <m-relay> <a​rticmine:monero.social> Yes. If I understand correctly they are  in the clear.
17:26:44 <m-relay> <a​rticmine:monero.social> Coinbase
17:26:55 <m-relay> <j​effro256: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?
17:27:35 <tevador> IIUIC, 8+4+2+1 is only for storage. The work is still 16.
17:27:49 <m-relay> <k​ayabanerve:matrix.org> Oh, I have no ideas/comments on coinbase outputs.
17:28:02 <m-relay> <k​ayabanerve:matrix.org> FCMP++ only affects the input side of things.
17:28:02 <rbrunner> 23 outputs: https://p2pool.io/explorer/tx/8bf3108a0ac267ca0e5d5ab4c622f05f816b1139f5ed1f9feae7e28445c3fe9a
17:28:55 <m-relay> <k​ayabanerve:matrix.org> jeffro256: 15 * (256 + 128) gates vs 16 * (256 + 128) gates
17:28:58 <tevador> Dummy inputs have some compute overhead due to the need to update the tree root.
17:29:14 <m-relay> <k​ayabanerve:matrix.org> BUT you also have the overhead of the multiple proofs.
17:29:45 <m-relay> <k​ayabanerve:matrix.org> No, 8 + 4 + 2 + 1 does multiple 'setups' (being mutiple proofs) but doesn't waste any multiplication gates.
17:30:44 <m-relay> <j​effro256:monero.social> kk thank you
17:31:02 <m-relay> <k​ayabanerve:matrix.org> Shall I move to discussing audits now?
17:31:06 <m-relay> <r​ucknium: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.
17:31:10 <m-relay> <k​ayabanerve:matrix.org> Er, review/research/audits
17:31:45 <m-relay> <k​ayabanerve: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.
17:32:20 <m-relay> <k​ayabanerve:matrix.org> Those are all 1-input proofs.
17:33:15 <m-relay> <a​rticmine:monero.social> When it comes to verification time we need to consider parallel processing.
17:34:23 <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
17:34:24 <m-relay> <a​rticmine:monero.social> There is a very significant amount of underutilized CPU and GPU power here
17:34:31 <m-relay> <r​ucknium: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.
17:35:29 <m-relay> <a​rticmine:monero.social> Yea!
17:35:56 <tevador> Beware of scope screep.
17:36:06 <tevador> creep*
17:36:26 <m-relay> <k​ayabanerve:matrix.org> I don'
17:36:34 <rbrunner> One after the other :)
17:37:03 <m-relay> <k​ayabanerve: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)
17:37:24 <m-relay> <k​ayabanerve: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
17:37:32 <m-relay> <k​ayabanerve:matrix.org> *4 lists and do verification...
17:37:42 <m-relay> <k​ayabanerve:matrix.org> So it's quite trivial to so parallelize.
17:38:24 <m-relay> <a​rticmine:monero.social> I am talking of verification of different transactions in parallel
17:39:00 <m-relay> <k​ayabanerve:matrix.org> Regarding audits and review, we've collected 4 quotes and are waiting on 2 re: divisor review.
17:39:35 <rbrunner> Quick ELI5 explanation what is a "divisor", maybe?
17:39:56 <rbrunner> Or is it "complicated" anyway
17:40:01 <m-relay> <k​ayabanerve:matrix.org> eli5: something mathemeticians made up, even I don't understand them
17:40:08 <rbrunner> :)
17:40:10 <jberman> *thumbs up* will parallelize verification of FCMP's where trivial as described there, including across txs
17:40:41 <m-relay> <k​ayabanerve:matrix.org> Tbf, I also haven't learned how BP works internally, solely how to use it.
17:40:41 <rbrunner> If they just work, and provably so, who cares :)
17:40:45 <m-relay> <r​ucknium:monero.social> Thanks, jberman :)
17:40:47 <m-relay> <k​ayabanerve:matrix.org> Anyways, I solicited 1 quote from Cypher Stack regarding the composition.
17:41:15 <m-relay> <k​ayabanerve: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'
17:41:37 <m-relay> <k​ayabanerve:matrix.org> (verify it achieves the desired properties, unlinkable, unforgeable, non-malleable linking tags, a correct composition, etc)
17:42:41 <m-relay> <k​ayabanerve:matrix.org> https://gist.github.com/AaronFeickert/c24d42d9180ddba515462d4468f25831 2.5 weeks, 175 XMR was the quote from Diego Salazar
17:43:07 <m-relay> <k​ayabanerve: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.
17:43:42 <m-relay> <k​ayabanerve: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
17:43:43 <m-relay> <k​ayabanerve: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.
17:43:51 <m-relay> <k​ayabanerve:matrix.org> For the relevant paragraph
17:44:55 <jberman> I'm in favor of moving forward with CS for composition review
17:45:05 <rbrunner> Only 2.5 weeks sounds pretty attractive, for whatever this is
17:46:51 <m-relay> <r​ucknium:monero.social> What does "review" mean in the gist?
17:47:06 <m-relay> <k​ayabanerve: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!
17:47:51 <m-relay> <d​iego:cypherstack.com> I've published two novels.
17:47:54 <m-relay> <k​ayabanerve: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.
17:48:17 <m-relay> <d​iego:cypherstack.com> One MRL member gets a free novel if we move forward on this proposal. ;)
17:49:08 <m-relay> <r​ucknium:monero.social> Will we get a security proof of the composability of this system?
17:49:27 <tevador> Forward secrecy should be among the properties to be audited.
17:49:45 <m-relay> <r​ucknium:monero.social> (I barely understand composability on a surface level 😬)
17:50:15 <m-relay> <k​ayabanerve:matrix.org> Diego Salazar: no kickbacks
17:51:21 <m-relay> <k​ayabanerve: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
17:51:34 <m-relay> <k​ayabanerve:matrix.org> (if it was a proof tbc)
17:52:43 <m-relay> <r​ucknium:monero.social> Well, I have _proven_ that I don't know the difference between composition and composability ;)
17:54:17 <tevador> kayabanerve: your script/proof should be reviewed.
17:54:26 <m-relay> <r​ucknium: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.
17:54:37 <m-relay> <k​ayabanerve:matrix.org> I don't mind including F-S again if Aaron Feickert or Diego Salazar want to chime in there.
17:55:05 <rbrunner> So, strongly simplified, security should be ok if the proofs that get composed are all ok, because what could go wrong when composing? ...
17:55:14 <m-relay> <k​ayabanerve: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.
17:55:19 <m-relay> <d​iego:cypherstack.com> we at CS would appreciate getting to work on this
17:55:39 <m-relay> <k​ayabanerve:matrix.org> Considering CS also submitted a distinct quote, their time is in demand and waiting an extra week does impact other milestones.
17:56:18 <m-relay> <k​ayabanerve:matrix.org> If composed correctly, hence the explicit review towards the desired properties.
17:56:27 <m-relay> <k​ayabanerve:matrix.org> (assuming they're picked for said distinct quote, but even if not, I have other quotes to request from them)
17:57:06 <tevador> FWIW, I think the audit quote is reasonable and might even result in a more efficient proof, so I'd go for it.
17:57:07 <m-relay> <k​ayabanerve:matrix.org> I'd be amazed if at the 2.5w mark, something didn't click into being lined up.
17:57:12 <m-relay> <r​ucknium: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.
17:57:26 <rbrunner> I would tend to give my own "go" given that the size is "small" in comparison to the whole "pot"
17:57:27 <m-relay> <k​ayabanerve:matrix.org> Heard, Rucknium.
17:58:01 <m-relay> <s​gp_: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
17:58:15 <rbrunner> Agree with Rucknium, especial if we arrive at the bigger parts
17:58:49 <rbrunner> I guess reviewing that "divisor" wizardry will be considerably bigger already?
17:59:11 <m-relay> <k​ayabanerve: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.
17:59:32 <m-relay> <s​gp_:monero.social> understood, and those justifications make sense to me
17:59:41 <m-relay> <r​ucknium:monero.social> I don't see any objections so far for MRL loose consensus on this expense. Anyone else want to say something?
18:00:42 <m-relay> <d​iego:cypherstack.com> tell me where to send the book
18:00:49 <m-relay> <j​effro256:monero.social> Im okay with CS reviewing FCMP-RCT composition for 175 XMR (including F-S variant)
18:01:38 <tevador> ^ AFAIK only the F-S variant is on the table.
18:02:00 <m-relay> <k​ayabanerve:matrix.org> tevador is correct.
18:02:11 <m-relay> <j​effro256:monero.social> Even better
18:03:54 <m-relay> <r​ucknium:monero.social> Is tevador's F-S comment still a loose end?
18:04:50 <tevador> I'm unsure if the provided quote included the F-S property. If not, it should be added.
18:04:52 <m-relay> <k​ayabanerve: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?
18:08:39 <m-relay> <a​aron: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
18:08:46 <m-relay> <a​aron:cypherstack.com> That way there's no scope ambiguity
18:09:00 <m-relay> <k​ayabanerve:matrix.org> It is the in the FCMP++ PDF, including the premise and a link to the supporting script.
18:09:38 <m-relay> <a​aron:cypherstack.com> Checking, one sec
18:09:48 <m-relay> <a​aron:cypherstack.com> (or if you have the section handy, please let me know)
18:11:01 <m-relay> <a​aron:cypherstack.com> Do you mean the link in Section 5.5?
18:11:46 <m-relay> <a​aron:cypherstack.com> Oh geez, after quickly reviewing the meeting notes, I assumed you meant Fiat-Shamir...
18:11:50 <m-relay> <a​aron:cypherstack.com> you mean forward secrecy
18:12:05 * m-relay <a​aron:cypherstack.com> flips a switch somewhere in his brain
18:13:03 <m-relay> <k​ayabanerve:matrix.org> 5.5
18:13:06 <m-relay> <k​ayabanerve:matrix.org> Sorry for the delay
18:13:07 <m-relay> <a​aron:cypherstack.com> OK, so AIUI the scope, which was originally Section 3 (and anything required from Section 2), should add Section 5.5
18:13:18 <m-relay> <a​aron:cypherstack.com> ?
18:13:20 <m-relay> <a​aron:cypherstack.com> np
18:13:21 <m-relay> <k​ayabanerve:matrix.org> Ideally :)
18:13:23 <m-relay> <a​aron:cypherstack.com> Sorry for the confusion on F-S :D
18:13:26 <m-relay> <k​ayabanerve:matrix.org> Sorry for causing it
18:13:27 <m-relay> <a​aron:cypherstack.com> I'd say just add a couple of days
18:13:37 <m-relay> <a​aron:cypherstack.com> Nah, I was catching up on the meeting notes too quickly :/
18:14:11 <m-relay> <k​ayabanerve:matrix.org> Diego Salazar: What's the + XMR for that?
18:14:19 <m-relay> <d​iego:cypherstack.com> Add 23 XMR
18:14:44 <m-relay> <k​ayabanerve:matrix.org> 198 total then. I'm fine with it, cc jberman tevador Rucknium everyone_else_here
18:15:06 <jberman> +1
18:15:10 <tevador> Looks fine to me.
18:15:25 <m-relay> <a​aron:cypherstack.com> For completeness, I'll update that gist to include the relevant sections of the technical note
18:15:39 <m-relay> <a​aron:cypherstack.com> Just so nothing slips through the cracks
18:16:13 <m-relay> <r​ucknium: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
18:16:43 <m-relay> <a​aron:cypherstack.com> The scope is Sections 2, 3, and 5.5
18:17:34 <m-relay> <a​aron:cypherstack.com> (gist updated just now)
18:18:02 <m-relay> <k​ayabanerve:matrix.org> 👍️ then
18:18:23 <m-relay> <r​ucknium:monero.social> Thank you all! More FCMP++ items to discuss?
18:18:25 <m-relay> <d​iego:cypherstack.com> Great! We'll start tomorrow.
18:20:02 <m-relay> <k​ayabanerve:matrix.org> That's it from me
18:21:06 <m-relay> <r​ucknium:monero.social> Any other business?
18:21:33 <m-relay> <a​aron: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
18:22:50 <m-relay> <r​ucknium:monero.social> We can end the meeting here.