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

<thomasbuilds:matrix.org> I can’t be there for the meeting, sharing this for potential discussion:

<thomasbuilds:matrix.org> xmrack's AI review for 11425 flags a “critical” issue. The description seems consistent with my own second review point of the PR.

<thomasbuilds:matrix.org> What's new though, that I haven't raised is F2 (medium), "shared custom unlock_time makes one unbounded tree growth"

<rucknium> Isn't that topic better for #no-wallet-left-behind:monero.social meetings?

<rucknium> AFAIK here's the link for that AI review: xmrack/monero-review #1011

<thomasbuilds:matrix.org> as you wish

<jpk68:matrix.org> I saw that too, and it would be good to make sure people are aware of this, but that's just me

<thomasbuilds:matrix.org> vuln is commented out right now. but plan is to uncomment it.

<thomasbuilds:matrix.org> monero-project/monero #11425#discussion_r4172805190

<rucknium> Looks like the meeting is going to be short, so there is room for other topics. I would defer to @jberman:monero.social on whether it make sense to discuss it at this meeting.

<jberman> Good with me to discuss, I planned to discuss this issue seraphis-migration/monero #499 today as well

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

<rucknium> 1. Greetings

<jberman> waves

Hello

<vtnerd> Hi

<gingeropolous> hello

<ack-j:matrix.org> Hey

<jbabb:cypherstack.com> Howdy

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

<gingeropolous> me: working on monerosim. speedup unlocked - faster startup times (weird thing with monerod), using all threads (bug in shadow). Also investigating selfish mining and mitigations. Feedback needed here: github.com/Fountain5405/monerosim/b…dates-for-mrl-146-the-owner-decides

<interestingband:matrix.org> (spectating)

<rucknium> me: Getting my Nyx eclipse analysis into reproducible form. Helping a little with stressnet.

<vtnerd> Tracking down a few bugs in monerod. Also spent some time working on lwcli (not ccs) which now has proper address book support

<vtnerd> Oh and finally published my updated thoughts on wallet encryption

<gingeropolous> also launched data collecting effort for stressnet. uses a secondary program (sidecar) to report data to a collector

