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

Can we add this to the meeting agenda? jeffro256/carrot #10

The second fix is relatively easy to implement, but would need to be fast-tracked to meet the code freeze deadline and possibly be audited.

<rucknium> Yes

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

<rucknium> 1. Greetings

<ack-j:matrix.org> Hi

<rucknium> @jeffro256:monero.social: ping

Hello

<vtnerd> Hi

Hi

hello

<jberman> waves

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

<rucknium> me: Keeping stressnet stressed. We hit 20MB blocks this week. Stressnet bugs.

<syntheticbird> Hi

<jpk68:matrix.org> Hello

<redsh4de:matrix.org> hi

<jberman> me: after combing through @rucknium:monero.social 's stressnet logs, implemented a series of fixes addressing the most significant apparent issues surrounding tx relay (some upstream, some pertaining to tx relay v2 that we'd want in for the first release of the protocol)

<vtnerd> Me: looked at lws DB locking issue, updated weak ptr pr which finally appears mergable, worked a little on strand blocking issue, and have looked at another serialization issue

<articmine> Hi

<rucknium> 3. PQ turnstile spend enables a Carrot/Jamtis distinguisher (privacy leak) (jeffro256/carrot #10).

Is jeffro256 present?

<rucknium> We can put this item later if you want, tevador

Basically - when the PQ turnstile protocol is activated (in the future when we want to migrate), it will leak more info than expected. A fix is proposed.

The fix needs to ne applied to Carrot before the HF.

OK, we can continue with the next item.

<rucknium> I will bundle the FCMP++ schedule with this one since they are related. I will go to relative locks next

<rucknium> 5. Relative locks with FCMP++ (monero-project/research-lab #161).

<rucknium> There was discussion in this room on Monday: libera.monerologs.net/monero-research-lab/20260803

<rucknium> Seems like there is good support for the boolean relative lock.

The last meeting agreed to reserve unlock_time = 1 without actually implementing the lock. I think implementing the lock is feasible for the HF.

<jberman> I'd prefer to focus entirely on what's critical for the hf personally, I think stopping at reserving unlock_time = 1 is ok

Pessimists might argue that something will force us into a relatively early hardfork one or the other way, and there we could implement this lock ..

*early follow-up hardfork

<rucknium> I've forgotten: For actual implementation of the lock, is a soft fork needed?

It could be a soft fork if unlock_time = 1 is reserved.

reserved meaning not rejected by consensus

Here is a rough amount of code needed to implement the consensus code: seraphis-migration/monero #445

<rucknium> Would it be a good idea to audit the implementation code?

<rucknium> If it were to be deployed with the HF

<jberman> This doesn't need an audit. The payment channel architecture and design perhaps ?

<rucknium> It's very short

But that can definitely come later?

<jpk68:matrix.org> Considering the double-spend issue that was fixed recently, the prospect of more complexity with this HF is a bit unsettling (especially if the code isn't audited)

And even multiple payment channel approaches implemented I guess

jpk68: Did you have a look at that 445 code?

I'll put tevador's #10 issue on my todo for today

<jpk68:matrix.org> I did, but FWIW the double-spend fix was even less lines of code

<jpk68:matrix.org> s/less/fewer/

<rucknium> I just think of the number of critical vulnerabilities patched in the BTC Lightning network code. Is it possible to bring payment channels to an audit standard? Or would it be checking if an implementation matches a paper? Anyway, that would be later on.

To minimize scope, the reservation of unlock_time = 1 only needs 3 lines (1 of which is a comment and 1 is a constant definition)

I am also often weary at more complexity, but if that code really is all on the consensus side, where would a problem hide there?

<rucknium> Thanks, UkoeHB

On monday I posted my revised ACK for the simple relative_lock as a 'prove it or lose it' opportunity for PC proponents.

I am sure there are myriads ways of messing up a payment channel implementation, but that's something else

<rucknium> I like the phrase :)

I think it's well known that payment channels can be implemented with just relative locks and adaptor signatures. The specific protocol is not important for the lock implementation.

Relative locks can also simplify some atomic swaps protocols.

the change would allow such designs (or if just the reservation is done, allow a soft fork later to allow the designs) but what tevador is asking for does not include any payment channel design/PoC in code directly to be included into codebase, only specific consensus changes to make them viable

<jberman> the code in that PR is incorrect. itwould allow a reference_block higher than chain height, because get_tree_root_at_blk_idx can return a tree root higher than chain height

(then there is the other suggestion that has extra fields on the tx, but afaik that's not in scope for this HF reservation)

<jberman> augh, nvm, spoken too soon

<jberman> the changes look ok on first pass

the question is whether to bring just reservation or that PR to implement relative blocks using the reservation for the HF

Maybe it's more complicated to find out whether somebody can do some nonsense, using those locks in malicious ways.

And if yes, how to mitigate if necessary

<rucknium> Could we view the choice this way?: Is it possible to implement actual relative locks without piling more on the plate of people who are chest-deep in the FCMP HF launch work?

this lock prevents including txs entirely, which is different from them being included and having weird stuff happening

That sounds hopeful

(so they'd wouldn't be "mineable" until the lock passes)

Has the code being touched by PR 445 already been audited?

<jberman> I think it's not a big deal to get this code in in terms of manpower. Maybe would be nice to have more time to think on the failure modes / concrete payment channel design, but it's such a small change that it's not an issue of manpower

<jberman> tevador: no

I think the audit scope expansion should be pretty minimal.

Seems to me it should be no problem to wait a little with this

<rucknium> @jberman:monero.social: Are you changing your mind about this, or you just don't feel very strongly about it? > <@jberman> I'd prefer to focus entirely on what's critical for the hf personally, I think stopping at reserving unlock_time = 1 is ok

<jberman> if people want it in, then manpower isn't the issue / this won't meaningfully delay FCMP++

<rucknium> Did tevador once enumerate all of Monero's soft forks?

Hmm, did we have any?

<rucknium> I am just thinking of how difficult it would be to soft fork later

<rucknium> IIRC, tevador had a broad definition of soft fork

I don't think Monero has ever had a soft fork

I tend to come back to reddit.com/r/Monero/comments/1mvmg4…of_all_of_moneros_consensus_changes which might not be correct

<jberman> I have some mild discomfort with a change that may lead to a sub-optimal design (payment channel txs have this fingerprint, fixed 720 days)

they call a few "soft forks"

<rucknium> Wasn't the counterfeiting bug at least a soft fork?

but these are more like, secret updates to miners to prevent specific attacks

yeah, #9 on that list

OK, technically the double spend fix was a soft fork

<jberman> 720 blocks*

jberman: Not all payment channel txs would actually use the time lock on-chain. It only appears when the channel is force closed (meaning there is a dispute).

<jberman> right, *the force close txs

What's the worst thing that can happen if we implement the lock? Nobody using it?

<rucknium> Maybe BTC Lightning forced closed txs on-chain could be measured. Or did the Taproot update obscure them?

<articmine> This does beg the question. The percentage of force closed TXs vs the increase in the annonimity set due to increased adoption as a result of payment channels.

There was a larger suggestion that did not use this unlock time field, and would remove that signal, but adds a new field to txs

<rucknium> I don't think the force-close txs would create much of a privacy problem. I am willing to listen to other views on that. IMHO, tx fungibility defects matter most when a user's wallet always or usually creates the defect. Then you can follow that wallet's behavior through time. In the extreme, you could even follow it with FCMP txs.

<rucknium> But you would not have a user always using force-close txs.

<jpk68:matrix.org> Why add part of it now, if the other half has to be added in a later fork anyways? Why not just add it all later?

jpk68: the point is to give PC advocates the chance to prove it's worth the extra effort/tx cost

or that's the point from my point of view ^.^

<rucknium> Should we move on for now or continue discussing this issue at this meeting?

19:46:33 <br-m> <jpk68:matrix.org> Why add part of it now, if the other half has to be added in a later fork anyways? Why not just add it all later?

to allow a soft fork (rule tightening) instead of hard fork

I think we should get a prod-oriented PR for the change and aim further discussion at that.

though the full set also looks very minimal, as shown in #445

<jpk68:matrix.org> If it goes unused, it's just going to create more technical debt for the future with no benefit

It's a chicken-egg problem. Nobody is going to design a payment channel for Monero using non-existent relative locks.

Well, somebody even tried to implement, but then ran into serious problems ...

It's a small price for a large opportunity, and the field can be eliminated if it proves useless.

This some small beside the complexity monsters that are FCMP++ and Carrot you can hardly see it :)

*This is so small

<jberman> tevador: Grease is seeking funding for their payment channel impl. Their request has seen resistance because they rely on trust in a key escrow service. I think there would be more interest in their request if it was to remove trust using this relative lock feature

Yes, I think Grease might be interested in using the relative lock in their protocol if it's implemented.

<rucknium> > Historical note: We based Grease on Monet/Auxchannel on the predicate that timelocks were unlikely to be added into Monero due to the heterogeneity they would introduce.

<rucknium> > But if they were to be implemented in FCMP in a ZK manner, then I agree, this approach is not only much better, it's basically a no-brainer.

<rucknium> monero-project/research-lab #161#issuecomment-5107532847

<jberman> It doesn't need to be implemented to spur that interest

<rucknium> That's what one of the Grease developers said.

"We based Grease on Monet/Auxchannel on the predicate that timelocks were unlikely to be added into Monero"

<rucknium> UkoeHB: What does everyone think about koe's suggestion? "I think we should get a prod-oriented PR for the change and aim further discussion at that."

Certainly allows a focussed long-time disucssion

AFAICS the PR only needs a test to be added?

Comment on the PR if anything else is missing.

<jberman> tevador: ya I think that calculus changes with this brand new development

<jberman> is there interest in funding Grease to develop their design with this new feature? if not, then why would we want it in?

<jberman> I don't think this is a chicken-and-egg problem. If there's interest today in Grease developing a design using this feature, then it lends support for the feature

IIRC their CCS was rejected mostly due to the key escrow requirement. With time-locks, I don't think anyone would oppose it.

<jpk68:matrix.org> Maybe this concern is unfounded, but making consensus changes for payment channels could potentially offload some of the onus to keep the base layer inherently scalable

<rucknium> This item will reappear next meeting. Let's move to the next item

<rucknium> 6. Shi, Zhang, Ge, Lan, Zhang, & Wang (2026) "Deanonymizing Monero Transactions in Tor Network." (arxiv.org/abs/2607.07062)

<rucknium> Does anyone now want to suggest specific code changes to mitigate the issues raised in the paper and/or volunteer to implement them? Or, especially, review them?

<boog900> This PR should fix one of the issues: monero-project/monero #11048

<rucknium> I was thinking more about putting Dandeion++ inside the Tor part of the relay. Besides the implementation complexity, it would probably suffer from easy black hole attacks because Tor Monero nodes are easily Sybil attacked.

<rucknium> And then if all the honest nodes get black hole attacked, you are almost back to square one. Or, you are back to BTC network privacy with the diffusion tx broadcast behavior.

<rucknium> Any thoughts on black hole attacks?

<vtnerd> That was my thought on d++ over tor, theres already an issue with quality relays

<vtnerd> I'm going to implement the address relay issue so it doesn't include it every response

<boog900> I do think we should do multiple hops over Tor tho

<boog900> even if not full D++

<vtnerd> And I'm going to look into hardening the timed sync requests to limit the timing analysis

<rucknium> By the way, a black hole attack on D++ occurs when a malicious peer decides not to relay a stem-phase D++ tx to another peer. It "swallows" the tx to prevent propagation. D++ has an embargo timer that will make the original tx originator ( and any honest nodes that got the tx during the stem phase) to initiate a fluff-phase tx broadcast behavior.

<vtnerd> multiple hops over tor would be similar to d++ as we don't send to every outbound tor connection iirc

<rucknium> @vtnerd: Thanks, @vtnerd:monero.social

<boog900> The goal would be to make it so someone getting a tx from an incoming Tor connection does not know they created the tx

<vtnerd> The way the code is written, implementing d++ over tor should be somewhat easy, but the results as you mentioned may be less desirable

<boog900> also I want to bring up this PR: monero-project/monero #9295

<boog900> Cuprate has those changes and this is making our tx-relay faster according to @gingeropolous:monero.social's monero-sim

<boog900> so faster and more private (more stem hops)

<rucknium> The change could be a good use case for monerosim. Try both versions.

<rucknium> More discussion of this item for now?

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

<rucknium> (We will go back to potential Carrot fix and FCMP schedule after this)

<rucknium> We thought we had squashed all of the tx relay bugs, but one more appeared

<jberman> Last week I had hoped to put out the next v2.1 release by this week. Ended up identifying a whole series of issues with @rucknium:monero.social 's logs, and made PR's for those. The most significant one includes some solid changes to tx relay v2: seraphis-migration/monero #450

<jberman> "but one more appeared" -> it turned out that this was apparently caused by an issue that this already-existing PR would fix seraphis-migration/monero #419 , but while digging found a whole bunch of other things worth fixing, including issues from tx relay v2 leading to nodes banning peers

<rucknium> So we finally reduced peer ban frequency? Nice.

<jberman> The changes to tx relay v2 are especially important imo because it includes a change to the messaging protocol, which we'd want in for the first release of tx relay v2

<rucknium> IMHO, peer bans weren't too bad, but it's nice that they will be reduced further.

<jberman> I think they also didn't appear as bad because stressnet unbans peers after 2m

<jberman> @rucknium: the changes would definitely reduce ban frequency (for one, because it stops banning peers and just drops connections lol), but the bulk of changes benefit most from all nodes on the network running them

<rucknium> mrelay.p2pool.observer/m/monero.social/jQXkPhEHVyFzDJjcBMKvxuZy.png (stressnet_blocksize_week_2026-08-05.png)

<rucknium> ^ We hit 20MB blocks this week. IIRC, 20MB blocks was hit on last year's stressnet, but this is the first time on this stressnet.

<rucknium> mrelay.p2pool.observer/m/monero.social/kZeJRfKupSfsQziIfLKiFeiN.png (stressnet_cpu_week_2026-08-05.png)

<rucknium> mrelay.p2pool.observer/m/monero.social/KClGPhaHOWkHDrlYfOcWmxja.png (stressnet_RAM_week_2026-08-05.png)

<rucknium> ^ That's CPU usage and RAM

<rucknium> Anything more on stressnet?

<rucknium> Those plots are from stressnetnode1.redteam.cash . The web app is blank right now because my nodes are catching up. Full storage with logs and everything. Needed to delete things.

<jberman> Reiterating a comment I made over in the nwlb channel: assuming the tx relay v2 changes go through, I lean toward wanting a v3 beta stressnet where everyone on the current beta stressnet would have to update to v3, so that we can test that these changes to tx relay v2 are working smoothly. Discussed briefly with @boog900:monero.social as well

<jberman> Not something that needs to be settled on right now, but just putting the thought out there

<rucknium> And it would reduce storage requirements :D

<jberman> well it would continue the current stressnet chain

<jberman> but I guess we could start over again if people wanted to do that too?

<boog900> You would want to keep the current scaling progress right?

<boog900> how hard is it to build up?

<rucknium> You mean a hard fork with the current chain? Or how do you get everyone to upgrade?

<rucknium> Takes a couple of weeks to get where we are. Now I have too much of a good thing and my storage is filling 🥲

<jberman> We could include something that just prevents new nodes from connecting to the v2 nodes, but continues with the current chain

<rucknium> I am OK to try to go a few more weeks with the current chain. I will have to cut the fat to the bone, on storage.

<rucknium> I think kico stopped mining because of too much storage required

<boog900> how big is it?

<boog900> the DB

<rucknium> 115GB pruned

<jberman> if stressnet participants would prefer a fresh chain to re-spam again, then I think that would be ok

I can add space :D

sorry forgot about the node xD

<jberman> thanks kico :)

np

on it :)

