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

<ack-j:matrix.org> @rucknium:monero.social: is there free space in the agenda? We’d (MAGIC) like to discuss a new project proposal to improve the efficiency of bulletproofs

<rucknium> @ack-j:matrix.org: Yes. I will put it at the end. What do you want as the agenda item title?

When is the meeting today?

<ravfx:xmr.mx> sech1: in 33 minutes

<rucknium> sech1: 17:00 UTC

<ack-j:matrix.org> “Bulletproof prover and verifier optimization research”

<rucknium> I put RandomX Version 2 first on the agenda, after greetings and updates.

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

<rucknium> 1. Greetings

<ack-j:matrix.org> Hi

hello world

<boog900> Hi

Hello

<jeffro256> Howdy

<sgp_> Hello

<w0venhand:matrix.org> Hi

<jberman> waves

<vtnerd> Hi

<articmine> Hi

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

Have been doing RandomX benchmarks for V2 and looking into low-level CPU performance counters on current generations, specifically now investigatin how increasing prefetch distance across RandomX vm loops reduces the waits and increase instruction throughput.

<rucknium> me: Back on using Markov Decision Process to analyze selfish mining countermeasures.

(note there seems to be a 2-5s delay on IRC bridging since last night outage, I'll investigate later)

I finished RandomX v2 in its current state (including the documentation) and have been testing it

<jeffro256> Me: reviewing ArticMine's scaling updates and digging into OSSFuzz issues

<vtnerd> Me: working on lwsf/monero_c builds for windows and macos. No decent progress on that asan issue unfortunately

<articmine> I updated the scaling documents to address changes with respect to the calculation for the maximum fee and also a series of fixes

<jberman> me: followed up on @jeffro256 's unbiased hash to point impl (a blocker for beta stressnet) and did a bit of refactoring of my own code for that impl and for the FCMP++/Carrot integration. Unrelated to the unbiased hash to point, I have some more refactoring ideas to implement in line with my changes there before opening up th [... too long, see mrelay.p2pool.observer/e/78aQ2N4KX01nQzFa ]

<rucknium> The Monerotopia Conference is happening February 12 to 15 in Mexico City: monerotopia.com . Some MRL regulars and semi-regulars like @jeffro256:monero.social , @articmine:monero.social , @freeman:cypherstack.com , @diego:cypherstack.com , and myself will be presenting.

<articmine> Yes I will be speaking at MoneroTopia and also afterwards at the Crypto Vigilante

<rucknium> 3. RandomX Version 2 (github.com/SChernykh/RandomX/blob/v2/doc/design_v2.md).

<rucknium> sech1, could you describe the purpose of the RandomX update, what tasks remain, any way others can assist, and maybe an expected timeline for completion?

The purpose is to fix the bottlenecks in RandomX on modern CPUs. The main things we found are CFROUND instruction and memory access, so this is what we changed in v2

I think the only task that remains is PowerPC big-endian intrinsics (two small functions). Need a ppc64be systems to test it

<jeffro256> Can you explain a bit further what about the "memory access" was a bottleneck?

<articmine> Is this going to be ready for the upcoming hard fork?

The CPU is waiting for data from the memory (dataset) instead of executing instructions, so it wastes energy

There's a smaller bottleneck with L3 cache access where CPU waited too, but we filled it with AES tweak

acricmine it's already 99% ready, just needs ppc64be test

we are doing live benchmarks with it, PR/code is ready as well

I have been doing similar tests in my go-randomx project (where it's also already implemented)

<rucknium> Any expected effect on the Bitmain X9?

quoting from elsewhere as well:

18:22:02 <sech1> If they have RISC-V CPU with hardware AES instructions, it should drop from 1 MH/s to ~650 KH/s on v2

18:22:32 <sech1> If they have the CPU without hardware AES instructions, but with an AES crypto accelerator to generate the scratchpad, they're screwed[... more lines follow, see mrelay.p2pool.observer/e/2oG72N4KRUtVQm9U ]

It depends on how X9 implemented AES support. If it's a separate circuit not in the CPU, X9 will be effectively bricked

Yes, that above ^

Worst case (for us) it will drop hashrate from 1 MH/s to 650 KH/s

<rucknium> I assume you don't know anyone with an actual X9 unit yet.

It's on preorder now, delivery in July

So no one but Bitmain has it

They also would need to bother and update the firmware which they didn't even for minor changes on other coins they supported

<articmine> Why do I see deja vu here eight years later?

<syntheticbird> and be sure you'll see it again in eight years

<rucknium> sech1: Before you have said that miners would need a 6 month period of time between released of the "final" monerod for the hard fork and activation of the hard fork with RandomX V2. Is that timeline still accurate?

6 months after XMRig release, not monerod

If v2 is finalized and released soon, miners will start updating

<rucknium> That makes it easier if it's not a monerod requirement.

^ even if no hardfork is set for monero at that point, just xmrig finalized support

We plan to finalize v2 in January, make a pull request, then I can start updating XMRig and it will be also released in February

I guess it'd be rx/0 to rx/1 or whatever version shift

So miners will be (for the most part) hardfork-ready in August

no, rx/v2 :)

I don't want to have confusion with number again as it happened with Cryptonight

<rucknium> Would Version 2 need any kind of external audit like Version 1 did, or are the changes small enough not to need it?

Changes are small and evolutionary

<rucknium> Seems like everything is going smoothly :)

