<kayabanerve:matrix.org> I may or may not be present. I'm currently slammed for the next couple weeks, sorry. In this time, I've deferred primarily to @sgp_:monero.social: so if they ACK the relevant work...

<tomdooley:matrix.org> hi guys just wanted to make a note of this new p2pool mining app (beta version)for Umbrel servers, delete if not relevant to this chat:

<tomdooley:matrix.org> x.com/MgkMshrmBrkfst/status/2018633822959751655

<rucknium> @tomdooley:matrix.org: #monero-community:monero.social would be a better room for that. Or #monero-community-dev:monero.social .

<suhyeon:matrix.org> Hello Monero guys. Thanks to the support of your community -especially DataHoader and sech1- our manuscript on the analysis of Qubic’s selfish mining on Monero has been completed. Although this was a truly independent side project for me, it was a meaningful experience for all of us to examine the real world attack campaign.

<suhyeon:matrix.org> * Link: arxiv.org/pdf/2512.01437

<suhyeon:matrix.org> The main updates are as follows:[... more lines follow, see mrelay.p2pool.observer/e/r6TTjuMKa2hFcV9H ]

<spirobel:kernal.eu> @suhyeon:matrix.org: what is your next topic of research? would be glad to see more Monero related work 👍️

<suhyeon:matrix.org> As I work in the Ethereum Layer 2 domain, my current focus is on analyzing the optimal trade-offs between fraud proofs based on the bisection game and fraud proofs based on zero-knowledge proofs (ZKPs).

<suhyeon:matrix.org> My approach is to perform the bisection game two to three times and then complete the fraud proof using a ZKP.

<suhyeon:matrix.org> With this design, the ZKP workload should be feasible on a personal computer, while keeping latency minimal through a small number of bisection rounds.

<rucknium> MRL meeting in this room in one hour and forty-five minutes.

thanks Rucknium

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

<rucknium> 1. Greetings

Hello

<sgp_> hello

<gingeropolous> hi

<vtnerd> Hi

<jberman> waves

<rucknium> @brandon:cypherstack.com: Are you available to answer questions about agenda item 4, Goodell (2026) "Generalized Bulletproofs for Opening Vector Commitments." (github.com/cypherstack/generalized-bulletproofs-fix)

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

<rucknium> me: Working on my Monerotopia conference talk.

<gingeropolous> still banging my head against running 1000 monero agents on 256 threads. getting closer.

<vtnerd> Me: resolving lwsf/monero_c issues on macos. Testing lwsf beast framework further

<syntheticbird> Hi

<ack-j:matrix.org> Hi

<jberman> me: we released v1.6 of the alpha stressnet that includes tx relay v2, I submitted PR's to improve type organization & dependency management in the FCMP++ integration, and misc PR wrangling

<ack-j:matrix.org> MAGIC: Launched a new fundraiser to research more efficient bulletproofs. Working on the reddit post

<ack-j:matrix.org> donate.magicgrants.org/monero/projects/2026-range-proofs-speedup

<rucknium> 3. zkSecurity quote for reviewing Elliptic Curve Divisors for FCMP++.

<sgp_> Cool this is me

<rucknium> Last meeting @sgp_:monero.social said that zkSecurity quoted MRL 50,000 USD for performing a mathematical review of EC Divisors. This would be the third review of EC Divisors.

<sgp_> I would like approval here to move forward with the funding of this from the FCMP research fund

<sgp_> The research community previously expressed a desire for a third review of divisors, given the complexities of the review process for it in the past

<sgp_> This quote is an "all inclusive" quote. If it takes them longer than they anticipate to sufficiently support the scheme for Monero's intended use, then they will cover the additional time at no extra cost

<rucknium> > <@kayabanerve:matrix.org> I may or may not be present. I'm currently slammed for the next couple weeks, sorry. In this time, I've deferred primarily to @sgp_:monero.social: so if they ACK the relevant work...

<rucknium> kayabaNerve said yesterday: "I may or may not be present. I'm currently slammed for the next couple weeks, sorry. In this time, I've deferred primarily to sgp_ : so if they ACK the relevant work..."

<sgp_> This was chosen because I specifically didn't want to kick the can again. I would like for divisors, if zkSecurity concurs with their suitability, to be considered safe to move forward with

<rucknium> Anyone can input their opinion here.

How much is USD 50,000 of the funds remaining for such things, give or take?

<articmine> Hi sorry I am late