<jberman> @ack-j:matrix.org did (another) major review pass on the FCMP++ and Carrot integration code and found that the fix for the detectable inflation issue was insufficient ( see the latest fix here seraphis-migration/monero #499 ). We can discuss this further now or later. Also beta v3 stressnet hard forked a [... too long, see mrelay.p2pool.observer/e/yaLQhrILRXlwdnBD ]

<rucknium> 3. FCMP++ to-do list status. Programming tasks (seraphis-migration/monero #53). Reviews and audits (cryptpad.fr/sheet/#/2/sheet/view/yP…9VF6GYm9bXbPdCerdST3UDEEfBxcM/embed). FCMP++ Integration Audit Overview (seraphis-migration/monero #294). Network upgrade [... too long, see mrelay.p2pool.observer/e/rfHShrILa1l4dlpJ ]

<jberman> On upstream FCMP++ integration PR's: the outstanding PR's include all code that is meant to prevent inflation at consensus. I'm working through AI reviews now, which have found some notable items

<sgp_> @jberman:monero.social: some of the tree building code from phase 3 is commented out like we talked about, is there a reason why they shouldn't be uncommented prior to getting the quotes? Or is something blocking them or whatever

<jberman> Uncommenting would have the tree built on any monerod running from the master branch. The upstream FCMP++ lib code has been modified a few times over the last months in ways that render the prior tree execution incompatible with those changes

<jberman> So I was thinking it may make sense to wait until we want to declare the upstream FCMP++ lib code definitively finalized such that no future changes to the tree are expected

<jberman> I could also have it be off by default with a compiler flag, and then we can remove that compiler flag later to enable

<jberman> (and someone can compile with it turned on)

<sgp_> would an fcmp++ branch help or would it make things even more annoying?

<jberman> it would be nice to have this all on master branch sooner rather than later so it's kept at pace with the (fairly rapid) changes on master

<jberman> and not expect every new PR to also be applied to an fcmp++ branch

<jberman> maybe @selsta will have an opinion on that too

compiler flag seems best for me

<sgp_> so it's just commented only because of build related things, not because it's unfinished, that is the main thing I wanted to check on

<jberman> right

<sgp_> gotcha, then it's probably fine from the rfq perspective

<jberman> I'll do the compiler flag as well

<jberman> Re: seraphis-migration/monero #499 . The context: Carrot outputs and legacy outputs use a distinct key image generator. If a Carrot output was to be used in a CLSAG, the code would use the legacy (biased) key image generator producing a distinct key image for that Carrot output. Thus if we allowed CLSAG [... too long, see mrelay.p2pool.observer/e/0cqIh7ILV19adWlz ]

<rucknium> What if this time there was no "double fork" 24-hour grace period? It would inconvenience users at the fork height, but maybe it would be worth it to make the process safer.

<rucknium> IIRC, last hard fork, "leftover" txs were dropped anyway because of an insufficient fee bug.

<rucknium> "This time, it's deliberate"

<jberman> The solution in seraphis-migration/monero #446 is to prevent CLSAG rings that contain Carrot outputs. However, it relied on the code that gets the "max height" of a ring member to be correct, and unfortunately it isn't since the ring member's id calculation can overflow and wrap around, which causes the [... too long, see mrelay.p2pool.observer/e/9qWUh7ILWENlX1BI ]

<jberman> @rucknium: I'm not strongly opposed to this. It's a nice-to-have that we still need to validate is even working correctly (and txs aren't getting dropped)

<jberman> We'd essentially be saying some expected valid txs might get dropped around the time of the fork, which isn't ideal

<jberman> We can do everything we can to make sure this interim fork code is airtight to make sure there isn't inflation. It does widen the surface for things to go wrong though

<rucknium> What would be the risks if wallet software started constructing FCMP-compatible txs 10 blocks before the fork height?

<jberman> Immediate answer is I think that would a riskier change. If we were to allow such txs into the pool early, we'd have to modify a lot of consensus critical code for verification too that has to make sure not to allow those txs into the chain until later

<ap4sh:matrix.org> (hi) if some pending txs get dropped at the fork, will wallets recover and resend them, or will users need to recreate those payments?

<jberman> they would need to recreate those payments

<rucknium> AFAIK, wallet software, at least the GUI and CLI, notify users if their txs fail to be confirmed after some time. Is that true?

<rucknium> This will probably be 100 txs that are ejected from the txpool if no one spams during the fork.

<jberman> They notify an error if the tx doesn't reach the node's pool (or is kicked from the pool)

<rucknium> Last time, someone spammed right before the fork. (Someone claimed responsibility for this at a MoneroKon or Monerotopia conference years later IIRC.)

<rucknium> Does someone want to discuss this ^ topic? > <@thomasbuilds:matrix.org> I can’t be there for the meeting, sharing this for potential discussion:

<rucknium> > xmrack's AI review for 11425 flags a “critical” issue. The description seems consistent with my own second review point of the PR.

<rucknium> > What's new though, that I haven't raised is F2 (medium), "shared custom unlock_time makes one unbounded tree growth"

<rucknium> The AI review is here: xmrack/monero-review #1011

<jberman> Personally I'd prefer not to remove the grace period fork and get this code correct. But if the idea to remove it and allow some txs to get dropped at the fork gets more support, I'm not opposed

<jberman> Yea, I'll discuss that as well

<jberman> That "critical" issue would've been caught immediately once the code is enabled by (multiple I'm pretty sure) tests. It's a result of a snippet of DB code that I copy pasted into a different spot from our development branch because I felt it would make the code cleaner. That was a poor mistake on my part

<jberman> I made some other changes on that branch from our development branch in aims of making the code cleaner and stronger based on some comments I've gotten in different places over the months

<jberman> With the compiler flag for this FCMP++ integration code, we could turn it on for tests as well. I'm also going to introduce significantly more testing that we have in our development branch already, into the upstream master branch in later PR's (because it uses prover code, and I wanted to isolate consensus changes for review to focus in on the major potential consensus issues)

<jberman> If we had all this stuff in 1 PR FWIW, I'd be working through 1000 LLM comments at this point

<jberman> On "shared custom unlock_time makes one unbounded tree growth": this is yet another reason to drop the timelock feature. We're settled on the retroactive deprecation date so that won't be an issue

<jberman> I guess I can introduce that consensus rule into this PR as well

<rucknium> @jberman: That's what I thought as well. It's a moot point.

<rucknium> More on this agenda item?

<jberman> nothing from me

<rucknium> 4. FCMP beta stressnet (github.com/seraphis-migration/monero/releases).

<rucknium> We have forked!

<ack-j:matrix.org> @jberman:monero.social: do you think it would be worth while if I ran the same deep scan on the closed fcmp PRs?

<ack-j:matrix.org> github.com/monero-project/monero/pu…r+label%3Afcmp%2B%2B+state%3Aclosed

<rucknium> My stressnet monitors are up. Not much going on at the moment: stressnetnode1.redteam.cash stressnetnode2.redteam.cash

<rucknium> sech1 was tx spamming and filling 10MB blocks for a while, but he stopped so the blockchain didn't grow too big too quickly.

<jberman> on beta v3: so far the 2 notable reported issues I've seen are just from GUI binaries plumbing

<jberman> which have a known and implemented solution already, just need to port the solution

<jberman> @ack-j:matrix.org: sure, and compare to master to see if any of it has already changed or been addressed

<rucknium> Some of us are feeding @gingeropolous:monero.social stressnet data so some analysis can be done: github.com/Fountain5405/stressnetmonitor

<rucknium> Discussion of stressnet is happening in #monero-stressnet:monero.social on Matrix and ##monero-stressnet on Libera IRC I think.

<rucknium> More discussion of this topic?

<rucknium> 5. Shi et al. (2026) "Are Unreachable Nodes Truly Safe? Fully Eclipsing Monero’s P2P Network!" (arxiv.org/pdf/2609.10260)

<rucknium> I re-ran simulations for a longer 50 hours in-sim time. I wasn't satisfied with the 26-hr simulations because the white_lists didn't reach a steady-state equilibrium.

<rucknium> mrelay.p2pool.observer/m/monero.social/YpBcrtEzNiVVBHaYDyErKhrY.png (white_list_unreachable.png)

<rucknium> ^ This is the 26-hour run. You can see that the red line on both plots does not go up near the 1,000-peer threshold.

<rucknium> mrelay.p2pool.observer/m/monero.social/mbvSyQoCpqeFIYgnBusgbwgK.png (white-list-unreachable.png)

<rucknium> The 50-hr run almost reaches that. There are 1,000 adversary-controlled peers. It takes a while for them to be absorbed by the unreachable node's white_list.

<rucknium> But anyway, the same result happens. Just wanted to make sure it worked with the longer sim time.

<rucknium> mrelay.p2pool.observer/m/monero.social/TdwwkZRUhcHTPhItvshfotYb.png (outbound-adversaries-unreachable.png)

<rucknium> @gingeropolous:monero.social helped make the sims run faster. We are at 15 hours of wall-clock time for this 50-hr in-sim time simulation.

<rucknium> I've been working on making the analysis reproducible. It is sometimes surprising how much time it can take to gather scattered scripts and data and write understandable reproduction instructions. But if it's not reproducible, it's not science! Once I'm done with that, which should be within 24 hours, I'll make the suggested changes as a PR.

<rucknium> Well, it won't be "easily" reproducible from scratch if you don't have a 1TB-RAM machine. But I will include the raw sim data. I may try to create a scaled-down sim that should show the results, after making the PR.

<rucknium> That concludes my update on this agenda item.

<rucknium> Actually, one more thing. @gingeropolous:monero.social and I notice that sometimes the status quo sim results in a sustained 12/12 eclipse, and sometimes only intermittent 12/12 eclipse. I think that's because of randomness in the sim. That just brings up why running the sim multiple times can be important. In this simulation [... too long, see mrelay.p2pool.observer/e/x9bGiLILRjFYVmpf ]

<rucknium> This is where I did multiple simulations and estimated confidence intervals on outcomes, previously: gist.github.com/Rucknium/ba230a2bab8a446d0997b7b002bf3af6

<rucknium> More on this topic?

<jeffro256> Ruck is CGO: chief graph officer

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

<jeffro256> Thank you

<sneedlewoods_xmr:matrix.org> @vtnerd: Can you share a link please?

<vtnerd> jeffro256/carrot #9#issuecomment-5942696358

<vtnerd> Got snuck into carrot. Basically I want to encrypt metadata with root secret. Carrot is better because spend key is kdfed from root key

<vtnerd> *Metadata kdfed from root

<vtnerd> The existing layout means a spend pubkey crack would reveal wallet crypto, whereas this won't be an issue with the carrot design

<gingeropolous> does anyone have their head around share or perish? according to the bots, the spec is leaving some things unspecified, and im having a hard time simulating SoP not knowing what it should be: "The fork-choice loop is unspecified. The spec does not say whether blocks displaced by a reorg are judged again one at a time or as a whole branch."

<gingeropolous> and apparently as writ "SoP is a hard fork, not a soft fork."