<r​ucknium:monero.social> Meeting time! monero-project/meta #1030

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

<a​aron:cypherstack.com> Hello

hello

Hello

hi

<h​into:monero.social> hi

<c​haser:monero.social> hello

<k​ayabanerve:monero.social> 👋

hi

*waves*

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

<r​ucknium:monero.social> me: Helping with stressnet. And I have the visualization of the two new solution concepts for best fee and ring size for defense against black marble attacks.

me: misc. stressnet tasks

a number of bug fixes to LWS and ZMQ. Re-started "frontend" lib work for LWS (after hearing the wallet2 update)

me: fcmp grow_tree and trim_tree algorithms

<0​xfffc:monero.social> Hi

<k​ayabanerve:monero.social> Soliciting quotes to review the divisor proof, one already acquired. Both should be here by Monday. We're also trying to move forward with the divisor R1CS specification.

<k​ayabanerve:monero.social> *specification review.

kayaba, if you need auditor intros/recommendations, i can help with that

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

The main thing to share is that we experienced serious issues with larger blocks. Consistent ~1.5MB blocks required lowering '--block-sync-size' for block propagation and network synchronization to function.

Each miner was isolated to separate chains and other nodes could not sync until the change was made.

<r​ucknium:monero.social> spackle, do you want to discuss stressnet?

<d​iego:cypherstack.com> Hi

That is the brief overview. Rucknium performed an investigation on the limits of the current software, and I imagine they would like to speak on it: gist.github.com/Rucknium/f092b0ad5870f6038226c39af529152c

<r​ucknium:monero.social> Right. By default, monerod has `--block-sync-size` set to 20 for recent (last several years) blocks on mainnet. A chunk of 20 blocks was too much once block size reached 1.5MB.

<r​ucknium:monero.social> I lowered it one unit at a time. I was able to sync once I set it to 14. Roughly, I think that monerod can sync block chunks when they are 20-25MB and lower.

<r​ucknium:monero.social> If this happened on mainnet, probably there would be a netsplit and chainsplit until a lot of the network restarted their nodes with a lower `--block-sync-size`

And it seems the daemon isn't "aware" that there is a problem, does not error out, does not warn, just does not progress anymore?

<r​ucknium:monero.social> It just says "Sync data returned a new top block candidate: 2521517 -> 2524276 [Your node is 2759 blocks (3.8 days) behind]" again and again. And then starts banning peers.

Splendid :)

<c​haser:monero.social> do we know if this limitation is imposed by the amount of data or the amount of computation? similar behavior was observed with ~300 kB mainnet blocks with 150-in/few-out transactions.

<r​ucknium:monero.social> I didn't try to turn on deeper log levels. The problem is reliably reproducible on stressnet if you pop blocks down to before the block size "hill". Developers can turn on the appropriate log levels and categories

log-level 2 would yield useful info here, and obviously would be nice to have someone focus on this asap

<r​ucknium:monero.social> In the newest release on stressnet, I just set the value to `1` to make sure it syncs ok: spackle-xmr/monero #8

<r​ucknium:monero.social> You can see where in the code the defaults are controlled. It is sort of a very basic control based on hard-coded block heights.

Thankfully it would be quite expensive to push blocksize up to that "hill" on mainnet

<c​haser:monero.social> (and on mainnet, `--block-sync-size 1` also got rid of the problem)

<r​ucknium:monero.social> spackle, do you have an estimate on how much in fees it would take with the minimum fee (20 nanoneros/byte)?

Certainly expensive to do quickly.

Not on hand, one moment...

what are this machine's specs?

<r​ucknium:monero.social> I pushed up block size to 1.5MB quickly by spamming priority 4 (highest) fees on stressnet.

<r​ucknium:monero.social> Here's a plot of the block sizes during the stress testing: github.com/spackle-xmr/chaindata_gr…ain/stressnet_block_size_26_JUN.png

<r​ucknium:monero.social> And here is spackle's one-week report: reddit.com/r/Monero/comments/1doyde9/stressnet_first_week_report

I don't quite understand the axes on that plot ...

<r​ucknium:monero.social> jberman: The machine that I used for the testing here gist.github.com/Rucknium/f092b0ad5870f6038226c39af529152c ?

yes