note a v2 hardfork also would include commitments, for anyone tracking that work

commitments already exist in randomx codebase merged

<rucknium> commitments of?

Those commitments ^

<jeffro256> Commitments to PoW verifiable by Blake2b

<rucknium> Good to hear.

<jeffro256> It's DoS-resistant pre-verification for our RandomX PoW

<jeffro256> Integration PR is here: monero-project/monero #10038

<rucknium> Anything else on RandomX Version 2?

<rucknium> Thanks so much, sech1 and DataHoarder, for working on it!

<rucknium> 4. FCMP and CARROT reviews and audits status (cryptpad.fr/sheet/#/2/sheet/view/yP…9VF6GYm9bXbPdCerdST3UDEEfBxcM/embed).

<rucknium> I kept this agenda item to follow up on the followups from last meeting.

<sgp_> Divisors is waiting on me. I'll reach out and CC jberman

<jberman> Veridise confirmed to sgp their helioselene review/audit is progressing

<rucknium> @sgp_:monero.social: You mean soliciting firms for a third review of divisors?

<sgp_> Specifically zkSec, yeah. We already got a quote but that was months ago before the CS work on it wrapped up. So we need to update it and accept it

<rucknium> Thanks.

<jberman> CS submitted their latest round of work on GBP, it's currently on us to review that work. That review will take some time to complete

<rucknium> @jberman:monero.social: Building on this? github.com/cypherstack/divisor_deep_dive

<sgp_> @jberman: Then after that review, back to zkSec for a second opinion. We got a quote for that already as well

<rucknium> Is there a reason it's not been posted publicly?

<sgp_> The CS GBP stuff?

<rucknium> Yes

<jberman> @rucknium: Building on this: repo.getmonero.org/-/project/54/upl…ef138126850/GBP_Security_Review.pdf

<rucknium> Ok. Also posted here: moneroresearch.info/243

<sgp_> I believe the intent was to publish after kayaba did their review of it, but I'm double checking

<sgp_> To make sure the suggested changes were feasible in practice (in the implementation)

<rucknium> They suggested changes in their latest review? Would that affect timeline at all?

<sgp_> There definitely has been a delay because of it (CS found issues with GBPs as originally written). Assuming the suggested fix is feasible (which kayaba sadly can't confirm asap since they're heads down for a Serai audit for another month), then the further delays should be minimal. If it's infeasible, then that'll be another delay

<sgp_> If CS is suggesting these fixes, there is a good chance that they will work as intended given their Monero experience

<rucknium> Isn't there a transparency reason to post it?

<rucknium> If it will take kayabaNerve a while to review it, then it could be best to let others see it now.

<sgp_> Fwiw I haven't seen it either, I'm just aware of the context around the delays. I wouldn't be opposed to posting it in draft form here

<jberman> Same position here^

<rucknium> Would be great if you could make that happen :)

