14:52:52 <br-m> <syntheticbird> Is there meeting today?
15:00:46 <br-m> <rucknium> MRL meeting in this room in two hours.
15:00:52 <br-m> <rucknium> @syntheticbird:monero.social: Yes
17:00:29 <br-m> <rucknium> Meeting time! https://github.com/monero-project/meta/issues/1365
17:00:30 <br-m> <rucknium> 1. Greetings
17:00:44 <UkoeHB> Hi
17:00:51 <br-m> <vtnerd> Hi
17:00:52 <br-m> <jpk68:matrix.org> Hello
17:00:52 <rbrunner> Hello
17:01:04 <br-m> <emsczkp:matrix.org> Hi
17:01:25 <br-m> <iamnew117:matrix.org> hello 
17:02:16 <br-m> <rucknium> 2. Updates. What is everyone working on?
17:03:50 <br-m> <vtnerd> Me: bug fixes and reviews for monerod, tests for the lws /feed endpoint, working on docker stuff for lws build, and lastly updating lws+lwsf for the API changes in the carrot libs
17:03:56 <br-m> <jberman> waves
17:04:14 <br-m> <syntheticbird> Hi
17:06:06 <br-m> <jberman> me: about to post a CCS proposal for the FCMP++ integration audits, @sgp_:monero.social has been in direct comms with a number of candidates on phase 1, various monerod fixes
17:06:31 <br-m> <jeffro256> Howdy
17:06:45 <br-m> <rucknium> 3. FCMP code integration audit overview (https://github.com/seraphis-migration/monero/issues/294).
17:07:17 <br-m> <articmine> Hi
17:07:43 <br-m> <jeffro256> Me: talking with Ledger, auditors, and other contributors. Looking into LWS performance leveraging GPU and what happens with CARROT 
17:08:03 <br-m> <jberman> Posting a CCS proposal today to request XMR upfront to budget for all 3 phases of the audit, sgp in comms with auditors soliciting quotes for phase 1
17:08:32 <br-m> <rucknium> @jeffro256:monero.social: "Looking into LWS performance leveraging GPU" Can you give more info on that?
17:08:34 <br-m> <jeffro256> Do you know of price points already?
17:09:30 <br-m> <jberman> We're requesting under $50k for each of the 3 phases, so budgeting $150k for the entire audit
17:09:39 <br-m> <jeffro256> @rucknium: Yeah I'm doing a quick detour to see if using the GPU is feasible for performinh bulk scanning of thousands of view-incoming keys 
17:09:50 <br-m> <vtnerd> https://github.com/vtnerd/monero-lws/issues/245
17:10:13 <br-m> <jberman> Then leftover funds would get repurposed for auditing the less critical components (like the torsion check)
17:10:41 <endogenic> that is elite jeffro
17:10:46 <br-m> <jeffro256> @jberman: That's a decent ceiling. I don't think any of those phases should take more than that. 
17:10:49 <br-m> <rucknium> IIRC, Monero Nodo wanted to make its onboard GPU useful for something.
17:12:19 <br-m> <jberman> @kayabanerve:matrix.org has also expressed strong interest in GPU scanning for normal wallets
17:13:27 <br-m> <rucknium> Monero Nodo's GPU is "Mali-G610, quad-core"  https://moneronodo.com/product/nodo/
17:13:31 <br-m> <jberman> (tbc, an interest in seeing it explored, not a personal interest in working on it)
17:13:32 <br-m> <syntheticbird> rest in peace to whoever is gonna adventure the great vulkan api
17:14:38 <br-m> <vtnerd> The big unknown is the massive amount of code needed to make it happen, but maybe with view tags and just x25519 scalarmult something could be made of it
17:14:56 <br-m> <vtnerd> Massive is the wrong word, just bigger than ideal 
17:16:11 <br-m> <rucknium> Anything more on this agenda item?
17:16:43 <br-m> <jberman> nothing from me
17:16:46 <br-m> <jeffro256> There's a lot of parallelization that can happen in the field / group math itself which I'm looking at, which would allow the breakdown of the program into many smaller parts, and maybe allow for better throughput 
17:17:25 <br-m> <rucknium> 4. FCMP beta stressnet (https://github.com/seraphis-migration/monero/issues/166).
17:18:07 <br-m> <jberman> kayaba is working on last remaining task items, then we should be ready to go
17:19:28 <br-m> <rucknium> 5. Grease Payment Channels (https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/651).
17:23:28 <br-m> <rucknium> My list of downsides to this proposal are 1) No trustless Key Escrow Service (KES) yet, 2) The use case is limited so far, 3) The proposal is expensive in XMR terms.
17:24:00 <br-m> <rucknium> I wonder if the Grease team could or would wait to start working on this phase of development until trustless KES was available.
17:24:43 <br-m> <rucknium> Any more discussion of this item?
17:25:47 <br-m> <rucknium> 6. Bulletproofs*: Verifier-Efficient Arithmetic Circuit Proofs via Folding (https://eprint.iacr.org/2026/586). CCS update (https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/626#note_35351).
17:26:06 <br-m> <jeffro256> Yeah I have a similar feeling. I understand that they want to keep it out of scope, but it's one of the single most critical components of the system. And from my experience, designing modular systems is cool and all, but usually you want at least one working implementation of a missing module in your system so you get a feel and design for how it would interact in the real word 
17:26:14 <br-m> <rucknium> Any more questions or comments for @emsczkp:matrix.org ?
17:26:32 <br-m> <emsczkp:matrix.org> Hi!
17:26:35 <br-m> <jeffro256> Otherwise you have an API which you don't end up using b/c the first implementation reveals things you didn't expect to need in an API 
17:27:24 <br-m> <emsczkp:matrix.org> Regarding questions posed in the previous MRL meeting by @jberman, which I thank for valuable comments on the paper and questions: the folding prover does not necessarily have to coincide with the NARK prover. The NARK prover knows the original secret witness, whereas the folding prover operates on the NARK proofs.
17:28:20 <br-m> <emsczkp:matrix.org> In BP*, NARK proofs are split into instance and witness parts. The folding prover takes both parts as input and performs the fold. Precisely, the witness data used here are those required by the (modified BP) algebraic verifiers for  constraint checks and the commitment-consistency check. Such witness data differ from the original secret witness.
17:28:38 <br-m> <emsczkp:matrix.org> So, to answer to jberman, the paper designs a folding scheme in which the NARK prover and the folding prover are conceptually decoupled. The folding prover does not need the original secret witness, but it does need the instance-witness parts for the proof and accumulator required by the folding relation. In that sense, a third party could fold already-generated NARK proofs.
17:29:28 <br-m> <emsczkp:matrix.org> I would phrase the application level implications cautiously, since the paper itself at this stage focuses on the folding scheme design rather than a concrete deployment scenario. But, My current intuition is that this decoupling could be useful in applications where one entity produces proofs and another entity folds them.
17:30:03 <br-m> <emsczkp:matrix.org> And that's the case, as also pointed out with jberman: https://github.com/monero-project/research-lab/issues/110
17:30:03 <br-m> <emsczkp:matrix.org>  
17:30:42 <br-m> <emsczkp:matrix.org> Here, BP* could potentially enable the idea outlined by kayabanerve, where a block producer folds many proofs from many parties without knowing secrets or interacting with parties. 
17:32:34 <br-m> <jberman> When we were initially discussing this CCS proposal, I expressed a desire / interest in seeing if the BP* design that could potentially enable exactly that^, so it's exciting to me that this potential is on the table with BP*
17:34:33 <br-m> <emsczkp:matrix.org> thank you!
17:35:47 <br-m> <jberman> I admit my math expertise is not deep enough to give a very strong review of the actual math itself, but it seems to pass a smell test with adequate rigor imo. It would be great to get it reviewed by those with the deeper math expertise, but generally I think this work is potentially bearing larger fruits than was initially even proposed, and I'm cautiously optimistic about the direction
17:36:40 <br-m> <rucknium> @emsczkp:matrix.org: Do you plan to submit the paper to a peer-reviewed conference or journal when it is finished?
17:37:36 <br-m> <emsczkp:matrix.org> yes, that's when all future works/steps will be addressed
17:38:34 <br-m> <rucknium> More discussion of this agenda item?
17:38:48 <br-m> <jberman> Thank you @emsczkp:matrix.org !!
17:39:27 <br-m> <emsczkp:matrix.org> thank you all !!
17:40:21 <br-m> <rucknium> 7. CCS proposal: I2P SAMv3 support (https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/650).
17:40:59 <br-m> <rucknium> Last time more discussion was about administrative questions, e.g. funding from the existing bounty or as a fresh CCS proposal.
17:43:38 <br-m> <jpk68:matrix.org> After a fair amount of discussion, I believe that has mostly been resolved (a fresh CCS would be the best approach)
17:44:02 <br-m> <jpk68:matrix.org> Now that the milestones are more solidified, it would be great to hear feedback on it, if any are willing :)
17:45:17 <br-m> <jpk68:matrix.org> Plowsof left a comment regarding the CCS approach, if anyone is interested. It seems the discussion at this point is about who would be the best to do the CCS itself
17:48:06 <br-m> <rucknium> Seeing no discussion for now, I will move to:
17:48:11 <br-m> <rucknium> 8.  Any other business
17:48:26 <br-m> <rucknium> https://research.google/blog/safeguarding-cryptocurrency-by-disclosing-quantum-vulnerabilities-responsibly/
17:48:26 <br-m> <rucknium> https://quantumai.google/static/site-assets/downloads/cryptocurrency-whitepaper.pdf
17:49:08 <br-m> <rucknium> Before the meeting, @semisimple:monero.social  suggested a discussion, at some unspecified time, about Google's new lower estimates for breaking the discrete log problem.
17:50:04 <br-m> <rucknium> Maybe people want to discuss a little now or we can agree to put it on the agenda next meeting. I don't know if there is a lot more to say than has already been said except for post-quantum is closer than expected.
17:50:32 <br-m> <rucknium> Some discussion on the MRL GitHub repo: Discussion: Post-quantum security and ethical considerations over elliptic curve cryptography (https://github.com/monero-project/research-lab/issues/131).
17:50:55 <br-m> <articmine> This is making the case for the acceleration of the post quantum issue.
17:51:26 <br-m> <rucknium> > Specifically, we have compiled two quantum circuits (a sequence of quantum gates) that implement Shor's algorithm for ECDLP-256: one that uses less than 1,200 logical qubits and 90 million Toffoli gates and one that uses less than 1,450 logical qubits and 70 million Toffoli gates. We estimate that these circuits can be execu [... too long, see https://mrelay.p2pool.observer/e/_umsnfUKcm9VcEVM ]
17:51:30 <br-m> <rucknium> > This is an approximately 20-fold reduction in the number of physical qubits required to solve ECDLP-256 and a continuation of a long history of gradual optimization in compiling quantum algorithms to fault-tolerant circuits.
17:51:32 <br-m> <rucknium> ^ That is what Google says.
17:52:14 <br-m> <rucknium> I don't know how to interpret that or how many widgets can be stabilized for how long and in what timeline.
17:52:54 <br-m> <vtnerd> They've still got to build a working prototype that does it, which is sort of the frustration in knowing when/if/maybe never
17:54:01 <br-m> <jberman> After all FCMP++ / Carrot research tasks are complete, I'd advocate for a strong concerted effort on designing a complete PQ protocol. tevador has already begun on a PQ key exchange protocol here: https://github.com/monero-project/research-lab/issues/151
17:54:01 <br-m> <jberman> I think it may be worth contracting a research team on a full-time basis for that work
17:55:27 <rbrunner> As I see it, that's more or less the only "wiggle room" we realistically have: No more "conventional" improvements after the FCMP++, but directly onwards to PQ resilience
17:55:45 <rbrunner> *after the FCMP++ hardfork
17:56:10 <rbrunner> Maybe that proposal will be able to get "loose consensus" in the light of this Google paper ...
17:57:25 <br-m> <rucknium> Should post-quantum issues be put on next week's agenda?
17:58:02 <rbrunner> I would give it a "why not" :)
17:58:11 <br-m> <articmine> Yes 
17:58:45 <br-m> <syntheticbird> Yes
17:58:49 <br-m> <rucknium> I will put it on the agenda.
17:59:43 <br-m> <rucknium> We can end the meeting here. Feel free to continue discussing.
18:00:05 <rbrunner> Getting a research team maybe just got a lot more difficult, if many more parties will take it seriously.
18:00:36 <br-m> <rucknium> Or easier, because Monero can build on others' work :)
18:01:22 <rbrunner> "Dear Quantum researcher, don't work for Google, don't work at a world-class university, don't work for IBM, and so ... your place is at the side of the Monero team!"
18:01:57 <rbrunner> Well, we need post-quantum crypto researchers, but still
18:03:29 <br-m> <articmine> rbrunner: The question is what other chains are taking this issue seriously.
18:04:34 <br-m> <articmine> Starting with chains with a greater market cap than Monero 
21:11:47 <endogenic> why is that the question?
21:15:41 <endogenic> besides, even if monero suddenly was looking to other projects instead of the research for leadership for some reason, would one other major project be sufficient ? https://pq.ethereum.org
21:16:17 <endogenic> and isnt btc kind of hosed without a turnstile anyway? (and good luck with that)
21:17:25 <endogenic> besides the nuances are so specific to what we actually do that it requires analysis of what we actually do. like randomx is for example probably fine, as i understand it
21:18:23 <endogenic> but other things will not be fine. ecc signing and key exchange are broken by a likely imminent or already existent qc
21:20:46 <br-m> <syntheticbird> Regarding assessing monero's vulnerability to quantum computers, I'll just post these two gist from jeffro that for some reason people are tending to forgot: https://gist.github.com/jeffro256/4155401274699e0437ba5b79b93c647f https://gist.github.com/jeffro256/ce35d497f3f191629a6a00da5e6ab828
21:23:15 <endogenic> sounds like jeffro's being elite again
21:23:37 <endogenic> it's more comfortable to forget
21:23:40 <endogenic> sometimes
21:23:48 <endogenic> but it won't be possible soon
22:49:05 <br-m> <sgp_> @jberman: Fwiw, MAGIC Grants already has money set aside for this, so we can act on expertise asap
22:50:29 <br-m> <sgp_> @syntheticbird: It's almost like random gists get lost 😅