14:56:41 MRL meeting in this room in two hours. 15:23:20

@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 16:18:31 @ack-j:matrix.org: Yes. I will put it at the end. What do you want as the agenda item title? 16:22:52 When is the meeting today? 16:23:32 sech1: in 33 minutes 16:25:19 sech1: 17:00 UTC 16:25:47

“Bulletproof prover and verifier optimization research” 16:25:55 I put RandomX Version 2 first on the agenda, after greetings and updates. 17:00:42 Meeting time! https://github.com/monero-project/meta/issues/1330 17:00:47 1. Greetings 17:00:56

Hi 17:01:08 hello world 17:01:21 Hi 17:01:23 Hello 17:01:29 Howdy 17:02:07 Hello 17:02:20 Hi 17:02:34 waves 17:02:46 Hi 17:02:58 Hi 17:03:19 2. Updates. What is everyone working on? 17:03:31 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. 17:03:48 me: Back on using Markov Decision Process to analyze selfish mining countermeasures. 17:04:06 (note there seems to be a 2-5s delay on IRC bridging since last night outage, I'll investigate later) 17:04:11 I finished RandomX v2 in its current state (including the documentation) and have been testing it 17:04:14 Me: reviewing ArticMine's scaling updates and digging into OSSFuzz issues 17:04:44 Me: working on lwsf/monero_c builds for windows and macos. No decent progress on that asan issue unfortunately 17:05:13 I updated the scaling documents to address changes with respect to the calculation for the maximum fee and also a series of fixes 17:05:37 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 https://mrelay.p2pool.observer/e/78aQ2N4KX01nQzFa ] 17:06:35 The Monerotopia Conference is happening February 12 to 15 in Mexico City: https://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. 17:08:09 Yes I will be speaking at MoneroTopia and also afterwards at the Crypto Vigilante 17:08:17 3. RandomX Version 2 (https://github.com/SChernykh/RandomX/blob/v2/doc/design_v2.md). 17:09:10 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? 17:10:43 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 17:11:10 I think the only task that remains is PowerPC big-endian intrinsics (two small functions). Need a ppc64be systems to test it 17:12:15 Can you explain a bit further what about the "memory access" was a bottleneck? 17:12:22 Is this going to be ready for the upcoming hard fork? 17:13:29 The CPU is waiting for data from the memory (dataset) instead of executing instructions, so it wastes energy 17:14:27 There's a smaller bottleneck with L3 cache access where CPU waited too, but we filled it with AES tweak 17:14:55 acricmine it's already 99% ready, just needs ppc64be test 17:15:26 we are doing live benchmarks with it, PR/code is ready as well 17:15:43 I have been doing similar tests in my go-randomx project (where it's also already implemented) 17:15:57 Any expected effect on the Bitmain X9? 17:17:13 quoting from elsewhere as well: 17:17:13 18:22:02 If they have RISC-V CPU with hardware AES instructions, it should drop from 1 MH/s to ~650 KH/s on v2 17:17:13 18:22:32 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 https://mrelay.p2pool.observer/e/2oG72N4KRUtVQm9U ] 17:17:17 It depends on how X9 implemented AES support. If it's a separate circuit not in the CPU, X9 will be effectively bricked 17:17:34 Yes, that above ^ 17:18:02 Worst case (for us) it will drop hashrate from 1 MH/s to 650 KH/s 17:18:22 I assume you don't know anyone with an actual X9 unit yet. 17:18:37 It's on preorder now, delivery in July 17:18:45 So no one but Bitmain has it 17:19:41 They also would need to bother and update the firmware which they didn't even for minor changes on other coins they supported 17:20:10 Why do I see deja vu here eight years later? 17:21:11 and be sure you'll see it again in eight years 17:24:16 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? 17:24:45 6 months after XMRig release, not monerod 17:25:05 If v2 is finalized and released soon, miners will start updating 17:25:30 That makes it easier if it's not a monerod requirement. 17:25:39 ^ even if no hardfork is set for monero at that point, just xmrig finalized support 17:25:53 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 17:25:55 I guess it'd be rx/0 to rx/1 or whatever version shift 17:26:11 So miners will be (for the most part) hardfork-ready in August 17:26:23 no, rx/v2 :) 17:26:39 I don't want to have confusion with number again as it happened with Cryptonight 17:26:41 Would Version 2 need any kind of external audit like Version 1 did, or are the changes small enough not to need it? 17:26:55 Changes are small and evolutionary 17:27:22 Seems like everything is going smoothly :) 17:27:30 note a v2 hardfork also would include commitments, for anyone tracking that work 17:27:43 commitments already exist in randomx codebase merged 17:28:00 commitments of? 17:28:41 https://github.com/monero-project/monero/issues/8827 17:28:48 Those commitments ^ 17:29:20 Commitments to PoW verifiable by Blake2b 17:29:36 Good to hear. 17:29:37 It's DoS-resistant pre-verification for our RandomX PoW 17:30:14 Integration PR is here: https://github.com/monero-project/monero/pull/10038 17:32:23 Anything else on RandomX Version 2? 17:34:36 Thanks so much, sech1 and DataHoarder, for working on it! 17:34:56 4. FCMP and CARROT reviews and audits status (https://cryptpad.fr/sheet/#/2/sheet/view/yPVIUywwA9-deE9VF6GYm9bXbPdCerdST3UDEEfBxcM/embed/). 17:35:22 I kept this agenda item to follow up on the followups from last meeting. 17:36:04 Divisors is waiting on me. I'll reach out and CC jberman 17:36:56 Veridise confirmed to sgp their helioselene review/audit is progressing 17:37:39 @sgp_:monero.social: You mean soliciting firms for a third review of divisors? 17:38:24 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 17:38:54 Thanks. 17:40:26 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 17:41:28 @jberman:monero.social: Building on this? https://github.com/cypherstack/divisor_deep_dive 17:41:34 @jberman: Then after that review, back to zkSec for a second opinion. We got a quote for that already as well 17:42:04 Is there a reason it's not been posted publicly? 17:42:16 The CS GBP stuff? 17:43:07 Yes 17:43:12 @rucknium: Building on this: https://repo.getmonero.org/-/project/54/uploads/b2d5c8198f55d72b588f1ef138126850/GBP_Security_Review.pdf 17:44:59 Ok. Also posted here: https://moneroresearch.info/243 17:47:02 I believe the intent was to publish after kayaba did their review of it, but I'm double checking 17:47:56 To make sure the suggested changes were feasible in practice (in the implementation) 17:49:03 They suggested changes in their latest review? Would that affect timeline at all? 17:51:17 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 17:53:08 If CS is suggesting these fixes, there is a good chance that they will work as intended given their Monero experience 17:54:05 Isn't there a transparency reason to post it? 17:54:39 If it will take kayabaNerve a while to review it, then it could be best to let others see it now. 17:55:24 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 17:55:54 Same position here^ 17:56:28 Would be great if you could make that happen :) 17:57:11 Ok, I asked kayaba. If I don't hear back (unlikely) I'll ask CS 17:57:41 Thanks. 17:57:49 Anything else on this agenda item? 17:59:13 5. FCMP alpha stressnet (https://monero.town/post/6763165). 18:01:02 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 18:01:34 Gotta fix the core tests in https://github.com/seraphis-migration/monero/pull/282 and update to match https://github.com/seraphis-migration/monero/issues/44#issuecomment-3776204112 18:02:04 After that, scaling changes will be ready for review 18:03:32 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. 18:04:46 A significant perf impact would definitely surprise me, but ya it's an unknown as of now 18:05:14 I do think it would be a good idea to have that task item settled before releasing beta 18:06:13 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 18:06:51 Hey. Guys. 18:06:55 I want FCMPs out Q2 2026 18:07:54 I'll get everyone a $10 gift card to cold stone or an equivalent ice cream shop. 18:08:11 Plz and thx 18:09:38 @diego:cypherstack.com: There was a desire to publicly post Cypher Stack's latest Generalized Bulletproofs work. 18:09:50 Is that possible to do soon? 18:10:49 Lemme ask. 18:11:01 Thank you. 18:11:11 Anything else about stressnet? 18:11:52 nothing from me 18:11:58 nothing from me 18:12:42 6. Bulletproof prover and verifier optimization research. 18:12:48 More Bulletproofs! 18:12:53 @ack-j:matrix.org: 18:14:13

MAGIC recieved a project proposal with the following research goals that we'd like community feedback on: 18:14:14

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 https://mrelay.p2pool.observer/e/n9aL2t4KbThCbm1x ] 18:14:14

The lead researcher, Dr Nan Wang, is well published in topics such as range proofs and ring signatures.[... more lines follow, see https://mrelay.p2pool.observer/e/n9aL2t4KbThCbm1x ] 18:17:29 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? 18:18:21 I have not, but on the surface, seems like a great proposal 18:18:57 The proposed protocol would not be quantum resistant, or would it? 18:19:27 I would assume not 18:19:31 @rucknium: not with Ed25519 18:20:44 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. 18:21:22 sry if it's a dumb question but would the proposal be compatible with https://ccs.getmonero.org/proposals/emsczkp-research-folding-gbp.html ? 18:22:13 The new protocol would require a hard fork probably, right? 18:22:36 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 18:22:45 @rucknium: Almost certainly 18:23:25 @ack-j:matrix.org: MAGIC didn't adopt my suggestion to change the title of the Fuzzing project to something easier to understand :P 18:24:22 It is a worthwhile proposal for the first post FCMP++ hard fork. 18:26:50

We generally agree and see it as a solid proposal to push forward bulletproof research with little risk. 18:26:50

@cyrix126:gupax.io that is a good question that I’m not sure of the answer 18:26:58

@rucknium:monero.social: sorry. Will update 18:27:05 @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) 18:29:50 it might be interesting to see how their poly evaluation proofs are working 18:31:25 within BP range proofs of course, i'm looking into that 18:32:25 @emsczkp:matrix.org: Could you read https://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. 18:32:34 and tell us what you think? 18:32:46

@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? 18:32:54 It's not part of your CCS proposal, so don't feel obligated to do it. 18:33:55 I'll take a look yes 18:34:34 also if the authors of the paper want discuss with me, it's ok 18:34:48 @emsczkp:matrix.org: Thank you! 18:35:01 thank you @emsczkp:matrix.org ! 18:35:05 welcome 18:35:07 @ack-j:matrix.org: You could put them it touch with @emsczkp:matrix.org 18:35:52

Will do 18:36:12 Anything else on this item? 18:38:58 We can end the meeting here. Thanks everyone. 18:39:11 👋 > <@rucknium> We can end the meeting here. Thanks everyone. 18:39:45 Delicious meeting 18:43:05 Thanks everyone! 19:10:28 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? 19:12:04 Just put the DRAFT LaTeX watermark :) 19:12:11 > <@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 19:12:11 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. 19:12:24 @rucknium: yeah, i plan on posting it soon(tm) 19:14:04 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. 19:14:25 @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 https://mrelay.p2pool.observer/e/9Zvo294Kb1JUSTd1 ] 19:15:29 @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 19:25:53 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 19:26:49 Thanks for your work on that, @brandon:cypherstack.com 19:54:28 Yes it's very good that it was caught