<emsczkp:matrix.org> Hi everyone, i just want to let the community know about the new update:

<emsczkp:matrix.org> repo.getmonero.org/monero-project/c…als/-/merge_requests/626#note_36734

<rucknium> @emsczkp:matrix.org: Thank you. Do you want me to put your update on today's MRL agenda?

<emsczkp:matrix.org> Yes, thank you

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

<gingeropolous> unfortunately I won't be able to attend live during the meeting. But I'm continuing to push monerosim towards mainnet fidelity. Current results here: github.com/Fountain5405/monerosim/b…/20260620_network_topology_study.md . TL;DR, it seems the hypothesis was right, that a 100% reachable network behaves differently than main net.

<gingeropolous> the sim currently running is the "churning" - nodes turning on and off throughout the sim, as opposed to always on.

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

<rucknium> 1. Greetings

<emsczkp:matrix.org> Hello

Hello

<jberman> waves

👋

<jpk68:matrix.org> Hello

<syntheticbird> Hello

<jeffro256> Howdy

<articmine> Hi

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

<syntheticbird> me: warning people to STAY HYDRATED 🚰

<jeffro256> me: reviewing upstream PRs, implementing feedback for FCMP++/CARROT PRs, writing documentation for existing code

<rucknium> me: Keeping stressnet stressed with transaction spam. Helping identify stressnet bugs.

updated my tooling and go-p2pool test to support beta stressnet (which works vastly better than alpha for the purposes of mining, so far, even with the current tx spam levels)

<jpk68:matrix.org> Making some patches, and have also ostensibly finished the daemon integration for I2P SAM. Waiting on sone feedback :)

<jberman> me: continuing reviewing jeffro's Carrot/FCMP++ hot-cold wallet PR, continuing investigating the observed stressnet wallet double spend error with @rucknium:monero.social's help

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

<emsczkp:matrix.org> Hi everyone! this updated version of the paper provides the proofs of the main theorems establishing the security of the BP* folding scheme. In particular, Theorem 1 proves that the modified AC proof for Bulletproofs is complete, HVZK, and special sound. Before introducing the BP* folding scheme, the paper presents an intermed [... too long, see mrelay.p2pool.observer/e/-6bkoJALcmlnOWtT ]

<emsczkp:matrix.org> The revised version also includes some changes with respect to the previous draft. In particular, it introduces a new algebraic verifier map V^comm and its relaxed version. This required the introduction of additional error terms in both the accumulator and the accumulation proof.

<emsczkp:matrix.org> Overall, the main purpose of this step is the security proof

<emsczkp:matrix.org> I've added more details in the GitLab update comment

<jberman> sounding like great progress!

<rucknium> @emsczkp:matrix.org: Thank you! After completing Milestone 2, did you uncover anything that makes Milestone 3 (extend Bulletproofs* to Generalized Bulletproofs) more difficult or easier?

<emsczkp:matrix.org> thanks, for the step 3 i think it will be appropriate to go into detail about GBP's relation and security proofs, but the folding scheme now appears to me extendable to GBP

<emsczkp:matrix.org> i can't say for sure, but i see good foundations

<rucknium> Do you have more discussion of this item or questions for @emsczkp:matrix.org at this time?

<rucknium> Thank you, @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).

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

I have no significant updates for today.

<rucknium> Anyone else have comments or questions on this item?

I think that with the implementation of Polyseed in the official wallet (big thanks to rbrunner), it makes sense to directly implement Jamtis and skip the Carrot hierarchy to save 1 Polyseed bit.

You mean no "Carrot key hierarchy" feature bit, but a "Jamtis" feature bit?

Yes, exactly

<jeffro256> tevador: I disagree, I still think that there's value in having a hierarchy with enchanced features and some quantum privacy which is backwards compatible and indistinguishable from existing addresses

<articmine> What would be the impact on the timing of the HF here?

<jberman> I don't think we need to make a decision on that until FCMP++ / Carrot (without the Carrot key hierarchy) is 100% merged upstream in the first place. It'll be a question of what to work on/prioritize next at that point/what the timeline to Jamtis versus Carrot hierarchy would be expected to be