<jberman> Strong +1 from me. Mathias Hall-Andersen, co-author on the curve trees paper, is the one communicating with sgp as well

<rucknium> IMHO, it's a good idea to do this because getting it wrong could be catastrophic for the post-FCMP blockchain. This would be triple-checking something that is very high stakes.

<sgp_> there is about 760 XMR left in the fund (this may exclude one payment to CS that is due?), and this would be ~143 for XMR@$350

Thanks, sounds good on that front

How will they do it, start with the results from the earlier reviews, or do it independently, to be on the safe side?

<sgp_> for GBP review (a separate item), an additional ~285 is expected fwiw. I'm not looking for approval for that today

<jberman> (760 XMR does exclude the ~20-25xmr payment to CS that's due)

<gingeropolous> im excited for another review. randomx got like 4, and i feel fcmp is even more critical

I mean, immune from influence

<rucknium> The aim is to get loose consensus on this proposal at this meeting. I have seen support so far. Anyone want to raise another opinion with this?

<articmine> In favor > <@sgp_> I would like approval here to move forward with the funding of this from the FCMP research fund

<sgp_> rbrunner: We gave them flexibility to choose the method so long as they are able to confidently and clearly demonstrate its safety

Alright, they will know what they do :)

<sgp_> I think they will use the initial approach not the CS approach

<rucknium> @sgp_: @sgp_:monero.social: Can you stay for the next agenda item for questions on that?

<sgp_> Ok

We will more or less put the future faith of Monero on this, right? So that's a +1 from me

<sgp_> yes it is essential that divisors are actually secure to use

*fate of course ...

<sgp_> fwiw, both Veridise and CS have signed off on the safety of them, albeit through different supporting methods

<sgp_> so this third one is because of an abundance of caution

<rucknium> I see loose consensus in favor of hiring zkSecurity to review Elliptic Curve Divisors for 50,000 USD.

<rucknium> 4. Goodell (2026) "Generalized Bulletproofs for Opening Vector Commitments." (github.com/cypherstack/generalized-bulletproofs-fix)

<sgp_> @rucknium: Great, I will move ahead with the project ASAP

<rucknium> This paper suggests a change to the Generalize Bulletproofs implementation in FCMP. It is a change to eliminate a possible vulnerability AFAIK. It could increase the computational expense of them.

<rucknium> But @kayabanerve:matrix.org is busy with other tasks for the next few weeks.

<rucknium> Implementing this for the beta stressnet was also discussed.

<sgp_> My understanding is that CS made these recommended changes because they believe the performance impact is likely to be tolerable. But ultimately this is waiting on kayaba (or anyone else crazy enough to jump into this task I guess?) to properly evaluate it. And they are busy for the immediate future

<rucknium> Is @jeffro256:monero.social here?

<syntheticbird> what does possible means here? It's suspected but unproven yet, or is it certain to be possible to exploit

<sgp_> CS believes that the prior approach is insecure, in basic terms

<sgp_> and they suggested this change to fix it

<rucknium> Is the suggested change something that could be implemented in code by someone else, like @jberman:monero.social or @jeffro256:monero.social ?

<jberman> On the implementation side, I'm waiting until kayaba is availalbe to continue this task item (as well as a couple others for beta). From my view, that is likely to be the most efficient way forward at this time

<sgp_> I got a quote from zksecurity as well on GBPs before this change was proposed. I expect it will be the same with the change, if kayaba/others sign off on its use: $100k

<rucknium> @sgp_:monero.social: For that quote can we get a written scope of work, before it's ready for loose consensus discussion?

<sgp_> Sure, the quote before was just an estimate. It was less of a formal proposal

<jberman> @jberman: kayaba was in discussions with CS on this, and obviously has more acute knowledge of all sections that should be modified

<articmine> Can we wait for kayaba's analysis for this?

<rucknium> @jberman: @jberman:monero.social: That sounds good to me

<sgp_> fwiw I am not asking for approval of this quote today. I'm just sharing an expectation of what it'll look like when it's ready

<sgp_> I think the purpose of this meeting item was to discuss the blocker and see if someone other than kayaba wanted to handle it? idk

<rucknium> Yes. And give people a chance to discuss the paper. It was posted during last week's meeting.

That could develop into the last thing that gets final form

<jberman> We have work that can proceed in parallel for getting FCMP++ to mainnet. I think the reasonable course of action is waiting on kayaba to continue this item for now