<r​ucknium:monero.social> It's one of the Monero Research Computing Cluster's machines: 3900x 24 thread, 32GB ram, 1TB nvme.

<r​ucknium:monero.social> It only had outgoing connections.

got it

A quick simulation shows min fees would expand the block size to 1.66MB in 8500 blocks at a cost of ~107 XMR.

*after 8500 blocks

<r​ucknium:monero.social> rbrunner: AFAIK, the vertical is number of bytes in a block and the horizontal is just number of blocks since the stressnet testing started last Wednesday.

Ok, thanks

<r​ucknium:monero.social> spackle: Thanks a ton for all your work on that simulation code that can give us an answer so quickly :)

I'll be the first to say it is not perfect, but I do think it paints a generally accurate picture.

So in less than 2 weeks and for less than USD 20'000 you can aspire and try to bring the Monero network to partial standstill.

<r​ucknium:monero.social> That's about 12 days. I think what we are doing on stressnet now is just spamming minimum fees and seeing the growth rate of the blocks.

Pretty sobbering.

<r​ucknium:monero.social> Here my webapp that shows live stressnet data: monitor.stressnet.net

<r​ucknium:monero.social> rbrunner: I agree. Stressnet has shown the issue. Now software engineers can decide what to do about it :)

<r​ucknium:monero.social> You could have a quick fix by lowering the default values or look into what causes the problem deeper.

It may well be that the correction will be quite easy, once the problem is on the table.

<r​ucknium:monero.social> Some other things: Node startup with a large txpool (600MB) takes about an hour. 0xfffc wrote a patch that decreased the time by 2-5x. Thank you! Still, that's slow, and it can be worked on more AFAIK. Node<->wallet connects are hard to establish when the txpool is very large, too.

<r​ucknium:monero.social> Anything else about stressnet? Stressnet conversation happens in #monero-stressnet:monero.social and ##monero-stressnet on IRC

<p​reland:monero.social> Cmon guys let’s reach 1m pending in mem_pool 🔥

<p​reland:monero.social> (Btw gigabytes and bytes look the same on the monitor)

if another dev isn't on this by next week's MRL meeting, I'll shift priority from fcmp's to this barring objection

<0​xfffc:monero.social> Parallelization of startup txpool load, is indirectly related to rwlock. So I went back to rwlock work.

<0​xfffc:monero.social> If we merge rwlock, we can write parallelization of txpool load. Which would even speed it up substantially

<r​ucknium:monero.social> preland: The default txpool size is about 600MB. That gets about 250,000 txs. We can't get higher without increasing the default (can be changed with a flag at startup)

<h​into:monero.social> 0xfffc: what causes txpool loading to take that long? curious on the details

<r​ucknium:monero.social> preland: Thanks for input. The monitor is a rough draft. I haven't done anything with the units yet. B = "billion".

<0​xfffc:monero.social> we are validating every txis.

<h​into:monero.social> and it is done sequentially?

<r​ucknium:monero.social> AFAIK, single-threaded 😎 (the sunglasses are ironic)

<r​ucknium:monero.social> The CPU load is on one thread at startup

<r​ucknium:monero.social> You could probably do batch verification, too, AFAIK

<r​ucknium:monero.social> The startup time is inconvenient, but it's potentially a bigger problem if nodes shut down during high tx volumes, then they need a long time to restart.

<r​ucknium:monero.social> The stressnet node release is running 0xfffc 's patch already

<r​ucknium:monero.social> We had about 40 nodes on stressnet at the start. Maybe 25-30 now.

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

<0​xfffc:monero.social> yes, of course.

<0​xfffc:monero.social> github.com/monero-project/monero/bl…c/cryptonote_core/tx_pool.cpp#L1793

<r​ucknium:monero.social> I updated black-marble-defense-params.redteam.cash with visualizations for the two new solution concepts. The first is the best fee and ring size at a specific effective ring size. The second is the best fee and ring size at a specific "budget" for Alice, i.e. the total cost of aggregate tx fees plus the cost of storage to node operators.

<r​ucknium:monero.social> I think sgp_ was interested in this.

<r​ucknium:monero.social> These solution concepts align with the expectation that as node storage costs are higher (i.e. adjust the `m` parameter up), it is more attractive to defeat black marbles by raiding the fee instead of raising the ring size.

<r​ucknium:monero.social> We don't have much time in the usual hour, so we can move to FCMP

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