<sgp_> Ok, I asked kayaba. If I don't hear back (unlikely) I'll ask CS

<rucknium> Thanks.

<rucknium> Anything else on this agenda item?

<rucknium> 5. FCMP alpha stressnet (monero.town/post/6763165).

<jberman> My position is more or less the same as last week. From my perspective, we're looking good for beta since v1.5 solved the core reliability issues. Perhaps ofrnxmr has an opinion on v1.5's current status as well

<jeffro256> Gotta fix the core tests in seraphis-migration/monero #282 and update to match seraphis-migration/monero #44#issuecomment-3776204112

<jeffro256> After that, scaling changes will be ready for review

<rucknium> Would the suggested changes to Generalized Bulletproofs affect performance enough that it would be a good idea to include the changes in beta stressnet? Probably the answer to this question is unknown, without the Cypher Stack document and/or kayaba's review.

<jberman> A significant perf impact would definitely surprise me, but ya it's an unknown as of now

<jberman> I do think it would be a good idea to have that task item settled before releasing beta

<jberman> We have outstanding tasks we're in the finishing stages for beta now (jeffro is working on scaling, I'm continuing on unbiased hash to point / some refactorings as needed, tx relay v2 is in review). It's all finishing stages though

<diego:cypherstack.com> Hey. Guys.

<diego:cypherstack.com> I want FCMPs out Q2 2026

<diego:cypherstack.com> I'll get everyone a $10 gift card to cold stone or an equivalent ice cream shop.

<diego:cypherstack.com> Plz and thx

<rucknium> @diego:cypherstack.com: There was a desire to publicly post Cypher Stack's latest Generalized Bulletproofs work.

<rucknium> Is that possible to do soon?

<diego:cypherstack.com> Lemme ask.

<rucknium> Thank you.

<rucknium> Anything else about stressnet?

<jberman> nothing from me

<jeffro256> nothing from me

<rucknium> 6. Bulletproof prover and verifier optimization research.

<rucknium> More Bulletproofs!

<rucknium> @ack-j:matrix.org:

<ack-j:matrix.org> MAGIC recieved a project proposal with the following research goals that we'd like community feedback on:

<ack-j:matrix.org> This project aims to deliver significant 2X speedup for both prover and verifier efficiency for Bulletproofs-style range proofs, while preserving their compact communication complexity of 2 log N. More precisely, it seeks to halve the number of computationally expensive group exponentiations required by existing Bulletproofs-b [... too long, see mrelay.p2pool.observer/e/n9aL2t4KbThCbm1x ]

<ack-j:matrix.org> The lead researcher, Dr Nan Wang, is well published in topics such as range proofs and ring signatures.[... more lines follow, see mrelay.p2pool.observer/e/n9aL2t4KbThCbm1x ]

<rucknium> Has anyone here closely read any of the papers linked above? It looks like at least one of them (BulletCT) could help with Bulletproofs efficiency. Anyone know anything about it?

<jberman> I have not, but on the surface, seems like a great proposal

<rucknium> The proposed protocol would not be quantum resistant, or would it?

<jberman> I would assume not

<cyrix126:gupax.io> @rucknium: not with Ed25519

<jeffro256> If the work to speeding up bulletproofs is applicable to either FCMP++'s GBPs and/or Bulletproof+ range proofs, then I am in support of it, especially at that price.

<cyrix126:gupax.io> sry if it's a dumb question but would the proposal be compatible with ccs.getmonero.org/proposals/emsczkp-research-folding-gbp.html ?

<rucknium> The new protocol would require a hard fork probably, right?

<jeffro256> Practically, I think that it's probably too late in the game to make it into the FCMP++ hard fork, but assuming that research and development go well for BulletCT, it would make a good candidate for a follow-up improvement HF

<jeffro256> @rucknium: Almost certainly

<rucknium> @ack-j:matrix.org: MAGIC didn't adopt my suggestion to change the title of the Fuzzing project to something easier to understand :P

