15:01:30 <br-m> <rucknium> MRL meeting in this room in two hours.
15:15:30 <br-m> <thomasbuilds:matrix.org> I can’t be there for the meeting, sharing this for potential discussion:
15:15:30 <br-m> <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.
15:15:30 <br-m> <thomasbuilds:matrix.org> What's new though, that I haven't raised is F2 (medium), "shared custom unlock_time makes one unbounded tree growth"
15:59:07 <br-m> <rucknium> Isn't that topic better for #no-wallet-left-behind:monero.social meetings?
16:01:10 <br-m> <rucknium> AFAIK here's the link for that AI review: https://github.com/xmrack/monero-review/issues/1011
16:04:30 <br-m> <thomasbuilds:matrix.org> as you wish
16:04:49 <br-m> <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
16:05:16 <br-m> <thomasbuilds:matrix.org> vuln is commented out right now. but plan is to uncomment it.
16:06:29 <br-m> <thomasbuilds:matrix.org> https://github.com/monero-project/monero/pull/11425#discussion_r4172805190
16:11:51 <br-m> <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.
16:13:52 <br-m> <jberman> Good with me to discuss, I planned to discuss this issue https://github.com/seraphis-migration/monero/pull/499 today as well
17:00:42 <br-m> <rucknium> Meeting time! https://github.com/monero-project/meta/issues/1470
17:00:46 <br-m> <rucknium> 1. Greetings
17:01:01 <br-m> <jberman> waves
17:01:06 <rbrunner> Hello
17:01:27 <br-m> <vtnerd> Hi
17:01:43 <br-m> <gingeropolous> hello
17:02:13 <br-m> <ack-j:matrix.org> Hey
17:03:22 <br-m> <jbabb:cypherstack.com> Howdy
17:03:23 <br-m> <rucknium> 2. Updates. What is everyone working on?
17:04:11 <br-m> <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: https://github.com/Fountain5405/monerosim/blob/dev/docs/20261007_sop_campaign7_results.md#7-spec-findings-candidates-for-mrl-146-the-owner-decides
17:04:20 <br-m> <interestingband:matrix.org> (spectating)
17:04:47 <br-m> <rucknium> me: Getting my Nyx eclipse analysis into reproducible form. Helping a little with stressnet.
17:04:52 <br-m> <vtnerd> Tracking down a few bugs in monerod. Also spent some time working on lwcli (not ccs) which now has proper address book support
17:05:36 <br-m> <vtnerd> Oh and finally published my updated thoughts on wallet encryption 
17:06:00 <br-m> <gingeropolous> also launched data collecting effort for stressnet. uses a secondary program (sidecar) to report data to a collector
17:06:34 <br-m> <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 https://github.com/seraphis-migration/monero/pull/499 ). We can discuss this further now or later. Also beta v3 stressnet hard forked a [... too long, see https://mrelay.p2pool.observer/e/yaLQhrILRXlwdnBD ]
17:07:16 <br-m> <rucknium> 3. FCMP++ to-do list status. Programming tasks (https://github.com/seraphis-migration/monero/issues/53). Reviews and audits (https://cryptpad.fr/sheet/#/2/sheet/view/yPVIUywwA9-deE9VF6GYm9bXbPdCerdST3UDEEfBxcM/embed/). FCMP++ Integration Audit Overview (https://github.com/seraphis-migration/monero/issues/294). Network upgrade  [... too long, see https://mrelay.p2pool.observer/e/rfHShrILa1l4dlpJ ]
17:08:27 <br-m> <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
17:09:32 <br-m> <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
17:11:15 <br-m> <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
17:12:04 <br-m> <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
17:12:26 <br-m> <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
17:12:52 <br-m> <jberman> (and someone can compile with it turned on)
17:13:30 <br-m> <sgp_> would an fcmp++ branch help or would it make things even more annoying?
17:14:10 <br-m> <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
17:14:32 <br-m> <jberman> and not expect every new PR to also be applied to an fcmp++ branch
17:16:38 <br-m> <jberman> maybe @selsta will have an opinion on that too
17:17:15 <selsta> compiler flag seems best for me
17:17:30 <br-m> <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
17:17:44 <br-m> <jberman> right
17:18:32 <br-m> <sgp_> gotcha, then it's probably fine from the rfq perspective
17:18:54 <br-m> <jberman> I'll do the compiler flag as well
17:21:56 <br-m> <jberman> Re: https://github.com/seraphis-migration/monero/pull/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 https://mrelay.p2pool.observer/e/0cqIh7ILV19adWlz ]
17:23:51 <br-m> <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.
17:24:43 <br-m> <rucknium> IIRC, last hard fork, "leftover" txs were dropped anyway because of an insufficient fee bug.
17:24:56 <br-m> <rucknium> "This time, it's deliberate"
17:25:08 <br-m> <jberman> The solution in https://github.com/seraphis-migration/monero/pull/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 https://mrelay.p2pool.observer/e/9qWUh7ILWENlX1BI ]
17:26:12 <br-m> <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)
17:27:07 <br-m> <jberman> We'd essentially be saying some expected valid txs might get dropped around the time of the fork, which isn't ideal
17:29:03 <br-m> <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
17:30:08 <br-m> <rucknium> What would be the risks if wallet software started constructing FCMP-compatible txs 10 blocks before the fork height?
17:31:51 <br-m> <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
17:33:14 <br-m> <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?
17:33:43 <br-m> <jberman> they would need to recreate those payments
17:34:55 <br-m> <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?
17:35:31 <br-m> <rucknium> This will probably be 100 txs that are ejected from the txpool if no one spams during the fork.
17:36:00 <br-m> <jberman> They notify an error if the tx doesn't reach the node's pool (or is kicked from the pool)
17:36:25 <br-m> <rucknium> Last time, someone spammed right before the fork. (Someone claimed responsibility for this at a MoneroKon or Monerotopia conference years later IIRC.)
17:39:00 <br-m> <rucknium> Does someone want to discuss this ^ topic? > <@thomasbuilds:matrix.org> I can’t be there for the meeting, sharing this for potential discussion:
17:39:00 <br-m> <rucknium> > xmrack's AI review for 11425 flags a “critical” issue. The description seems consistent with my own second review point of the PR.
17:39:00 <br-m> <rucknium> > What's new though, that I haven't raised is F2 (medium), "shared custom unlock_time makes one unbounded tree growth"
17:39:27 <br-m> <rucknium> The AI review is here: https://github.com/xmrack/monero-review/issues/1011
17:39:32 <br-m> <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
17:39:57 <br-m> <jberman> Yea, I'll discuss that as well
17:42:35 <br-m> <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
17:44:14 <br-m> <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
17:46:54 <br-m> <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)
17:47:22 <br-m> <jberman> If we had all this stuff in 1 PR FWIW, I'd be working through 1000 LLM comments at this point
17:50:00 <br-m> <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   
17:50:54 <br-m> <jberman> I guess I can introduce that consensus rule into this PR as well
17:51:35 <br-m> <rucknium> @jberman: That's what I thought as well. It's a moot point.
17:52:23 <br-m> <rucknium> More on this agenda item?
17:52:58 <br-m> <jberman> nothing from me
17:54:12 <br-m> <rucknium> 4. FCMP beta stressnet (https://github.com/seraphis-migration/monero/releases/).
17:54:21 <br-m> <rucknium> We have forked!
17:55:07 <br-m> <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?
17:55:07 <br-m> <ack-j:matrix.org> https://github.com/monero-project/monero/pulls?q=is%3Apr+label%3Afcmp%2B%2B+state%3Aclosed
17:55:17 <br-m> <rucknium> My stressnet monitors are up. Not much going on at the moment: https://stressnetnode1.redteam.cash/ https://stressnetnode2.redteam.cash/
17:55:57 <br-m> <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.
17:56:07 <br-m> <jberman> on beta v3: so far the 2 notable reported issues I've seen are just from GUI binaries plumbing
17:56:34 <br-m> <jberman> which have a known and implemented solution already, just need to port the solution
17:57:14 <br-m> <jberman> @ack-j:matrix.org: sure, and compare to master to see if any of it has already changed or been addressed
17:57:56 <br-m> <rucknium> Some of us are feeding @gingeropolous:monero.social stressnet data so some analysis can be done: https://github.com/Fountain5405/stressnetmonitor
17:59:57 <br-m> <rucknium> Discussion of stressnet is happening in #monero-stressnet:monero.social on Matrix and ##monero-stressnet on Libera IRC I think.
18:01:21 <br-m> <rucknium> More discussion of this topic?
18:02:41 <br-m> <rucknium> 5. Shi et al. (2026) "Are Unreachable Nodes Truly Safe? Fully Eclipsing Monero’s P2P Network!" (https://arxiv.org/pdf/2609.10260)
18:03:46 <br-m> <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.
18:04:04 <br-m> <rucknium> https://mrelay.p2pool.observer/m/monero.social/YpBcrtEzNiVVBHaYDyErKhrY.png (white_list_unreachable.png)
18:04:45 <br-m> <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.
18:05:09 <br-m> <rucknium> https://mrelay.p2pool.observer/m/monero.social/mbvSyQoCpqeFIYgnBusgbwgK.png (white-list-unreachable.png)
18:05:42 <br-m> <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.
18:06:02 <br-m> <rucknium> But anyway, the same result happens. Just wanted to make sure it worked with the longer sim time.
18:06:18 <br-m> <rucknium> https://mrelay.p2pool.observer/m/monero.social/TdwwkZRUhcHTPhItvshfotYb.png (outbound-adversaries-unreachable.png)
18:07:28 <br-m> <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.
18:09:19 <br-m> <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.
18:10:35 <br-m> <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.
18:11:31 <br-m> <rucknium> That concludes my update on this agenda item.
18:13:51 <br-m> <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 https://mrelay.p2pool.observer/e/x9bGiLILRjFYVmpf ]
18:14:23 <br-m> <rucknium> This is where I did multiple simulations and estimated confidence intervals on outcomes, previously: https://gist.github.com/Rucknium/ba230a2bab8a446d0997b7b002bf3af6
18:15:00 <br-m> <rucknium> More on this topic?
18:16:51 <br-m> <jeffro256> Ruck is CGO: chief graph officer 
18:17:39 <br-m> <rucknium> We can end the meeting here. Thanks everyone.
18:17:58 <br-m> <jeffro256> Thank you 
18:19:36 <br-m> <sneedlewoods_xmr:matrix.org> @vtnerd: Can you share a link please?
18:25:35 <br-m> <vtnerd> https://github.com/jeffro256/carrot/issues/9#issuecomment-5942696358
18:26:22 <br-m> <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
18:26:42 <br-m> <vtnerd> *Metadata kdfed from root 
18:27:52 <br-m> <vtnerd> The existing layout means a spend pubkey crack would reveal wallet crypto, whereas this won't be an issue with the carrot design 
19:08:20 <br-m> <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."
19:08:53 <br-m> <gingeropolous> and apparently as writ "SoP is a hard fork, not a soft fork."