Jamtis is strictly superior to the Carrot key hierarchy

Well, skipping the Carrot key hierarchy and go directly to Jamtis is of course a much bigger question than any feature bits alone :)

<jberman> @articmine: 0 impact

The only reason to introduce an intermediate wallet type would be if Jamtis was severely delayed for some reason (I don't forsee that at the moment).

Looks like a hard decision to me. Both pathes have advantages and disadvantages

<jpk68:matrix.org> FWIW, having multiple intermediate addressing protocols (which will each presumably be used for just a few years) in the codebase would seemingly create quite a large attack surface, and that code will have to be maintained forever if we are to keep restore functionality

Just wondering, couldn't a switch to Jamtis get complicated if it should turn out that it brings a significant performance hit?

<jeffro256> tevador: Except in metrics that I previously mentioned: backwards compatability, and by extension, ease of implementation, and indistinguishability

Do we have already any idea how Jamtis might perform

<jeffro256> "Details table" section in monero-project/research-lab #151#issuecomment-4281932714

"Just a few years" is quite a lot in the life of a cryptocurrency, as they develop today, if you ask me

jeffro256: no protocol with the features of Jamtis can compete on those metrics. But you are technically correct. However, Carrot is also beaten by CryptoNote on the 'ease of implementation' metric.

19:25:56 <tevador> Jamtis is strictly superior to the Carrot key hierarchy

the reason for Carrot though is being still backwards compat with address format as mentioned

Ah, yes, sorry I forgot this table. Where we ruled out schemes that would run for freaking hours!

Jamtis scanning performance should be roughly on par with Carrot, except for wallets with a lot of received external payments that need CSIDH decryption.

<articmine> What about TX sizes?

<jeffro256> Unpruned parts of the tx (the part that wallets download) would be 31% larger

<jeffro256> For BC512

Jamtis aims for on-chain indistinguishability, which implies identical tx sizes. But there will be ~132 bytes in tx extra for all transactions (even legacy ones).

IMHO it could well be that we can go into a focussed decision process only with the FCMP++ and Carrot hardfork successfully behind us, not yet now

Yes, it's definitely too early to decide. I was just stating my opinion.

<jeffro256> Yes, TBC, the bit that decides whether unpruned tx sections rises by 31% is whether or not we collectively decide to support Jamtis in some wallets AND plan for on-chain distinguishability. If we stuck with only the Carrot hierarchy, then tx sizes would stay down. But if some wallets support Jamtis-PQ and we decide that all [... too long, see mrelay.p2pool.observer/e/oZvloZALcUFpZnRF ]

<articmine> A 31% increase in sizes is less than 1 year of Neilsen's law

It's the price to pay for PQ privacy with static address support.

Well, right now only storage prices rise trememdously. Thanks, AI

Will give quite a dent in that law

<articmine> This is very short term. I prefer to focus on the long term

<articmine> Yes I am very much aware of the SSD pricing issue

Understood. And still, we want to offer a cryptocurrency that works today, for various values of "today" for the next years

Well, should probably have written "works well"

<rucknium> More discussion of this for now?

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

<rucknium> We are pushing up the long term median block size now. stressnetnode1.redteam.cash

<rucknium> We produced a 17MB block recently: stressnet.p2pool.observer/block/cda…31e01635456ab6398e3a3e2e68caebd6958

have been seeing an increase on block sizes (recent ones have quite a list of txs) stressnet.p2pool.observer/block/cda…31e01635456ab6398e3a3e2e68caebd6958 thanks to the spam

heh. yep that block. there is a second one as well stressnet.p2pool.observer/block/d36…e475a97a9d34ddebe9e8973b3bf641adcf8

<rucknium> Thanks to DataHoarder[m] for getting his FCMP block explorer working :)

<jeffro256> Not a whole lot of updates from me. Still bugging hardware wallet people. Working on hot/cold PR, thanks @j-berman. I'm about to push a couple business PRs to upstream

my p2pool miner will stop packing txs past 128K block blob byte sizes, but I can deal with that. it's 70 KiB / 128 KiB so far and approaching quick :)