Yeah, didn't want to propose a different course of action. Just a mini-revelation, if you want

<jberman> w.r.t. zkSec's 100k quote to review GBP: considering we have a proposed change to GBP at this stage, I think another independent review is evidently justified

<rucknium> @jberman:monero.social: Do you mean in addition to zkSec's proposed review?

<sgp_> we in theory could jump straight into review of the modification, but it's likely sensible to ensure that we actually want to use it with the modification

<jberman> Tbc, I agree with sgp^ there. I would like to see GBP independently reviewed again, after this latest proposed change is sufficiently vetted (which is blocked on kayaba)

<brandon:cypherstack.com> @syntheticbird: The old version of GBP was provably insecure. Period.

<brandon:cypherstack.com> Also. Good morning, sorry for the delay in joining

<rucknium> @brandon:cypherstack.com: No problem. I should have pinged you earlier :)

<rucknium> @brandon:cypherstack.com: What is your opinion on review GBP, including your suggested modifications. Is zkSecurity a good choice?

<brandon:cypherstack.com> The question is not whether the old version is acceptably secure. It isn't. The question is whether my proposed changes are going to blow up efficiency. There will be an efficiency hit, I don't think it's a game changer, but I haven't had time to work out the specific comparison.

<brandon:cypherstack.com> @rucknium: I think so.

<articmine> By efficiency do you mean verification time, size or both?

<rucknium> @brandon:cypherstack.com: This is probably hard to answer now: How reasonable is it to expect that a more efficient method than yours could be discovered for constructing GBP? Or is it do or die with this, regardless of the efficiency loss?

<brandon:cypherstack.com> My back of the envelope says GBPs will be about 25% larger and an unknown additional verification time. GBPs don't take up the full transaction space so the space complexity worsening should be less than 25%

<brandon:cypherstack.com> @rucknium: I don't believe that any version of gbps can be made smaller, although proving systems that are outside of the bulletproofs framework might

<articmine> @brandon:cypherstack.com: I am not covered about this ballpark. It will have a minimal impact on scaling

<articmine> *Concerned

<ack-j:matrix.org> @brandon:cypherstack.com: how much or little would optimizations to bulletproofs+ help optimize GBP?

<brandon:cypherstack.com> An optimization to bp+ would make the bp+ part of the proof smaller but not the GBP parts

<rucknium> More questions or comments on this item?

<rucknium> Thank you, @brandon:cypherstack.com , for your work on GBP and answering questions here.

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

<jberman> We released v1.6 of the alpha stressnet yesterday. It includes tx relay v2 (and connection patches that were upstreamed). It doesn't include FCMP++/Carrot changes

<jberman> Hopefully we'll get some people running that just to make sure tx relay v2 is running smoothly, so we can port it to beta / upstream it

<jberman> A related item: I also made progress on audit prep for the FCMP++ integration

<rucknium> I have read some papers that warn that BTC's default number of outbound connections may too low to resist eclipse and network partition attacks. BTC has 8 full outbound connections and 2 block-relay-only outbound connections by default. Monero 's default outbound connection count is 12.

<rucknium> So Monero's resistance to eclipse and partitioning attacks could increase if some of the efficiency savings for tx relay v2 is used to increase the default number of outbound connections.

<jberman> @jberman: Here is essentially what I'm thinking, 4 stages: paste.debian.net/hidden/82c00500

<rucknium> "As soon as you save some money, there is the temptation to spend it." 😉

<boog900> Cuprate has a higher limit FWIW

<boog900> or default I should say

<jberman> Raising the default after the fork could make sense, to ensure the node is connected with peers supporting tx relay v2

<boog900> it also helps for the fluff stage of d++

<rucknium> @jberman: @jberman:monero.social: Should the integration audit prep go on the agenda next week as a dedicated item? Or is it covered in #no-wallet-left-behind:monero.social meetings?

<jberman> We can add it as a dedicated item for next week. I'm not planning to start reaching out to firms until the crypto code is settled (and docs are updated)

<rucknium> Anything more on stressnet?

<jberman> Nothing from me

<rucknium> 6. CARROT Outgoing View Keys (OVKs) (github.com/jeffro256/carrot/blob/master/carrot.md#22-new-wallets-only).

<rucknium> Anything more to discuss about OVKs at this time?

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

<jberman> thank you

<articmine> Thanks

<gingeropolous> thanks!