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

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

<rucknium> 1. Greetings

<jeffro256> Howdy

<articmine> Hi

Hello

<gingeropolous> howdy do

<emsczkp:matrix.org> hi

hullo

hi

<cyrix126:gupax.io> Hello

<jberman> waves

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

RandomX V2 testing, specially around new prefetch parameter tweak now part of the main design github.com/SChernykh/RandomX/blob/v2/doc/design_v2.md (and is considered finalized for the PR)

<gingeropolous> trying to put the final touches on the monerosim package.

<rucknium> me: Selfish mining countermeasures analysis.

<rucknium> @gingeropolous:monero.social: How did your 1000-node test go?

<jeffro256> Me: finished reviewing @j-berman's unbiased hash-to-point changes, fixiing beta scaling tests, working on my Monerotopia presentation

<gingeropolous> its working well. I want to demonstrate something useful, so im getting a simulation that does a network upgrade (going from one version of monerod to another.... in this case, one that that has tx relay v2 pulled in). Currently the user agent code isn't handling the wallet correctly during the daemon restart. But otherwise it runs

<jberman> me: preparing the FCMP++ integration code for auditing, finalizing tx relay v2

<rucknium> @gingeropolous:monero.social: Fantastic. Thanks.

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

<rucknium> Was the Cypher Stack Generalized Bulletproofs review & suggestions posted? I didn't see it.

<jeffro256> No updates from me

<rucknium> @diego:cypherstack.com: Has the Generalized Bulletproofs new review been posted?

<jberman> @sgp_:monero.social reached out to zkSec (specifically a curve trees author) to review divisors, don't believe there's been an update

<jberman> re: integration audit, I'm aiming to have the code ready by EOW, and will start planning an audit approach then

<rucknium> @brandon:cypherstack.com: Any update on posting the Generalized Bulletproofs review draft? > <@brandon:cypherstack.com> yeah, i plan on posting it soon(tm)

<rucknium> "I'm still cleaning it up" is a valid response :)

<rucknium> I'll go to the next agenda item. Maybe Cypher Stack staff will come in later.

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

<diego:cypherstack.com> yes > <@rucknium> @diego:cypherstack.com: Has the Generalized Bulletproofs new review been posted?

<jberman> I'm still thinking it would be nice to have tx relay v2 tested on alpha. I'm going to prepare all the changes that would be solid for a v1.6 release (nothing significant at this stage), and also port those changes to the staging branch in prep for beta

<diego:cypherstack.com> it's on iacr

<jberman> If we have capacity to get a v1.6 release out, then that would be solid, but if not, then we'll just have it ready for beta

<vtnerd> sorry Im late, here now

<jeffro256> So tx relay v2 changes coming along well?

<jberman> Generally, I remain confident that alpha achieved a level of stability that is ready to move to beta

<diego:cypherstack.com> grabbing the link, moment

<jberman> @jeffro256: Yep, changes are pretty much done

<jberman> Completed @boog900:monero.social 's latest review round

<brandon:cypherstack.com> I submitted the generalized bulletproof paper to iacr last week but the editors have not posted it yet. As soon as I get the link sent to me I will share it here.

<rucknium> @brandon:cypherstack.com: Thank you!

<jeffro256> @jberman: agreed, thanks for all that work

<rucknium> I agree that alpha should try tx relay v2 because we don't know yet if beta stressnet should have changes to Generalized Bulletproofs (GBP).

<jberman> ack

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

<rucknium> @emsczkp:matrix.org: Did you find time to look at 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. ?

<emsczkp:matrix.org> > <@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.

<emsczkp:matrix.org> I don't want to dominate this agenda item, just share some thoughts on BulletCT

<emsczkp:matrix.org> BulletCT contributes to RingCT signature schemes with a “K-weight” version of K-out-of-N proofs (K/N proofs), inspired by the Any-out-of-N proofs (Any/N proofs), and proposes a new Tag proof.

<emsczkp:matrix.org> BulletCT doesn’t bring improvements to Bulletproofs proof system itself; rather, it compares mainly against the Any/N RingCT scheme, the Omniring and RingCT-3.0.