<rucknium> I decided to turn some of my spam wallets to high fees to push block sizes up and exhaust the wallets' funds.

anything else to do to help push sizes further? I have p2pool mining code which is quite efficient at packing these sudden high fee txs

<jberman> Stressnet generally seems to continue to run smooth. Unfortunately, the issue I brought up last week of wallets sporadically erroring on tx construction with double spend errors is actually not solved yet (seems I mistakenly mis-identified the root cause of the issue, realized thanks to @rbrunner7:monero.social's pushback on t [... too long, see mrelay.p2pool.observer/e/jM6KopALSlNURmpR ]

I can send funds or mine to other addresses if that'd help Rucknium :)

<rucknium> DataHoarder: DataHoarder: We hit another long-term median ceiling again. I don't know how long we will be scraping that ceiling until it gives way. I'd guess 1-4 days.

additionally could make many miner outputs on coinbases, that send each to a different wallet (and with some changes, maybe multiple per wallet)

<rucknium> DataHoarder: I may need more funds in a week to two. You can pay me back for those high-fee mined blocks :D

so far I have been sending to the faucet, give an address and I can send via the wallet :)

also, for anyone mining or spamming, if you'd like to get listed on the blocks list with attribution or stressnet.p2pool.observer/pools, or display payment details, you can give an address+viewkey

<rucknium> I chose to exhaust funds on a few wallets because eventually big wallets get slower. Big = lots of historical txs.

<jeffro256> Same here, I've built up some miner funds , let me know where to send em

<rucknium> My main stressnet wallet: 9uk5eY8waibQp7MMwpo3JrcMFatbiGtHKcTHMEzxWE39An8R3VTbztTPcJ7MDYEVVrAC4ueSV5KzP4GMTTwGoGBjAtKFp7i

<rucknium> Thanks.

sent ~640 tXMR your way.

<rucknium> More discussion about stressnet?

<rucknium> DataHoarder: Thank you.

how long is v2 beta stressnet expected to continue for?

<articmine> I would suggest that it run until the hard limit 100 MB code issues are addressed

<articmine> So we'll afy the HF

<articmine> after

100MB blob byte size or weight size?

<articmine> DataHoarder: Enough to trigger the code issues

privacy wise, would it be proper in these sweep cases stressnet.p2pool.observer/tx/b5ec05…bd801cd1ee2379b6bc6bb12f18cc5ccd339 to not send 0.000000000000 XMR back as change?

<jberman> It would be nice to solve the following big issues observed: sporadic double spend errors, higher ban frequency, possibly node's pool not catching up to another. And get p2p SSL and hot/cold wallet support running / tested. It would also be very nice to get the major RPC getblocks.bin speedup implemented too because I expect t [... too long, see mrelay.p2pool.observer/e/3JywopALUjNmcFh6 ]

<articmine> Yes

<jberman> the former "nice-to-solves" would be nice to solve to be certain if the cause is tx relay v2, pre-existing, or anything FCMP++/Carrot related (though that is not my current suspicion)

<jberman> tx relay v2 though I guess is a big +1 especially for FCMP++ once tx sizes are much larger, so it's indirectly related in that way

<rucknium> Would the RPC getblocks.bin speedup affect wallets' txpool requests at all?

<jberman> @rucknium: ya that's what I'm referring to there (the pool fetching part of getblocks.bin, not the blocks fetching part)

<jeffro256> DataHoarder: You need 1 scannable output per tx as per CARROT rules. Also, if you share your viewkey and the public can see amounts of UTXOs , they can calculate that the output has 0 XMR anyways

<rucknium> Ah good.

jeffro256: yeah, this case is due to viewkey sharing specifically that it decrypts the 0 XMR. I guess it'll be better with full Carrot where those outputs end up internal instead of the special external change case.

<jberman> The main reason the sweep case has 0 amount change back to sender is so that seeds remain compatible for background syncing and light wallet support as currently implemented (without needing to reveal your key images to a daemon/server)

<rucknium> I think my max spam pace is being limited by slow wallet-node interaction. I think I can only get 25-30 wallets connected per node before adding more wallets decreases total spam volume. And I don't have infinite nodes.

