<jberman> MRL meeting in this room in a bit under 2 hours

<superviber:sk.community> Hi all

<superviber:sk.community> Does anyone have any online jobs? I need income.

<jpk68:matrix.org> Wrong channel

<superviber:sk.community> Why not?

<sgp_> Zcash seems to be leaning more into dynamic fees: shieldedlabs.net/zcash-dynamic-fees-now

<jberman> Meeting time! monero-project/meta #1395

<neptunian:unredacted.org> Hooray.

<jberman> I'll be substituting for Rucknium today

<jberman> 1. Greetings

Hi

<neptunian:unredacted.org> Hello.

<sgp_> Hi

Hello

<vtnerd> hi

<jpk68:matrix.org> Hello

<syntheticbird> Hi

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

<redsh4de:matrix.org> hi

<gingeropolous> hi

<vtnerd> me: created lws 1.0 beta branch, and having otherwise been looking at serialization stuff in monerod/lws/lwsf

<neptunian:unredacted.org> I'm currently reading up on Raccoon, Raccoon-G, and other possible schemes for PQ-DSA (See MRL issue 159).

<jberman> me: beta stressnet v2 (we just released v2.0 which includes an auto rollback to address a stressnet-specific consensus issue in v1), FCMP++ integration audit handling some suggestions (the phase 1 audit went well, only informational suggestions found, and it seemed solidly deep. Final report I anticipate will be ready soon)

me: updated the Jamtis specs and drafted Monero-PSK

<gingeropolous> me: waiting on monerosim approval / issues, debating diving into running dns ban list experiments with it

Polyseed in the RPC wallet server