<emsczkp:matrix.org> Overall, BulletCT constructs a RingCT signature by combining four proofs, K/N proof, Tag proof, Balance proof and Range proof. The authors only provide the K/N proof and Tag proof. Moreover, both K/N proof and Tag proof follow the Bulletproofs-style proof for two different objectives: K/N proof proves the “existence of a val [... too long, see mrelay.p2pool.observer/e/qLCO-eAKUDhwYVY3 ]

<emsczkp:matrix.org> However, it is unclear to me why the authors use separate Bulletproofs-style proofs for the K/N proof and the Tag proof. While the K/N proof appears to be motivated by Bulletproofs’ bit-decomposition constraints, an analogous motivation is not evident for the Tag proof. Finally, neither construction presents an explicit redu [... too long, see mrelay.p2pool.observer/e/qLCO-eAKUDhwYVY3 ]

<emsczkp:matrix.org> this is my brief review

<emsczkp:matrix.org> i don't agree Bulletct will benefit for Bulletproofs neither FCMP

<emsczkp:matrix.org> i didn't read the other paper, but i will do

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

<emsczkp:matrix.org> welcome

<sgp_> Fwiw I don't think anyone claimed that bulletct as written would benefit Monero directly

<jberman> @emsczkp:matrix.org: Do you draw this conclusion because you think there isn't enough support for their idea? In other words, do you think they could take your feedback specifically from the second paragraph and iterate? Or that it's fundamentally flawed

<emsczkp:matrix.org> here maybe > <@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?

<rucknium> So my hypothesis was wrong :D

<emsczkp:matrix.org> @jberman: i don't see the prover/verifer optimizations in BulletCT. I would like more details on that particular optimizations, or at least which papers do

<emsczkp:matrix.org> here the authors claim there are "it seeks to halve the number of computationally expensive group exponentiations required by existing Bulletproofs-based constructions, yielding an almost 2X practical speedup" ... i haven't find this yet > <@ack-j:matrix.org> MAGIC recieved a project proposal with the following research goals that we'd like community feedback on:

<sgp_> BulletCT is related work, but it's not "using BulletCT as a direct starting point, we changed this and this to create a Monero compatible proposal". Ack-j can chime in if my understanding is wrong

<rucknium> Right. I was trying to get an idea of the researcher's research agenda .

<sgp_> They aren't saying BulletCT accomplishes the scope/claims

<ack-j:matrix.org> Yea bulletCT is different. The papers that are more relevant are SwiftRange and flashproofs. I will get you a link

<rucknium> To fund this, you would want to know if the objective of the research is feasible and if the researcher is likely to succeed in his/her goal.

<ack-j:matrix.org> moneroresearch.info/index.php?actio…S_CORE&method=creatorProcess&id=692

<ack-j:matrix.org> Here is the authors publications. 3 papers on range proofs and then bulletct is an outlier

<rucknium> I suggested the wrong one. Sorry.

<ack-j:matrix.org> Update on the MAGIC side. Dr. Nan Wang identified a soundness flaw in their proposed bulletproof+ optimization that affects the verifier efficiency. Their proposal still should double the prover efficiency and benefit verifier efficiency, but the 2x verifier estimate has been reduced.

<ack-j:matrix.org> We plan to make a reddit post soon and start the fundraising round

<jberman> fwiw, I don't recall exactly how long it takes to construct the BP+, but I at least haven't noticed it to be a perf issue when constructing a tx

<jeffro256> Especially after FCMP++ ...

<jberman> right

<rucknium> Verifier efficiency is usually much more important than prover efficiency, for blockchains.

<jberman> FCMP++ construction is still pretty slow especially for large input txs, to the point it would actually be a noticeable thing for users

<sgp_> @rucknium: This was emphasized to them by @ack-j:matrix.org fwiw

<ack-j:matrix.org> mrelay.p2pool.observer/m/matrix.org/tGRPFJzPclIFBXyRgcohWeCS.pdf (Monero_Proposal 3.pdf)

<ack-j:matrix.org> The author agreed to let us share the proposal. Here is the latest revision

<rucknium> @emsczkp:matrix.org: Any thoughts on the "Project Feasibility" section?

<emsczkp:matrix.org> yea, now I see swiftrange promises BP rangeproof speed-up

<emsczkp:matrix.org> I'm not in swiftrange, I'll take a look

<jeffro256> It says communication cost up to 2x as the "range size" increases. I'm guessing that that's the 64-bit amount, and not the number of outputs ?

<emsczkp:matrix.org> of course, don't want to block the fundraising