right! the tx needs to be picked up by a spend / view balance wallet

<rucknium> If we want to go a lot higher with tx volume, faster RPC would be very helpful I think.

Rucknium: I see a lot of txs coming as discretized units instead of batches which is spamming some of my logs, so somewhere it's hitting a bottleneck

example recent ones privatebin.net/?80e0dae714f31b58#6L…XywMyMBsrPmBPHDK7NBip7buEa7yaGB6HWP

<jberman> ya it's known when there's a lot of txs in the pool, the /getblocks.bin request can be extremely slow and prevent the daemon from doing anything: seraphis-migration/monero #293

<rucknium> Discretized units instead of batches means what?

afaik the verification is faster (1.5s for the recent big blocks)

Rucknium: on ZMQ interface new txs can be notified as one event instead of individual ones. Usually the node is fast enough that it aggregates them a bit, but recently it has started sending many individual events (which adds some overhead)

<rucknium> @jberman:monero.social: Will the new getblock.bin code make txpool requests become a non-blocking operation?

<rucknium> DataHoarder: Do you think that is related to clumping in p2p tx messages?

<jeffro256> It will still be blocking

<jberman> @rucknium: no, it can make the request take ~0.1s as opposed to 3-15s+ per wallet. Making it a non-blocking operation is another potential improvement mentioned in that issue

yeah, maybe they are less clumped, so they don't come at once, or the monero code takes time verifying them. they also come very quick one after each other

<jeffro256> Unfortunately that's just how the blockchain DB and higher level code work

<rucknium> e.g. Fountain5405/monerosim #3 "Clumping in transaction broadcast messages"

I am talking about post-verification, where it notifies listeners via ZMQ. I can't remember if that's done per clump on the wire message, or on the go as txs get verified

<rucknium> I think we had some attrition with the total number of nodes on the network. IMHO a smaller network causes less tx message clumping. I don't know if that could be causing what you're seeing.

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

code on my side is performant, so doesn't make much of a difference except sending ~400 new jobs to xmrig instead of 2-10 per block

<rucknium> @gingeropolous:monero.social gave an update before the meeting:

<rucknium> > unfortunately I won't be able to attend live during the meeting. But I'm continuing to push monerosim towards mainnet fidelity. Current results here: github.com/Fountain5405/monerosim/b…/20260620_network_topology_study.md . TL;DR, it seems the hypothesis was right, that a 100% reachable network behaves differently than main net.

<rucknium> > the sim currently running is the "churning" - nodes turning on and off throughout the sim, as opposed to always on.

<rucknium> I think someone has one last question for the meeting.

<emsczkp:matrix.org> Can I quickly ask about the Milestone ? Do people think another review slot is needed next week, or can we consider the current state sufficient for approval? Thanks

<rucknium> IMHO this depends on if anyone plans to spent time reading the revised paper at this point.

Yeah, feedback from one of our cryptographers would be interesting

Even as they are surely quite busy already ...

<ofrnxmr> > <@jberman> It would be nice to solve the following big issues observed: sporadic double spend errors, higher ban frequency, possibly node's pool not catching up to another. And get p2p SSL and hot/cold wallet support running / tested. It would also be very nice to get the major RPC getblocks.bin speedup implemented too b [... too long, see mrelay.p2pool.observer/e/i6mSo5ALV0N2THow ]

<ofrnxmr> I'm running p2p ssl

<rucknium> We will see if anyone comments here and then decide about approval timeline.

<ofrnxmr> On stressnet, on 2 nodes, and seems to be a third node on sttessnet also running it

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

<ofrnxmr> (sorry for the interruption)

<articmine> Thanks

<jberman> @rucknium: I will try to make time over the next week, but FWIW the summary does sound like solid progress to me

<rucknium> Thanks, @jberman:monero.social

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

<vtnerd> Crap missed reminders about meeting. I was focused on the fido2 encryption lib, initial but not yet complete code is at github.com/vtnerd/fhse

<vtnerd> There's already the base structure with tests and ci

tevador: is there any implementation of current jamtis progress/research other than the gist?

There is only the specification in the gist, no code yet.