<jberman> 3. Post-Quantum Encryption ( monero-project/research-lab #151 ).

<jeffro256> Howdy

<ofrnxmr> > 2025-11-07 02:12:19.109 E wrong miner tx in block: , b.miner_tx.vin.size() != 1

<ofrnxmr> I think i found the cause of this, and possibly fixed it. Hard to reproduce though, so, yeah. Testing

I updated Jamtis specs to reflect what was discussed in the past few meetings. gist.github.com/tevador/639d083c994c1ef9401832c08e2b7832

Still a lot of work left, mainly in the appendix.

<diego:cypherstack.com> hi

<diego:cypherstack.com> CS has a thing

<jberman> tevador you mentioned Monday that the Jamtis-PQ solves the weaknesses in the filter-assist tier from Jamtis-Seraphis (specifically that the tier can't link enotes to known addresses and that it can't know if the same address received >1 enote) using an additional identify-received key. Tbc, that's an additional pub key in the address

<jberman> Was my rationale above accurate in explaining the stronger justification for an additional pubkey? "With the addition of PQ protection, seems the additional key has a more marginal impact on address sizes now"

Yes, the additional pubkey only adds ~40 characters, which is small compared to the address length of 400 characters

And the benefits are definitely worth it I think

<jberman> I would agree, that's a significant benefit for much lower cost than it originally was

But only relatively?

40 of 400 is 10%, 40 of 200 is 20%

Yes, the addition of PQ encryption shifted the scale

Ok. I think that's a valid point of view :)

Also a notable change in the specs is that the secondary view tag is constructed differently so a quantum attacker cannot always decide if an enote belongs to the wallet with a high probability. gist.github.com/tevador/639d083c994…08e2b7832#682-component-derivations

I think this is also worth the extra 3 bytes in each address.

<neptunian:unredacted.org> tevador to clarify regarding Appendix B (Interactive payments) in the Jamtis spec, I just want to know if atomic swaps will become a concern in the future.

neptunian: I don't follow. Why would an optional interactive payment protocol have any effect on atomic swaps?

<neptunian:unredacted.org> I just realised I misread it. Disregard what I said lol

<jberman> Arguably an atomic swap protocol may be more included to use the interactive protocol (since atomic swaps are interactive) and would benefit

<jberman> more inclined*

Yes, it might be beneficial for atomic swaps, not concerning.

<neptunian:unredacted.org> Good to know. Thanks.

The interactive protocol is there to enhance the overall PQ resistance, but it's not always possible to use it. Jamtis of course supports traditional non-interactive transactions.

I will add a clarification in Appendix B.

<jberman> PQ protection on view tags is a nice added bonus. That would bring Option A closer to Option B in terms sounds like

<jberman> From this table: monero-project/research-lab #151#issuecomment-4412416686

Yes, but it works only in some cases, notably for enotes that have been received to an address the QA doesn't know and the wallet must not have received more than 1 enote to the same address.

<jberman> Ha, that pesky caveat. Still a solid improvement that I agree is worth an additional 3 bytes in each address

<jberman> Anything further on PQ encryption today? Thank you tevador for your continued quality work on this

<neptunian:unredacted.org> Unless someone wants to talk on the question of Jamtis enforcement, I have nothing further to add.

I think that can be left for later.

<jberman> What's the question of Jamtis enforcement? As in enforcement at consensus?

<neptunian:unredacted.org> @jberman: Yes. gist.github.com/tevador/639d083c994…ment_id=6097146#gistcomment-6097146

Jamtis requires a special tx-extra field. The question is if nodes should enforce its presence.

Transactions lacking this field cannot be sending to a Jamtis address, which leaks information.

It's similar to the issue with the number of transaction public keys and subaddresses.

<jberman> I'd lean toward Option 3B

<jberman> Ideally we'd also enforce a consistent tx format for tx pubkeys and subaddresses at consensus

<neptunian:unredacted.org> @jberman: My thinking as well. I was in favour of 3A or 3B

CSIDH-1024 key validation takes ~10 ms of CPU time (for options 3A vs 3B)

<jberman> Part of the leaning toward deprecating tx extra was hardening protocol fields in tx format at consensus. I think enforcing consistent tx formats is a good goal

<neptunian:unredacted.org> tevador: Would it be possible for 3A to come first with 3B after as to minimise metadata leakage?

<jberman> Key validation = decompressing the point? So wallets will need to do it anyway? If it was the case that if consensus doing it could save the wallet some ops during scanning, I'd be more inclined for 3A

<jpk68:matrix.org> Is the key only put in tx_extra because that allows Jamtis to be a soft fork?

<jpk68:matrix.org> Rather than adding a separate field

jberman: key validation is similar to checking if an EC point is on the curve. It needs to be done before acting on the public key with a private key to avoid attacks.

<syntheticbird> epic matrix parsing

<neptunian:unredacted.org> @syntheticbird: lol

jpk68: exactly, Jamtis is supposed to be a soft fork

<vtnerd> an attacker could re-use the same key too right? meaning 3A is of marginal use compared to 3b

I was thinking it would be mostly to deter lazy wallet developers, but yeah, they can just ship a hardcoded valid CSIDH key...

Not sure if it's a real concern

<jberman> or they could chuck other things into the tx that pass validation. I agree it seems doing extra crypto ops validation on the key at consensus is probably of marginal benefit here

<vtnerd> I don’t think its an issue, other than de-compressing the point has somewhat low utility

<jberman> presumably wallets would break if the key is invalid too, so lazy wallet devs would be deterred by having a broken wallet

<neptunian:unredacted.org> I doubt it would manifest in a significant manner if it's only in lazy-dev-wallets.

<jberman> We can circle back to this convo in a future meeting, but Option 3B seems sanest to me fwiw

Agreed

<neptunian:unredacted.org> @jberman: That sounds good.

<jberman> 4. Monero-PSK ( gist.github.com/tevador/9169235b3c0c97e735f58a8c2ba92502 )

This would be another addressing protocol backward compatible with Carrot, but with different tradeoffs.

<jberman> Another advantage to Monero-PSK is PQ resistance no? Just using symmetric encryption rather than a key exchange protocol

Yes, but the PQ resistance is kind of moot because it requires the address to stay secret and Jamtis has the same property when addresses are kept secret.

<jberman> Ah, I see

<neptunian:unredacted.org> I am very concerned about the enote construction being stateful. That is already mentioned in the disadvantages section, though.

My claim is that we don't want *two* new address formats, so the choice should be either Jamtis or Monero-PSK, but not both.

<jberman> I think Monero-PSK is a neat idea to think on. The disadvantages are pretty significant and I have a hard time swallowing them, but an interesting thought experiment

<neptunian:unredacted.org> Having both would also make enforcement that much harder.

<jberman> I also agree we ideally wouldn't want two new address formats

Monero-PSK doesn't need any enforcement since it doesn require any extra on-chain data.

<jpk68:matrix.org> It would be unfortunate to make the protocol more fragmented. Sort of like what SSL did (someone made this analogy last week)

<neptunian:unredacted.org> Correct me if I'm wrong, however, since it would be Jamtis XOR Monero-PSK, adopting 3B would lead to possible metadata leakage with Monero-PSK addresses, no?

<sgp_> Fwiw I think instant syncing is going to be worth it in a non-negligible number of cases, but it I had to pick one or the other, it wouldn't be the option that forces an interactive payment

<jberman> The core benefit of Monero-PSK is that the daemon stores extra query-able data per tx that enables someone to efficiently query for their txs, no?

neptunian: no

<sgp_> "Alice needs to keep track of the number of generated addresses, "address lookahead" is needed in order to restore from a seed"

<sgp_> What happens if this is unknown? Is there a major disadvantage to picking a large/excessive lookahead number?

sgp_: Monero-PSK doesn't require interactive payments, only interactive address exchange.

sgp_: Yes, the same as current subaddress lookahead. Unexpectedly high value = wallet will not detect the payment

<sgp_> tevador: Sorry that's what I meant

<sgp_> tevador: I don't see this as a meaningful downside then

The "lookahead" issues are very similar to what we have now with subaddresses. However, Jamtis doesn't have those issues.

So it's a downside compared to Jamtis.

<hbs:matrix.org> the lookahead is not interactive in the sense PSK would be (needing coordination between both parties) so it varies quite significantly

<hbs:matrix.org> or you mean identifying the last index could be done by a lookahead mechanism

Yes, with Monero-PSK, the damage is much greater if you give the same address to 2 people.

<vtnerd> hmm. how to re-synchronize on recovery from seed?

<neptunian:unredacted.org> What would happen if Bob lost his local database and restores from his seed under Monero-PSK?

Blockchain lookahead only works if the address was used. If you give 100 addresses to 100 people who never pay you, you have to remember to always skip those addresses.

<vtnerd> correct, but then recovery means it PSK can never be re-used?

<vtnerd> as-in if you recover from seed in a PSK environment, you can only recover existing addresses but not give out new ones

When restoring a waller from a seed, the user would have to manually tell the wallet to skip 100 addresses that have been given out but not used.

<sgp_> Ideally there would be both formats :( the wallet UI would differentiate between "single use" addresses and "reusable" addresses. I think most people will have a better experience with single use addresses and no syncing. I'm sorry that this comment isn't particularly helpful, but I do appreciate the work that went into PSK in chasing better UX

Maybe now that the basic idea is "born" people will take it, run with it, and improve

<sgp_> Fwiw I'm not actually suggesting that both (in their current forms) should be used together, but they both have their merits

<jberman> Worth emphasizing: if you give out the same subaddress to 2 different people today, they can't infer which enotes on chain are yours. But with this scheme, if you do that, they can. It brings Monero closer to Bitcoin's privacy properties too

<neptunian:unredacted.org> rbrunner: I hope so, but that's why I agree with @jberman:monero.social's sentiment of it being an interesting thought experiment.

All enotes?

(two persons receiving the same address)

Only enotes sent to the reused address.

<jberman> the enotes received to that address*

Oh, that does not sound so drastic

Little trade-off, enjoy these benefits, but remember to not do A), B) and C)