<jberman> in any case, I think we can cross that bridge of deciding next stressnet steps once/if the tx relay v2 changes go through fine

<rucknium> Sounds good. Anything else on stressnet?

<jberman> nothing from me

<rucknium> 3. PQ turnstile spend enables a Carrot/Jamtis distinguisher (privacy leak) (jeffro256/carrot #10).

<rucknium> tevador and @jeffro256:monero.social

Anyone is welcome to comment on the issue

<jberman> initial proposal seems reasonable to me

<rucknium> What are the downsides to these fix options? A cheap hash calculation and more review of this part of Carrot?

The fix using k_v would involve one extra elliptic curve operation when constructing a tx

<jberman> Does the alternative fix proposed remove the downside risk @jeffro256:monero.social mentioned of making K_v public leaking incoming history?

Correction: one extra elliptic curve operation when accepting an enote (unless we cache K_v^j)

K_v^j is not published in the PQ protocol. This might have been a misunderstanding by jeffro256.

jeffro256 complained that the fix involving k_v makes scanning clunky, hence the alternative proposal

<jberman> ack, I think will be best to give jeffro a chance to assess

<rucknium> 4. 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/oMqR5p0LREEzZjYw ]

<jberman> tobtoht prepared master for Rust build changes, which sets the stage for the Rust FFI getting to master here monero-project/monero #10359 , which is the 2nd to last PR from the Phase 1 audit

<jberman> The last PR from Phase 1 is relatively small compared to the priors

<jberman> Then it's on to Phase 2 PR's. I don't think an audit needs to hold up the Phase 2 PR's from merge, but arguably still worth auditing alongside Phase 3 especially taking into account the recently identified double spend vuln that would have been in Phase 3 scope

Link to vuln?

<jberman> We're also working on getting quotes for a secondary audit of the Rust FCMP++ lib circuit and gadgets impl (in addition to the fcmp-plus-plus Rust lib), as part of the Research audit task. This covers the section of code analogous to Zcash's recent hidden inflation vuln

<jberman> UkoeHB: seraphis-migration/monero #446

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

foreshadowing comment: monero-project/research-lab #142#issuecomment-3215321512

20:38:26 <br-m> <jberman> if stressnet participants would prefer a fresh chain to re-spam again, then I think that would be ok

I'd prefer some space cleanup, another heavy session and might run of (fast) storage I have for stressnet. but if that sets back the size scaling, maybe not

gingeropolous

woops