<rucknium> MRL meeting in this room in two hours.

<neptunian:unredacted.org> I forgot the meeting was at 17:00 and thought it was 12:00 so I thought I had overslept lmao.

<gingeropolous> I'ma kinda be here

<ravfx:xmr.mx> o/

<rucknium> Meeting time! monero-project/meta #1415

<rucknium> 1. Greetings

<neptunian:unredacted.org> Hello, all.

<syntheticbird> Hi

Hello

<emsczkp:matrix.org> hello

<redsh4de:matrix.org> Hi

<jberman> waves

<vtnerd> hi

<jeffro256> Howdy

<boog900> Hi

<rucknium> 2. Updates. What is everyone working on?

<rucknium> me: Keeping stressnet stressed and investigating bugs.

<sgp_> Hello

<vtnerd> me: going through claude reports (via @sgp_) on monero-lws, lwsf, and fhse repos

<neptunian:unredacted.org> Some FHE shenanigans and stuff related to Raccoon-G.

<jeffro256> me: reworked a large portion of the Carrot libraries to support making OutProofV2 proofs to selfsends (currently possibly but unused behavior in wallet2)

<jberman> Me: finalized the first set of FCMP++ integration PR's that were audited (thank you to UkoeHB for reviewing), continued investigating @rucknium:monero.social 's observed sporadic wallet errors (the double spend issue) and identified a bug and suspected culprit, reviewed @jeffro256:monero.social 's hot-cold FCMP++/Carrot PR + other upstream PR's for next release, prepping stressnet v2.1

<jeffro256> me: reviewing PRs and going through views of my upstream PRs

<rucknium> 3. emsczkp research Bulletproofs* Milestone 2 completed (repo.getmonero.org/monero-project/c…als/-/merge_requests/626#note_36734).

<jpk68:matrix.org> Hello

<gingeropolous> Me: trying to see if monerosim is done

<rucknium> Last time @emsczkp:matrix.org discussed his progress. @jberman:monero.social intended to look at the revised paper IIRC.

<emsczkp:matrix.org> I have nothing to add beyond what said during the previous meeting. It was great to see positive comments on socials

<jberman> I haven't had a chance to dive, but the revised paper (and proofs) looks solid

<neptunian:unredacted.org> @jberman: ++

<jberman> I think once the work is complete, it'll make sense to get another maths review on it, similar to how we've done for FCMP++

<jberman> But reiterating, looking like great progress, and exciting results! Well done @emsczkp:matrix.org

<emsczkp:matrix.org> thank you!

<rucknium> Last meeting, @emsczkp:matrix.org asked whether it is OK to payout Milestone 2 of his CCS at this point or if more review is necessary.

<jberman> I'm a +1 on payout

<emsczkp:matrix.org> @rucknium: Exactly, thank you for the clarification

<rucknium> @emsczkp:matrix.org: When the paper is complete, do you intend to submit it to a peer-reviewed journal or conference?

<emsczkp:matrix.org> @rucknium: yes, that's the goal

<rucknium> That wouldn't necessarily be as rigorous as MRL would like it, but it would be at least another set of critical eyes on it.

<rucknium> I mean, if the results were to be used in actual production Monero code.

<rucknium> I am +1 on payout too, but I have not tried to understand the paper. Any other opinions here?

<emsczkp:matrix.org> Exactly, and I’ll work on a submission to the first major conference on the subject asap

<rucknium> @emsczkp:matrix.org: Thank you.

<neptunian:unredacted.org> @emsczkp:matrix.org: Hope to see you at EUROCRYPT :-)

<emsczkp:matrix.org> Thank you, community, for the support on this reseach , which I strongly believe in and it is a very long story to me

<rucknium> luigi1111 luigi1111_ : FWIW, we have support in this MRL meeting to payout @emsczkp:matrix.org Milestone 2 of repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/626

<rucknium> More discussion on this item?

<rucknium> Thanks, @emsczkp:matrix.org