It's slightly better than Bitcoin because it doesn't leak to external observers.

<jberman> Personally I think the filter-assist tier has an improved tradeoff profile of fast sync with better privacy properties

<sgp_> I consider that limitation to be acceptable. Unlike with Bitcoin there's no future graph analysis to cluster addresses

<jberman> (The filter-assist tier in Jamtis-PQ)

Yeah, filter-assist is almost like giving out your view key today, but without giving out the view key :)

<sgp_> If fast enough, then yeah it may be "good enough"

<neptunian:unredacted.org> I'm still anxious about Monero-PSK being stateful with the presented UX risks (i.e. manual skipping)

<hbs:matrix.org> Isn't it too complex for users and could lead to many errors where addresses would be reused?

Jamtis is more versatile. It can support static addresses and "almost" instant sync with filter assist.

Maybe dumb idea, but can't you just send something yourself to otherwise unused addresses, so no skips needed?

<neptunian:unredacted.org> rbrunner: I think that risks breaking sender privacy.

Ah, yes, you would need to have something like a secret with yourself ...

<sgp_> filter assist requires an always running server though

<jberman> fwiw I think Monero-PSK would be much more attractive if Jamtis-PQ still had those old privacy issues in the filter-assist tier from Jamtis-Seraphis. but because Jamtis-PQ doesn't, it's a more attractive set of tradeoffs to me

