15:09:39 MRL meeting in this room in a bit under 2 hours 16:05:04 Hi all 16:05:06 Does anyone have any online jobs? I need income. 16:07:23 Wrong channel 16:09:16 Why not? 16:58:16 Zcash seems to be leaning more into dynamic fees: https://shieldedlabs.net/zcash-dynamic-fees-now/ 17:00:25 Meeting time! https://github.com/monero-project/meta/issues/1395 17:00:35 Hooray. 17:00:45 I'll be substituting for Rucknium today 17:00:48 1. Greetings 17:00:50 Hi 17:01:00 Hello. 17:01:00 Hi 17:01:06 Hello 17:01:12 hi 17:01:23 Hello 17:01:51 Hi 17:01:57 2. Updates. What is everyone working on? 17:01:59 hi 17:02:29 hi 17:02:49 me: created lws 1.0 beta branch, and having otherwise been looking at serialization stuff in monerod/lws/lwsf 17:03:35 I'm currently reading up on Raccoon, Raccoon-G, and other possible schemes for PQ-DSA (See MRL issue 159). 17:03:44 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) 17:03:48 me: updated the Jamtis specs and drafted Monero-PSK 17:03:59 me: waiting on monerosim approval / issues, debating diving into running dns ban list experiments with it 17:04:33 Polyseed in the RPC wallet server 17:05:09 3. Post-Quantum Encryption ( https://github.com/monero-project/research-lab/issues/151 ). 17:05:20 Howdy 17:06:05 > 2025-11-07 02:12:19.109 E wrong miner tx in block: , b.miner_tx.vin.size() != 1 17:06:05 I think i found the cause of this, and possibly fixed it. Hard to reproduce though, so, yeah. Testing 17:06:45 I updated Jamtis specs to reflect what was discussed in the past few meetings. https://gist.github.com/tevador/639d083c994c1ef9401832c08e2b7832 17:07:13 Still a lot of work left, mainly in the appendix. 17:07:36 hi 17:07:38 CS has a thing 17:09:18 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 17:10:08 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" 17:11:08 Yes, the additional pubkey only adds ~40 characters, which is small compared to the address length of 400 characters 17:11:21 And the benefits are definitely worth it I think 17:12:06 I would agree, that's a significant benefit for much lower cost than it originally was 17:12:29 But only relatively? 17:12:50 40 of 400 is 10%, 40 of 200 is 20% 17:13:03 Yes, the addition of PQ encryption shifted the scale 17:13:38 Ok. I think that's a valid point of view :) 17:13:53 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. https://gist.github.com/tevador/639d083c994c1ef9401832c08e2b7832#682-component-derivations 17:14:22 I think this is also worth the extra 3 bytes in each address. 17:14:25 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. 17:15:11 neptunian: I don't follow. Why would an optional interactive payment protocol have any effect on atomic swaps? 17:16:12 I just realised I misread it. Disregard what I said lol 17:17:22 Arguably an atomic swap protocol may be more included to use the interactive protocol (since atomic swaps are interactive) and would benefit 17:17:31 more inclined* 17:18:05 Yes, it might be beneficial for atomic swaps, not concerning. 17:18:27 Good to know. Thanks. 17:18:39 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. 17:19:27 I will add a clarification in Appendix B. 17:20:22 PQ protection on view tags is a nice added bonus. That would bring Option A closer to Option B in terms sounds like 17:20:38 From this table: https://github.com/monero-project/research-lab/issues/151#issuecomment-4412416686 17:22:03 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. 17:23:04 Ha, that pesky caveat. Still a solid improvement that I agree is worth an additional 3 bytes in each address 17:24:22 Anything further on PQ encryption today? Thank you tevador for your continued quality work on this 17:25:35 Unless someone wants to talk on the question of Jamtis enforcement, I have nothing further to add. 17:25:57 I think that can be left for later. 17:26:25 What's the question of Jamtis enforcement? As in enforcement at consensus? 17:27:14 @jberman: Yes. https://gist.github.com/tevador/639d083c994c1ef9401832c08e2b7832?permalink_comment_id=6097146#gistcomment-6097146 17:27:19 Jamtis requires a special tx-extra field. The question is if nodes should enforce its presence. 17:27:52 Transactions lacking this field cannot be sending to a Jamtis address, which leaks information. 17:28:24 It's similar to the issue with the number of transaction public keys and subaddresses. 17:28:32 I'd lean toward Option 3B 17:29:23 Ideally we'd also enforce a consistent tx format for tx pubkeys and subaddresses at consensus 17:29:29 @jberman: My thinking as well. I was in favour of 3A or 3B 17:30:37 CSIDH-1024 key validation takes ~10 ms of CPU time (for options 3A vs 3B) 17:30:54 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 17:31:40 tevador: Would it be possible for 3A to come first with 3B after as to minimise metadata leakage? 17:31:54 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 17:32:05 Is the key only put in tx_extra because that allows Jamtis to be a soft fork? 17:32:33 Rather than adding a separate field 17:33:29 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. 17:33:43 epic matrix parsing 17:34:03 @syntheticbird: lol 17:34:04 jpk68: exactly, Jamtis is supposed to be a soft fork 17:34:15 an attacker could re-use the same key too right? meaning 3A is of marginal use compared to 3b 17:36:00 I was thinking it would be mostly to deter lazy wallet developers, but yeah, they can just ship a hardcoded valid CSIDH key... 17:36:17 Not sure if it's a real concern 17:36:50 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 17:37:14 I don’t think its an issue, other than de-compressing the point has somewhat low utility 17:37:57 presumably wallets would break if the key is invalid too, so lazy wallet devs would be deterred by having a broken wallet 17:39:52 I doubt it would manifest in a significant manner if it's only in lazy-dev-wallets. 17:40:32 We can circle back to this convo in a future meeting, but Option 3B seems sanest to me fwiw 17:40:41 Agreed 17:40:57 @jberman: That sounds good. 17:41:06 4. Monero-PSK ( https://gist.github.com/tevador/9169235b3c0c97e735f58a8c2ba92502 ) 17:42:49 This would be another addressing protocol backward compatible with Carrot, but with different tradeoffs. 17:43:21 Another advantage to Monero-PSK is PQ resistance no? Just using symmetric encryption rather than a key exchange protocol 17:43:56 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. 17:44:27 Ah, I see 17:45:05 I am very concerned about the enote construction being stateful. That is already mentioned in the disadvantages section, though. 17:45:11 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. 17:45:35 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 17:45:48 Having both would also make enforcement that much harder. 17:46:13 I also agree we ideally wouldn't want two new address formats 17:46:47 Monero-PSK doesn't need any enforcement since it doesn require any extra on-chain data. 17:46:57 It would be unfortunate to make the protocol more fragmented. Sort of like what SSL did (someone made this analogy last week) 17:47:52 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? 17:48:16 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 17:48:25 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? 17:49:05 neptunian: no 17:49:25 "Alice needs to keep track of the number of generated addresses, "address lookahead" is needed in order to restore from a seed" 17:49:26 What happens if this is unknown? Is there a major disadvantage to picking a large/excessive lookahead number? 17:49:44 sgp_: Monero-PSK doesn't require interactive payments, only interactive address exchange. 17:50:30 sgp_: Yes, the same as current subaddress lookahead. Unexpectedly high value = wallet will not detect the payment 17:50:30 tevador: Sorry that's what I meant 17:51:11 tevador: I don't see this as a meaningful downside then 17:51:49 The "lookahead" issues are very similar to what we have now with subaddresses. However, Jamtis doesn't have those issues. 17:52:15 So it's a downside compared to Jamtis. 17:52:49 the lookahead is not interactive in the sense PSK would be (needing coordination between both parties) so it varies quite significantly 17:54:09 or you mean identifying the last index could be done by a lookahead mechanism 17:54:09 Yes, with Monero-PSK, the damage is much greater if you give the same address to 2 people. 17:55:07 hmm. how to re-synchronize on recovery from seed? 17:55:14 What would happen if Bob lost his local database and restores from his seed under Monero-PSK? 17:55:26 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. 17:55:59 correct, but then recovery means it PSK can never be re-used? 17:56:32 as-in if you recover from seed in a PSK environment, you can only recover existing addresses but not give out new ones 17:56:40 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. 17:57:11 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 17:58:19 Maybe now that the basic idea is "born" people will take it, run with it, and improve 17:58:42 Fwiw I'm not actually suggesting that both (in their current forms) should be used together, but they both have their merits 17:58:51 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 17:59:10 rbrunner: I hope so, but that's why I agree with @jberman:monero.social's sentiment of it being an interesting thought experiment. 17:59:12 All enotes? 17:59:29 (two persons receiving the same address) 17:59:30 Only enotes sent to the reused address. 17:59:35 the enotes received to that address* 17:59:50 Oh, that does not sound so drastic 18:00:25 Little trade-off, enjoy these benefits, but remember to not do A), B) and C) 18:00:25 It's slightly better than Bitcoin because it doesn't leak to external observers. 18:00:50 Personally I think the filter-assist tier has an improved tradeoff profile of fast sync with better privacy properties 18:01:08 I consider that limitation to be acceptable. Unlike with Bitcoin there's no future graph analysis to cluster addresses 18:01:25 (The filter-assist tier in Jamtis-PQ) 18:01:33 Yeah, filter-assist is almost like giving out your view key today, but without giving out the view key :) 18:02:10 If fast enough, then yeah it may be "good enough" 18:03:01 I'm still anxious about Monero-PSK being stateful with the presented UX risks (i.e. manual skipping) 18:03:11 Isn't it too complex for users and could lead to many errors where addresses would be reused? 18:03:23 Jamtis is more versatile. It can support static addresses and "almost" instant sync with filter assist. 18:03:39 Maybe dumb idea, but can't you just send something yourself to otherwise unused addresses, so no skips needed? 18:05:24 rbrunner: I think that risks breaking sender privacy. 18:06:01 Ah, yes, you would need to have something like a secret with yourself ... 18:06:11 filter assist requires an always running server though 18:06:41 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 18:07:37 @sgp_: this is true, and tbc, one that specifically has a key that a user provides to it 18:07:46 to scan the chain with 18:08:10 @sgp_: Or for you to temporarily do full scans 18:08:35 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 :) 18:09:55 Relying on a wallet provider poses a lot of issues, centralization,possible censorship, leaks... 18:10:09 Filter-assist is a replcement for LWS. 18:10:26 and services like MyMonero 18:11:24 not mentioning the burden on said provider who could be tempted to raise their existing fees or make user pay for their service. 18:12:06 @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. 18:12:14 @hbs:matrix.org: As long as running a monero daemon remains relatively low cost, good luck charging for LWS services 18:14:41 MyMonero had users 18:14:52 like I said, if I had to pick one, it would be jamtis-pq 18:15:18 @sgp_: about the same. my heart is towards jamtis-pq 18:15:20 but instant sync without needing a server is a huge UX win for "most users" 18:15:38 @sgp_: Ditto. 18:15:52 @syntheticbird: +1 18:16:17 @syntheticbird: +1 18:17:11 tevador: it would just be integrated into LWS as an option … ? 18:17:42 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 18:17:51 I could imagine both 1) more people running LWS for one (and it ending up a first class binary alongside monerod) 18:18:13 and 2) more MyMonero-like wallet service providers offering it 18:19:08 vtnerd: yes, it should be an option (possibly the only option for Jamtis) 18:19:20 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. 18:19:30 @jberman: Regulatory pressure may reduce the number of entities willing to provide such services more than it would increase it 18:19:31 technically can always sync via daemon* 18:20:26 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) 18:20:58 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) 18:22:04 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 18:22:32 @syntheticbird: +1 18:23:45 vtnerd: my concern is that "full filtering" will win due to being easier to implement and we'll lose the privacy benefits 18:24:08 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 18:24:23 @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? 18:25:07 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 18:28:47 Ok, moving on to next agenda item 18:29:13 5. FCMP beta stressnet. ( https://github.com/seraphis-migration/monero/releases/ ) 18:29:49 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 18:30:53 Right now, the testnet difficulty is spiked but is coming down, so the fork date will probably end up hppening tomorrow 18:31:00 v2 auto rolls back the chain in order to revert the consensus issue, and will fork from the current testnet in ~500 blocks 18:32:25 We'll see how the relaunch goes and continue tackling issues identified 18:33:27 Any further questions/comments on beta? 18:34:08 6. FCMP++ integration audit. ( https://github.com/seraphis-migration/monero/issues/294 ) 18:35:01 The audit went well, only information issues identified. Currently working on remediations for the informationals, and still awaiting the final document 18:35:59 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) 18:36:22 Is it okay if you list which one that is? 18:36:25 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. " 18:37:28 Were my comments here included in the audit? https://github.com/seraphis-migration/monero/issues/294#issuecomment-4086444878 18:37:56 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 18:38:37 I had updated both those bullets to try to cover those comments a while back 18:39:55 (prior to the audit) 18:40:11 It didn't include equivalence of the unbiased hash to point impls. 18:41:19 > which may simply involve verifying that the C++ implementation is fully Elligator2-spec-compliant 18:41:19 it included that part 18:42:31 You mean the audit included that? It isn't in the bullets that I can see, unless I am blind. 18:42:49 Wait I see it now! 18:42:55 > Does the implementation match Elligator 2 as specified in the Elligator paper: https://eprint.iacr.org/2013/325.pdf ? We are aware the implementation does not match the IRTF specification. 18:43:05 That was added after/from your coment 18:43:23 and prior to the audit 18:43:52 and the audit did include that 18:44:50 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? 18:46:20 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 18:47:33 Thanks. Does the fcmp C API expose any code paths that actually depend on the rust version of the Hp impls? 18:48:49 That's a good q. I'm not sure, also can look into that 18:49:43 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 18:50:12 Yeah sal is independent. 18:52:20 Further comments on integration audit? I'll get back to those q's, and continuing on remediation / awaiting final report 18:53:02 oh uh 18:53:05 are we on code audit? 18:53:08 I have the completed version from CS 18:53:42 https://mrelay.p2pool.observer/m/cypherstack.com/jQquPPViperLiEQRRqJSzixs.pdf (FCMP_Code_Implementation_Audit.pdf) 18:55:01 Nice, thank you ! 🙏 18:56:19 Will take a closer look 18:57:08 All feedback would be much appreciated! Also, there is a rather elegant proof about the unbiasedness of the hash to point scheme included. 18:58:07 Will do in the coming days 18:58:40 7. CCS proposal: ProbeLab P2P Network Metrics Proposal. ( https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/667 ) 18:59:18 Hi everyone myself and @dennis_tra:matrix.org are around. 19:00:24 Hi everyone 19:00:42 We've received feedback from the community during the last few MRL meetings and have revised the proposal. 19:01:28 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. 19:04:07 @luke:cypherstack.com: When he thinks your proof is elegant 🥰💍🤩 19:04:59 @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 19:05:08 Unironically, it might be one of the nicest proofs I have ever seen. All the pieces just smoothly fit together. 19:06:11 > 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 19:06:25 I am not sure I understand that 19:07:26 @jberman: It was just updated abt an hr ago 19:07:35 The whole point of D++ is to minimize the spying ability of spy nodes 19:08:50