<rucknium> 4. Post-quantum encryption (monero-project/research-lab #151#issuecomment-4412416686). Jamtis (gist.github.com/tevador/639d083c994…32#appendix-c-instant-sync-protocol).

No updates from me today.

<neptunian:unredacted.org> Have there been any changes in regards to CSIDH and the security level assumptions?

<neptunian:unredacted.org> I haven't kept up with it, apologies.

<jberman> Not to my knowledge

I haven't seen any papers regarding that

<neptunian:unredacted.org> I have no further comments in that case. I don't feel the need to try to find other primitives to use here, as I like CSIDH currently.

<rucknium> 5. FCMP beta stressnet (github.com/seraphis-migration/monero/releases).

<rucknium> DataHoarder set up a view key scanner on stressnet: stressnet.p2pool.observer/payments

<jeffro256> Thanks to @j-berman for reviewing the hot/cold PR. It is in a good spot, I don't know if it will make it into v2.1, but I feel like it should be ready v soon

<jeffro256> Lots of review/implementation going on there

<jberman> Aiming to put v2.1 out today or tomorrow that fixes the window GUI binary, hopefully also fixes the observed sporadic double spends as well

<rucknium> And I provided the view keys to my spamming wallets. I have a basic set of tables at the bottom of stressnetnode1.redteam.cash that help me see which of my spam wallets are actually getting txs into blocks.

<jberman> (The latter appears to be an upstream issue)

<jeffro256> @j-berman also debugged several issues with the daemon and RPC, reviewing those fixes

<rucknium> @jeffro256:monero.social: Is the hot/cold PR the same one that speeds up getblock.bin?

<jeffro256> Completely separate

<jeffro256> The hot/cold wallet PR is here: seraphis-migration/monero #52

<jeffro256> The RPC speedup PR is here: monero-project/monero #10605

<rucknium> More discussion about stressnet?

<jeffro256> j-berman did some really interesting profiling of LMDB related to 10605. I think that I might try to really reduce the complexity of that PR

<jeffro256> Then, in a separate PR, implement the separate pruned/prunable mempool database tables approach. The only thing I'm worried about is if it'll make normal daemon block processing slower

<jeffro256> After PR 9135, bulk block processing will skip the mempool, so it wouldn't apply their, but it would to top block propogation times (maybe)

<jberman> I suspect impact to normal sync will be close to negligible

<jeffro256> I hope so

<rucknium> I am excited for the speedup :)

<rucknium> Thanks for all the work on it, including reviewers

<jeffro256> If LMDB has a large readahead, I can see that once the blockchain code starts touching prunable blobs during top block propgation, then the reads will be in-memory, and then the only additional overhead would be the 2x key lookups

<jeffro256> So I can see it being negligible, but we'll see

<jeffro256> At a certain point, trying to theorize about performance, w/o a demo, and with so many moving parts is basically astrology

<rucknium> Does stressnet provide enough of a demo envionment?

<jeffro256> Yeah I'd definitely say so

<jberman> It took 0.1s in that demo to read 20k keys and also the pruned blobs

<jeffro256> I can't remember, was the

<jeffro256> keys read in series, or was it lookup from the root each time?

<jeffro256> in the demo

<rucknium> Crazy idea: Could I just apply that PR to the stressnet node code and hope it speeds up my spamming?

<jberman> It's read in order, though I also tested locally with random read order and it was roughly equivalent

<jeffro256> @Rucknium Yeah go for it, I don't think it should have any conflicts with other open PRs beside 10761

<rucknium> Awesome. Thank you.

<rucknium> More discussion of this item?

<rucknium> 6. monerosim (github.com/Fountain5405/monerosim).

<rucknium> Is @gingeropolous:monero.social here?

<gingeropolous> Hi! Yep, here

<rucknium> I think you were doing a tedious grid search for network parameters that would get closest to mainnet behavior.

<gingeropolous> Yes, your review encouraged me to investigate the delta and see if I could narrow it

<rucknium> What are your findings so far?

<gingeropolous> I think it has been narrowed. I'm remote so I can't really link things right now, but the detailed findings can be found on the repo

<gingeropolous> But yeah, the general idea seemed to be the 100% reachable network has a different behavior than mainnet, and the always on network in the sim also modified things

<gingeropolous> So, those parameters can be toggled and managed via the config files for sim generation

<rucknium> Fantastic. How was the unreachable nodes implemented?

<gingeropolous> Just adding the --hide-my-port.

<rucknium> Do you think you would have different results if trying --in-peers=0?

<gingeropolous> As I'm typing it, I realize I could also also do it from the host level, as in each shadow thing could function as a firewall for that virtual entity

<rucknium> in-peers would probably be stricter. Or combining them

<rucknium> @gingeropolous: Is that easy to do? That would probably mimic the actual network setup most closely

<gingeropolous> Dude, yeah, it's a sim. We could test parameters for as long as the machines spin , and I look forward to doing so!

<gingeropolous> Yeah, I could add that in.

<rucknium> Because most unreachable are unreachable because of their NAT or similar external setup, not because of their monerod flag config options

<gingeropolous> Indeed. I guess we could also mimic the ... Effective of that UPNP punch through or whatever? Because monero still tries, right? And sometimes it works.... Or just flat default firewall... Though I guess that can just get swallowed up in the config setting of % reachable ".....

<rucknium> I don't know too much about the UPNP punch through, but maybe someone who does know could comment.

<rucknium> Any more discussion of this agenda item?

<gingeropolous> So I'm still not at the milestone? What do we think, 98%, 70%..... 🤗

<rucknium> I think you are

<sneedlewoods_xmr:matrix.org> I don't think we use upnp anymore monero-project/monero #10012

<rucknium> We can end the meeting here. Thanks everyone.

<jeffro256> Thanks everyone

<gingeropolous> Thank you all!

19:32:54 <br-m> <rucknium> DataHoarder set up a view key scanner on stressnet: stressnet.p2pool.observer/payments

FYI I support carrot-native scanning as well, if any of those were running. JSON is available in stressnet.p2pool.observer/payments.json which provides some further details, including TxProofV2 (InProof)

<rucknium> I forgot to say that DataHoarder has it for mainnet, too. Has the General Fund, CCS, Magic, and Bounties view keys at least: blocks.p2pool.observer/payments