<jberman> @sgp_: this is true, and tbc, one that specifically has a key that a user provides to it

<jberman> to scan the chain with

<jeffro256> @sgp_: Or for you to temporarily do full scans

<sgp_> is the expectation that wallet providers run filter assist scanning for their users? or is the expectation that it is used in similar situations as LWS is today? or do we not know :)

<hbs:matrix.org> Relying on a wallet provider poses a lot of issues, centralization,possible censorship, leaks...

Filter-assist is a replcement for LWS.

and services like MyMonero

<hbs:matrix.org> not mentioning the burden on said provider who could be tempted to raise their existing fees or make user pay for their service.

<neptunian:unredacted.org> @hbs:matrix.org: Maybe the wallet provider could provide a default? Like how Cake has their own nodes to default to? I still agree with the issues, though.

<jeffro256> @hbs:matrix.org: As long as running a monero daemon remains relatively low cost, good luck charging for LWS services

MyMonero had users

<sgp_> like I said, if I had to pick one, it would be jamtis-pq

<syntheticbird> @sgp_: about the same. my heart is towards jamtis-pq

<sgp_> but instant sync without needing a server is a huge UX win for "most users"

<neptunian:unredacted.org> @sgp_: Ditto.

<hbs:matrix.org> @syntheticbird: +1

<redsh4de:matrix.org> @syntheticbird: +1

<vtnerd> tevador: it would just be integrated into LWS as an option … ?

<jberman> I had concern with more of the ecosystem moving toward filter assisted services with the old set of privacy issues, but I have less concern with it now considering Jamtis-PQ's improved privacy profile for it

<jberman> I could imagine both 1) more people running LWS for one (and it ending up a first class binary alongside monerod)

<jberman> and 2) more MyMonero-like wallet service providers offering it

vtnerd: yes, it should be an option (possibly the only option for Jamtis)

<jberman> the centralization / censorship risk is mitigated to a degree because wallets technically always sync via daemon too. wallets can include both a daemon to point to and LWS e.g.

<hbs:matrix.org> @jberman: Regulatory pressure may reduce the number of entities willing to provide such services more than it would increase it

<jberman> technically can always sync via daemon*

<jberman> There is a notable privacy risk with more centralized service providers too collecting txs (and doing timing analysis on users using the service to send txs)

<vtnerd> yeah I would have to look at the overhead of storage+transmission, some wallets may still want full filtering (seems like you think this should never happen)

<jberman> I'd argue a "better" model would be for wallets to point to distinct daemon and LWS (ideally controlled by separate entities). Use daemon + tor/i2p/some mixnet for construction / submitting txs, and LWS for scanning