<r​ucknium:monero.social> kayabanerve: ^

<k​ayabanerve:monero.social> 👋

<k​ayabanerve:monero.social> Aaron also has news beyond my own.

<a​aron:cypherstack.com> Cypher Stack has complete its FCMP++ report and provided a draft to kayabanerve

<a​aron:cypherstack.com> Cypher Stack has completed its FCMP++ report and provided a draft to kayabanerve

<r​ucknium:monero.social> Great!

<k​ayabanerve:monero.social> I only saw after the meeting started, hence my lack of announcement in intro, apologies there.

<a​aron:cypherstack.com> Once any issues are addressed and inevitable typos fixed, we'll get it posted to GitHub (along with TeX source)

<k​ayabanerve:monero.social> Delivered this morning though :)

good news :)

<a​aron:cypherstack.com> The gist is that the technique should be suitable for its intended use case, given some conditions on how proving systems are instantiated

<a​aron:cypherstack.com> We also proved an optimization secure

<k​ayabanerve:monero.social> I'm still reading through, so I apologize I can't immediately provide my own summary.

Almost suspicious how clear the FCMP sailing has been so far :)

<k​ayabanerve:monero.social> My notation has been thoroughly critiqued.

<k​ayabanerve:monero.social> Yet we now have GBP proofs (which I'm soliciting review for), divisor proofs (also soliciting review for), and the composition proofs (I say as I read through the document supposedly with them).

<k​ayabanerve:monero.social> Once we get the necessary secondary reviews for GBPs/divisors, we should be able to move forward with audits on each.

<k​ayabanerve:monero.social> And with the divisor R1CS spec being reviewed, we can then request Veridise to do formal verification of the rest of our spec or do it ourselves before moving to auditing there.

<k​ayabanerve:monero.social> I don't have much more to say on this end. jberman may on the integration side?

hoping to have a documented spec of the grow_tree and trim_tree implementations within the next 2 weeks. haven't been particularly simple to implement

<k​ayabanerve:monero.social> Mind if I ping you on your thoughts about the rust ffi side of things 👀 Been fine, been a leading cause of issues...?

<s​gp_:monero.social> cool stuff! Thanks for adding that dot to the graph

hah course. ffi stuff has been mostly fine, it's more capturing the edge cases on the algo side unrelated to the ffi

<k​ayabanerve:monero.social> I want it on the record Rust is mostly fine :p

<r​ucknium:monero.social> sgp_: If you sweep the two lines through the plot area, you get similar optima because they are both downward-sloping lines. The main difference between the two solutions is the effective ring size line is more convex (higher second derivative) than the budget line.

<r​ucknium:monero.social> We can end the meeting here. Thanks everyone.

<a​aron:cypherstack.com> Excited to share the FCMP++ report once it's reviewed :D

<e​msczkp:matrix.org> Hi everyone, sorry I'm late (chat and logs is not working). Few updates on my side: i worked on multi-exp, compressed sigma IPA provides effectively the multi-exp now. I'll test on the kayabaNerve fcmp github repo my solution, also with batching, and compare it. I'll keep you updated ...

<e​msczkp:matrix.org> I haven't asked for funds yet. We could discuss it when I see improvements in verification times of 5-10% (as kayabanerve said), right ?

<r​ucknium:monero.social> libera.monerologs.net is giving 504 error for me

<k​ayabanerve:matrix.org> I'd be interested in moving forward with it if it benefited performance 5-10%. That'd be non-trivial, and due to it being a drop-in replacement (not redoing all the GBP work), it'd potentially be feasible to review within our time span. I'd have to see that time for myself to ask the community thought's on the effort, and then we'd be discussing paying for review of the proof to e<clipped message

<k​ayabanerve:matrix.org> nsure its security holds.

<k​ayabanerve:matrix.org> I don't want to trouble you with the dev work on your end, if it is something you're unfamiliar with. I'm truly happy to take the responsibility there :) I just have to sit down and do it 😅

<a​aron:cypherstack.com> You mean this is a drop-in replacement of the BP IPA?

<a​aron:cypherstack.com> And therefore could be reviewed independently?

<k​ayabanerve:matrix.org> Yep, which I wrote as a dedicated proof already. Should be feasible within just 100 lines or so.

<k​ayabanerve:matrix.org> Yep, GBPs would remain.

<k​ayabanerve:matrix.org> *I impl'd as a dedicated proof already

<k​ayabanerve:matrix.org> I believe it already has security proofs for the same properties as the BP IPA, emsczkp obviously the better person to confirm with.

<a​aron:cypherstack.com> I would certainly be interested in conducting such a review :D

<p​reland:monero.social> Yeah I understood that—though it did make me scratch my head for a second when the total blockchain size was 10.3 bytes

<k​ayabanerve:matrix.org> So we'd be doing proof review _if_ the performance justifies it as more than a point of interest not worth the political capital and effort on.

<k​ayabanerve:matrix.org> (not to be rude to the theory. I actually quite like a design done without the inversions. I just already have had "scope creep" discussions and a distinct IPA is right on that fence :p )

<k​ayabanerve:matrix.org> But yeah, 5-10% off the FCMP++ verification would be non-negligble and very worth discussng.

<a​aron:cypherstack.com> The security proof given for that protocol is not nearly as detailed as the original BP IPA

<e​msczkp:matrix.org> thanks kayabaNerve. Yes the security proofs are there and I have also extended them, I would be happy if anyone wants to discuss it. I would like to personally test the solution on fcmp, also to avoid committing your effort before being 5-10% verif sure

<a​aron:cypherstack.com> Oh, you expanded on the proofs to provide better detail?

<e​msczkp:matrix.org> Yes!

<a​aron:cypherstack.com> Nice

<a​aron:cypherstack.com> Are you one of the original authors as well?

<a​aron:cypherstack.com> (if you care to say)

<a​aron:cypherstack.com> I'd be interested to see the updated proofs, for sure

<e​msczkp:matrix.org> I'm the author

<a​aron:cypherstack.com> Apologies if this was discussed earlier, but is there a reason why you'd expect to see practical efficiency benefits, given that inversions are batched?

<k​ayabanerve:matrix.org> It mainly has benefits for the prover who has reduced MSMs while proving.

<a​aron:cypherstack.com> Ah, I see

<a​aron:cypherstack.com> I was only considering the verifier

<k​ayabanerve:matrix.org> For the verifier, it removes... 24 inversions at our scale?

<a​aron:cypherstack.com> If you're batching, you only have one actual inversion

<k​ayabanerve:matrix.org> Sure, yet that's still 256 scalar muls knocked out.

<a​aron:cypherstack.com> (although you do more muls)

<a​aron:cypherstack.com> So the 5-10% informal target was for proving, ya?

<a​aron:cypherstack.com> Not verifying?

<e​msczkp:matrix.org> the multi-exp on verfier should save several MSMs too

<a​aron:cypherstack.com> Even when combining challenges to a single MSM?

<e​msczkp:matrix.org> my target would be the verifier, but the prover should also benefit if I'm not mistaken

<e​msczkp:matrix.org> Yess I see many msm saved

<a​aron:cypherstack.com> I'm thinking in terms of Equation 105 in the BP preprint (page 29)

<a​aron:cypherstack.com> Where would the savings come from in that case?

<e​msczkp:matrix.org> this in multi-exp but I want to see batching too, I will work on this in the next few days

<a​aron:cypherstack.com> Just from the `L`- and `R`-type terms?

<a​aron:cypherstack.com> Surely you wouldn't get anything from the generators if you're doing generating combining?

<a​aron:cypherstack.com> *challenge combining

<a​aron:cypherstack.com> I think the most helpful thing for investigating verifier performance would be something akin to Equation 105

<a​aron:cypherstack.com> (of course, it would be for the AC protocol)

<e​msczkp:matrix.org> I should calculate the challenges more lightly, this from multiexp if I remember equation 105

<k​ayabanerve:monero.social> My target was the verifier. I'll also bench prover yet I'd need much higher prover perf to justify that. Most of our proving time isn't IPA dominated AFAIK yet the divisor Poly's.

<k​ayabanerve:monero.social> The verifier saving MSMs is notational, not practical.

<k​ayabanerve:monero.social> I'd be surprised by 5-10% verifier perf increase. I wouldn't be surprised by that much on the prover. I'd want the prover to be 20+% though.

<k​ayabanerve:monero.social> (And again, that may due 50% off the IP A, but I can only care about the entire FCMP++ membership proof)