<articmine> It is a worthwhile proposal for the first post FCMP++ hard fork.

<ack-j:matrix.org> We generally agree and see it as a solid proposal to push forward bulletproof research with little risk.

<ack-j:matrix.org> @cyrix126:gupax.io that is a good question that I’m not sure of the answer

<ack-j:matrix.org> @rucknium:monero.social: sorry. Will update

<jberman> @cyrix126:gupax.io: a good question. I'd guess maybe and probably not, but perhaps could yield potential improvements to BP* as well. Perhaps @emsczkp:matrix.org could give better insight (but may need further details)

<emsczkp:matrix.org> it might be interesting to see how their poly evaluation proofs are working

<emsczkp:matrix.org> within BP range proofs of course, i'm looking into that

<rucknium> @emsczkp:matrix.org: Could you read moneroresearch.info/285 Wang, N., Wang, Q., Liu, D., Esgin, M. F., & Abuadbba, A. (2025). BulletCT: Towards More Scalable Ring Confidential Transactions With Transparent Setup. BulletCT: Towards More Scalable Ring Confidential Transactions With Transparent Setup.

<rucknium> and tell us what you think?

<ack-j:matrix.org> @emsczkp:matrix.org: assuming we fund this proposal within the next month. Would their 13 week timeline overlap with your work and have the opportunity to benefit from it?

<rucknium> It's not part of your CCS proposal, so don't feel obligated to do it.

<emsczkp:matrix.org> I'll take a look yes

<emsczkp:matrix.org> also if the authors of the paper want discuss with me, it's ok

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

<jberman> thank you @emsczkp:matrix.org !

<emsczkp:matrix.org> welcome

<rucknium> @ack-j:matrix.org: You could put them it touch with @emsczkp:matrix.org

<ack-j:matrix.org> Will do

<rucknium> Anything else on this item?

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

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

<syntheticbird> Delicious meeting

<jeffro256> Thanks everyone!

<brandon:cypherstack.com> no good reasons, only several poor reasons. i wanted matthias from curve trees to take a look at it, and haven't gotten around to communicating about that. i wanted sarang to take a look at it. etc. but it's important and i agree it should be posted publicly sooner rather than later > <@rucknium> Is there a reason it's not been posted publicly?

<rucknium> Just put the DRAFT LaTeX watermark :)

<brandon:cypherstack.com> > <@sgp_> There definitely has been a delay because of it (CS found issues with GBPs as originally written). Assuming the suggested fix is feasible (which kayaba sadly can't confirm asap since they're heads down for a Serai audit for another month), then the further delays should be minimal. If it's infeasible, then that'll be another delay

<brandon:cypherstack.com> yes, the proposal i reviewed (i believe written by sarang, which was a modification of a previous version based on matthias' comments) had a problem with the extractor which sarang did not catch, and the only fix we could identify required a modification to the protocol which worsened efficiency slightly. @kayabanerve:matrix.org has more comments about that.

<brandon:cypherstack.com> @rucknium: yeah, i plan on posting it soon(tm)

<rucknium> If you can estimate the inefficiency increase and it's not very high, e.g. 20% or less total increase in FCMP verification time, it would seem OK to me.

<brandon:cypherstack.com> @brandon:cypherstack.com: despite the delay, i count this as a win because the version which would have been posted would have possibly allowed malicious parties to falsely convince verifiers of arithmetic circuit satisfaction. however, we do suspect that someone who could pull that off would be reducible to a discrete log [... too long, see mrelay.p2pool.observer/e/9Zvo294Kb1JUSTd1 ]

<brandon:cypherstack.com> @rucknium: @kayabanerve:matrix.org should have a better view of that; i believe we had a few back-and-forth conversations on the specific complexity costs of my proposed fix

<brandon:cypherstack.com> afaik, kayaba has not concretely implemented my changes, so does not yet have concrete efficiency analysis done, and my back of the envelope asymptotics were slightly incorrect the last i spoke with kayaba about it

<rucknium> Thanks for your work on that, @brandon:cypherstack.com

<sgp_> Yes it's very good that it was caught