<jpk68:matrix.org> @syntheticbird: +1

vtnerd: my concern is that "full filtering" will win due to being easier to implement and we'll lose the privacy benefits

<sgp_> I think this discussion can be deferred since it seems people are in favor of jamtis-pq even if no FilterAssist servers are widely used

<jberman> @hbs:matrix.org: Fwiw, MyMonero doesn't exist anymore and there is I think just 1 centralized LWS operator out there today? Edge wallet? Sky Wallet requires users to bring their own LWS ya?

<sgp_> two distinct use-cases for LWS. Partially trusted (like using their remote node) can use FilterAssist, while at home I can self host with ViewAll no prob

<jberman> Ok, moving on to next agenda item

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

<jberman> We launched v2.0, which solved a stressnet-specific consensus issue in beta stressnet v1, and also solved a few other issues identified during the stressnet

<jeffro256> Right now, the testnet difficulty is spiked but is coming down, so the fork date will probably end up hppening tomorrow

<jberman> v2 auto rolls back the chain in order to revert the consensus issue, and will fork from the current testnet in ~500 blocks

<jberman> We'll see how the relaunch goes and continue tackling issues identified

<jberman> Any further questions/comments on beta?

<jberman> 6. FCMP++ integration audit. ( seraphis-migration/monero #294 )

<jberman> The audit went well, only information issues identified. Currently working on remediations for the informationals, and still awaiting the final document

<jberman> There was one item from Phase 1B that they were not able to complete a comprehensive audit on within the time allotted (though they did look into it)

<jeffro256> Is it okay if you list which one that is?

<jberman> Specifically this item: "Verify the claim that no output or commitment detectable as a valid receive on the Monero blockchain today (or at any point in the past) would cause output_to_tuple to throw. This is critical because it means that an output that is detectable as a valid receive under existing/prior rules would not be spendable after FCMP++ goes into effect. "

Were my comments here included in the audit? seraphis-migration/monero #294#issuecomment-4086444878

<jberman> It's an important item. I think it's understandable that it wasn't completed within the timeframe. I do think they were rigorous in the items they did explore

<jberman> I had updated both those bullets to try to cover those comments a while back

<jberman> (prior to the audit)

It didn't include equivalence of the unbiased hash to point impls.

<jberman> > which may simply involve verifying that the C++ implementation is fully Elligator2-spec-compliant

<jberman> it included that part

You mean the audit included that? It isn't in the bullets that I can see, unless I am blind.

Wait I see it now!

<jberman> > Does the implementation match Elligator 2 as specified in the Elligator paper: eprint.iacr.org/2013/325.pdf ? We are aware the implementation does not match the IRTF specification.

<jberman> That was added after/from your coment

<jberman> and prior to the audit

<jberman> and the audit did include that

The remark about being off-spec implies it could not match with the rust version, hence my being anal about this. Do we even have any test vectors the rust version is checking?

<jberman> Will look closer post meeting (also pinging @kayabanerve:matrix.org ). One of the valid suggestion they made during the audit was also to add more test vectors with known answer tests for various items

Thanks. Does the fcmp C API expose any code paths that actually depend on the rust version of the Hp impls?

<jberman> That's a good q. I'm not sure, also can look into that

<jeffro256> Off the top of my head, I want to say that the FCMP membership verification and SA/L verification is independent of the hash-to-point function chosen

Yeah sal is independent.

<jberman> Further comments on integration audit? I'll get back to those q's, and continuing on remediation / awaiting final report

<diego:cypherstack.com> oh uh

<diego:cypherstack.com> are we on code audit?

<diego:cypherstack.com> I have the completed version from CS

<diego:cypherstack.com> mrelay.p2pool.observer/m/cypherstack.com/jQquPPViperLiEQRRqJSzixs.pdf (FCMP_Code_Implementation_Audit.pdf)

<jberman> Nice, thank you ! 🙏

<jberman> Will take a closer look

<luke:cypherstack.com> All feedback would be much appreciated! Also, there is a rather elegant proof about the unbiasedness of the hash to point scheme included.

<jberman> Will do in the coming days

<jberman> 7. CCS proposal: ProbeLab P2P Network Metrics Proposal. ( repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/667 )

<yiannisbot:matrix.org> Hi everyone myself and @dennis_tra:matrix.org are around.

<dennis_tra:matrix.org> Hi everyone

<yiannisbot:matrix.org> We've received feedback from the community during the last few MRL meetings and have revised the proposal.

<yiannisbot:matrix.org> Consensus seems to have been that Milestone 1 on general metrics and dashboards should be removed from the scope of the project and instead focus on Milestone 2. We've revised the proposal accordingly and expanded the scope of Milestone 2 with more details.

<freeman:cypherstack.com> @luke:cypherstack.com: When he thinks your proof is elegant 🥰💍🤩

<jberman> @ofrnxmr:monero.social @sgp_:monero.social @boog900:monero.social do you guys have further thoughts on the updated proposal? Apologies I haven't been following this item closely

<luke:cypherstack.com> Unironically, it might be one of the nicest proofs I have ever seen. All the pieces just smoothly fit together.

<boog900> > We will try to quantify how big of a role do spy nodes play. The Dandelion++ paper assumes that spy nodes do not play a role and therefore ignores them in the analysis

<boog900> I am not sure I understand that

<ofrnxmr> @jberman: It was just updated abt an hr ago

<boog900> The whole point of D++ is to minimize the spying ability of spy nodes

<yiannisbot:matrix.org> @boog900: Yup, at this stage and given we're not going to analyse the D++ specifics (e.g., message propagation), we're going to look at how spy nodes affect the network from a connectivity point of view as a first step.

<yiannisbot:matrix.org> This particular recommendation was originally from @rucknium:monero.social

<jberman> @ofrnxmr: Seems people could use more time to grok/weigh the updated proposal

<boog900> IMO I would want the proposal focused on investigating solutions, so I like the few points focused on that

<yiannisbot:matrix.org> @jberman: Sure, but also, I'd suggest to contribute to the issue so that we make faster progress ;-)

<boog900> I don't know if you saw, but I made an issue for proving connections: monero-project/research-lab #160

<boog900> tevador also gave a proposal in there too

<boog900> it would be good for those to be included in the analysis

<yiannisbot:matrix.org> @boog900:monero.social: I didn't see this - thanks for the pointer. Regarding solutions: we don't know which solution would work at this stage, so it's difficult to list it. If the community has clearer view, please share and we can focus our investigation accordingly. But it doesn't seem to be the case from what I gather the [... too long, see mrelay.p2pool.observer/e/iN7-oocLZ0ZheHRl ]

<yiannisbot:matrix.org> @boog900: Let me have a look at the details and will get back to this thread and/or add it to the proposal.

<sgp_> I also don't fully understand the comment here, but overall I think the changes are in the right direction > <@boog900> > We will try to quantify how big of a role do spy nodes play. The Dandelion++ paper assumes that spy nodes do not play a role and therefore ignores them in the analysis

<jberman> Thank you guys. Feel free to keep discussing. I'll close the meeting here

<boog900> @yiannisbot:matrix.org: We have had a few ideas: monero-project/research-lab #126 and that link I just sent.

<boog900> But if we knew what would work we wouldn't need to investigate

<boog900> The reason they are still here is we don't know how to get rid of them

<sgp_> Mandatory kyc to run a node, ez /s

<yiannisbot:matrix.org> @boog900: Exactly, that's what we also want to investigate. But we also don't have a solution off the shelf 😂

<boog900> That's fair, but then I don't think we need more research to tell us we have a problem

<yiannisbot:matrix.org> @boog900: But this way the problem will just remain, no?

<boog900> I mean we already know we have a problem

<yiannisbot:matrix.org> Sure, we don't plan to do a study to confirm there's a problem. We'd like to get closer to a solution, or ideally find a solution. If there's no research around it then it will just continue to be a problem.