11:09:21 Meeting in this room in a lot of time. Probably wasn't worth pointing it out but I wanted to do it still. 15:02:42 MRL meeting in this room in two hours. 17:00:27 Meeting time! https://github.com/monero-project/meta/issues/1371 17:00:41 1. Greetings 17:00:44 👋 17:00:53 Hi 17:00:59 Hi 17:01:01 Hi 17:01:10 Hi 17:01:11 waves 17:01:43 hello 17:01:47 Hello 17:01:52 Hello 17:02:26 2. Updates. What is everyone working on? 17:02:48 Jamtis-PQ 17:03:28 me: using the latest FCMP++ lib changes, preparing for beta 17:03:56 Implementing Polyseed in the Monero core software 17:05:09 Me: testing lwsf /feed implementation via unit tests 17:06:07 Howdy 17:07:26 3. FCMP code integration audit overview (https://github.com/seraphis-migration/monero/issues/294). CCS proposal (https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/663). 17:08:58 We're waiting on a quote from likely just 1 more firm, and have a good slate of candidates we're discussing. I think we should have a proposed candidate for discussion by next week's meeting, and will respect the rule aiming to post the candidate at least 24 hours in advance of the meeting 17:09:49 The CCS proposal itself is sitting at 2 likes, which makes me slightly uneasy about support for it, perhaps others have thoughts on that here 17:11:01 I presume people may have the thought this is "yet another round of FCMP++ audits" on top of the FCMP++ Research audit. Perhaps I can make it clear this is auditing the code I've been writing for the past 2 years 17:11:42 Did previous hard forks have integration audits? I'm just curious. I think it's good if this is new with this hard fork, i.e. security precautions are ratcheting upward. 17:11:58 while the FCMP++ Research Audit was focused on the more math-focused side of the FCMP++ protocol and lib by @kayabanerve:matrix.org 17:12:38 @rucknium: IIRC QuarksLab reviewed the BP code, but I could be wrong 17:12:42 @jberman: I think it received more positive feedback last community meeting 17:13:09 @rucknium: not that I'm aware of. IIRC I believe the BP+ protocol was audited, but I'm not sure if moneromoo's actual PR integrating it into consensus was audited 17:13:38 perhaps moneromooo / selsta have a better answer 17:15:13 TBF, the FCMP++ integration contains a significantly higher amount of business logic touching crypto, that if done incorrectly, can lead to inflation bugs 17:15:15 I thumbed-up the proposal now :) 17:15:23 FWIW, I have no objections to that CCS proposal. 17:16:35 @jeffro256: @jeffro256:monero.social: Maybe this info could be added to the proposal so the stakes are known. 17:16:55 I don't think we had an audit of mooo's integration PR 17:18:06 Thanks, selsta 17:18:20 More discussion on this item? 17:18:39 To be extraordinarily reductive, the integration code for RingCT was A) changing the tx format, B) adding new data to the DB to store amount commitments, and C) adding a table for RingCT-specific outputs, D) switching which crypto functions were used for verification. The FCMP++ integration does all of that plus includes Rust [... too long, see https://mrelay.p2pool.observer/e/zIGZ3fkKSFNGNG90 ] 17:19:18 I can add a more accessible blurb to that CCS today 17:19:36 Yes, please do that, will be very valuable 17:19:41 @rucknium: #monero-community:monero.social workgroup is deferring to MRL as to when and whether it is merged 17:19:49 would be welcome, thank you @jeffro256:monero.social 🙏 17:21:09 4. Increased FCMP++ membership proof size, marginally slower 1-input verification time (https://github.com/seraphis-migration/monero/issues/317). 17:21:52 Re-sharing: the GBP fix identified and proposed by Cypher Stack has increased FCMP++ tx sizes ~33% and 1-in verification times ~10%. Results and further thoughts are here: https://github.com/seraphis-migration/monero/issues/317 17:23:09 I'm in favor of moving forward with these new figures, and penciling in continued follow-up research into the 2nd alternative route shared there 17:23:45 Can we consider the mathematics of the new protocol (+33% tx size) to be fully reviewed? 17:24:18 3 more months before FCMP++ HF 17:24:28 unless this can be done in parallel 17:24:35 I agree that it would be better to tolerate the larger tx size instead of opening the n'th can of worms by researching the 2nd alternative route, reviewing it, etc. 17:24:52 @rucknium: It has a small impact on scaling 17:24:53 I also support going ahead with the new sizes, perhaps adjusting the reference tx size if needed. 17:24:53 @syntheticbird: Until the fork, or until its date is announced? 17:25:14 @rucknium: No, @kayabanerve:matrix.org has 2 follow-up questions posted here: https://github.com/cypherstack/generalized-bulletproofs-fix/issues , and has explicitly mentioned intent to do a round of deeper review 17:25:23 @jpk68:matrix.org: im just saying if we ask for another review on the result of a review, we're gonna have to wait on it too. 17:25:29 ... and likely on fees 17:27:20 Do we have a checklist of items that need to be completed before tagging the HF version? 17:28:10 Commit description here indicates @kayabanerve:matrix.org 's blockers on it: https://github.com/monero-oxide/monero-oxide/commit/cba7117d2cb4a45444c54005604b2a943a8517f1 17:28:56 But @kayabanerve:matrix.org also stated that such blockers are not worth blocking beta on, which I can discuss in the FCMP++ beta discussion 17:30:11 tevador: I'll update this checklist with tasks like "Complete all outstanding Research items", "Audit integration", "beta stressnet", etc.: https://github.com/seraphis-migration/monero/issues/53 17:30:22 I feel like a 33% increase in tx size will affect beta scaling ... 17:30:49 jberman: thanks, I missed that issue 17:31:12 This was my initial take on scaling impact fwiw 17:31:21 The reference tx size was 10k, which still seems reasonably applicable, and the minimum penalty zone of 625kb was chosen with the size of large blocks in mind, rather than as a function of tx size IIRC. So I don't immediately see a reason to modify the fee structure 17:31:27 And faster increasing membership proof size as n inputs increases fits within the rationale for choosing weight to roughly follow byte size: https://github.com/seraphis-migration/monero/issues/44#issuecomment-3423391977 17:31:44 @jberman:monero.social: I replaced the beta streetnet agenda item with the item we are currently discussing. You can discuss beta stressnet now. > <@jberman> But @kayabanerve:matrix.org also stated that such blockers are not worth blocking beta on, which I can discuss in the FCMP++ beta discussion 17:32:16 We need to increase the transaction weights accordingly and also increase fees 17:32:46 Tx weights roughly follow byte size, they are increased as a result of this change 17:33:21 Which means a small fee increase 17:36:58 The reference tx weight would need to increase which in turn means an initial fee increase 17:37:44 is that the only change in mind? 17:37:55 it's currently 10k bytes 17:38:37 which is still larger than the new 2-in/2-out 17:38:54 or sorry, new 2-in/2-out is 10,425 bytes 17:39:46 yes, the reference size might need to be increased slightly 17:39:54 Vs ~8000 before 17:40:09 Bytes 17:41:21 Shall we make it 10.5k bytes to roughly match 2-in/2-out? 17:41:45 I am thinking ~ 12500 bytes 17:42:19 I'm ok with that 17:44:02 that's approx a +56% fee increase 17:44:26 Correct 17:45:14 sounds reasonable 17:45:52 5. Proposal for FCMP++ HF Activation Rule to Retroactively Ignore Future unlock_time (https://github.com/monero-project/research-lab/issues/125). 17:46:20 @articmine: In whole numbers, i assume thats like ~0.00012 xmr for a 2in/2out tx? 17:46:24 hang on, before moving to this item, I think we should finish discussion on scaling / beta 17:46:38 @jberman:monero.social: Ok 17:47:05 I think the only constant in the code that needs to be changed is the reference tx size 17:47:36 sounds good to you ArticMine ? 17:47:50 Yes 17:48:36 Okay then I will open the PR 17:50:29 on beta: I don't think @kayabanerve:matrix.org will have availability to continue on the GBP item until EOM. in discussions, my take is kayaba seems to hold a view any further changes are not expected to fundamentally alter tx size or verification/prove time, and feels we should move forward with beta 17:51:27 That sounds good to me 17:51:44 Should we simply add 33% as an empty byte buffer to the beta txs to mimic bandwidth loads? 17:52:02 Or whatever the actual change would be 17:52:47 I'm somewhat uneasy about it, in an ideal world I'd personally prefer to have this item completely settled before beta launch, but I think we're more likely to delay FCMP++ if we wait. The beta will be very useful no matter what, like the alpha was 17:53:30 I misunderstood. The code for the new changes hasn't been written yet? 17:53:38 @kayabanerve:matrix.org implemented the change already, it's just final task items remaining to sign off on it for production use essentially / slate it for auditing I believe 17:54:04 the benchmarks I posted are using the changes kayaba implemented 17:54:55 i.e. you understood correctly @rucknium:monero.social 17:54:56 Then the 33% empty byte buffer would be unnecessary? 17:55:09 yes, that would be unnecessary 17:55:20 Ah okay, so we can use the actual code (or something ostensibly similar to final production version) in the beta stressnet branch? 17:55:27 yep 17:55:46 If so, then I misunderstood, as I thought that the code wasn't done yet. Kayaba is just waiting for CS to sign off? 17:56:24 no kayaba is just busy with other work at the moment 17:57:42 I'm ok with moving forward with using the latest changes and launching beta 17:59:05 Okay yeah, if it is complete (not necessarily sound) and will have similar performance characteristics, then I agree 18:00:30 ok, then I say let's have all beta code ready for next week's meeting, so we're prepared to announce beta then with release binaries etc. 18:01:42 SGTM 18:01:44 That would be great. Thank you. 18:02:26 More discussion on this item? 18:02:43 nothing from me 18:03:34 5. Proposal for FCMP++ HF Activation Rule to Retroactively Ignore Future unlock_time (https://github.com/monero-project/research-lab/issues/125). 18:04:32 Firstly, we should have been on top of the May 1, 2025 date and announced it more formally, I apologize for that 18:05:59 Me too, I thought that it had gotten more highly disseminated, but I guess not. I vaguely remember some people debating it on Reddit, but I can't find any actual evidence of that discussion happening 18:06:06 Is a getmonero.org blog post planned? 18:06:13 Going forward, I think we should double check volume of unlock times since we last checked, and if all looks good, I think we should set a new date relatively soonish (e.g. 6/1/26) 18:06:24 tevador: It should be 18:06:28 And then yes, make a blog post and announce 18:07:10 There shouldn't be many nonzero unlock_times due to the relay rule 18:07:39 @jberman: If the long-term unlocked outputs is still in the double digits, or even below say 200, then I would be fine resetting the date 18:07:51 I can check the volume of those txs. 18:07:52 I also tried to find any discussion of this decision on Reddit, and failed. Found only discussions predating the decision. 18:07:59 But because of the relay rule introduction, it also might not make much sense to reset the date 18:08:52 ya the relay rule is an implied rule to an extent such that I don't think it would be a major violation of the social contract to keep the 5/1/25 date 18:09:21 https://gist.github.com/Rucknium/48dd80d52c26ab461035e4da5b1e5230 18:09:26 > Below are all non-coinbase transactions with nonzero unlock time confirmed on the Monero blockchain between September 1, 2024 (height 3227566) and October 13, 2024 (height 3258526). 18:09:35 > Version 0.18.3.4 of the Monero deamon, which prevents these transactions from entering the node's txpool, was released on August 22, 2024: https://github.com/monero-project/monero/releases/tag/v0.18.3.4 18:09:39 is the intention to sunset unlock_times across the board entirely? 18:09:44 That's the older data 18:10:11 @jbabb:cypherstack.com: Yes. Having custom unlock time would make FCMP code a lot more complicated. 18:10:30 @jbabb:cypherstack.com: The plan already in place is to not allow custom unlock_time at consensus at the fork 18:10:53 most of the unlock times in rucknium's gist are invalid anyways 18:11:09 @rucknium: We have had multiple vulnerability fix releases since then, so hopefully those pools have updated in the last 1.5 years 18:11:19 The plan we're discussing now is to retroactively not respect any custom unlock_time created after x date once the fork happens 18:11:30 and x date would be a date before the fork 18:12:51 I think it's quite likely there have not been any unlock_time values with a future time at all since May 2025. 18:13:56 I agree, and in which case, I think we'd be ok with setting a soon-ish future date to avoid nagging complaints about "officially" announcing a date in the past 18:14:11 my small comment is not in opposition but rather that I and a couple of others have been playing with atomic swap protocols which would benefit from unlock_time support but aren't blocked by its absence, just left to work with weaker refund path delay methods like VTSs 18:14:29 better to solidify it at consensus imo rather than left to relay rules 18:14:31 @jbabb:cypherstack.com: Which protocols? 18:15:12 toys at this point, nothing production ready anyways 18:15:47 if there is a complete protocol defined that would definitely benefit from the unlock_time that monero currently supports, it would be new/relevant info 18:15:57 AFAIK no production atomic swaps have used it. It's quite useless actually. 18:16:59 Who can prepare a getmonero.org blog post? 18:17:44 I or @jeffro256:monero.social can handle it 18:18:01 AFAIK the most useful time locks are ones which are specified in a signed input and conditional on some other condition like revealing a hash preimage. Monero's time locks are not that 18:19:09 Maybe prep the blog post, extract the mainnet chain data (me), then finalize decision on the date next meeting? 18:19:49 @jeffro256: right, so that one output can be spent before time x, and another after time x. DLSAG introduced that concept. no one has shown how to use monero's unlock_time to achieve that 18:20:29 rucknium: sounds good 18:21:45 6. CCS proposal: ProbeLab P2P Network Metrics Proposal (https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/667). 18:21:53 ProbeLab has discussed their preliminary network scan results here previously. 18:22:30 @dennis_tra:matrix.org and @yiannisbot:matrix.org aren't able to attend the meeting today, but they can respond to comments and questions later. 18:22:42 The mainnet spy node situation has gotten worse. On March 31, about 900 new spy nodes appeared. That raised the percentage of nodes that are spy nodes from 47% to 55%. It looks like they appeared in a few Amazon-owned ASNs. 18:22:55 This new deployment is more dangerous than previous ones because more of the nodes are scattered into their own subnets. The subnet deduplication countermeasure (https://github.com/monero-project/monero/pull/9939) is less effective against the new deployment. Maybe the adversary chose the deployment configuration to defeat the countermeasure or it may have been happenstance. 18:23:31 That data is here: https://xmrnetscan.redteam.cash/ . Creating the ASN static treemap plot is triggering an error condition, so it's missing. The IP subnet treemap is available. You can click the interactive ASN treemap, but (warning) it may cause an error condition in your browser. 18:23:45 Two issues I see with ProbeLab's proposal are 1) Mixing open source with a closed source backend and 2) Cost. 18:25:02 The first part of their proposal is to publish an open source extension that hooks into their closed-source "generic" network analyzer that they have used with a lot of other chains. There is some precedent for funding data dashboards with closed-source backends, e.g. TxStreet (https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/217). 18:25:07 > <@rucknium> Maybe prep the blog post, extract the mainnet chain data (me), then finalize decision on the date next meeting? 18:25:07 Rucknium: can you extract the running total of custom-locktime, currently unlocked at each block over time, please? That would be the most useful graph as it pertains to the wallet DoS vector. I made one here: https://github.com/monero-project/monero/pull/9522#issuecomment-2420662734 18:25:16 Maybe ProbeLab could make sure that their open source implementation dumps all useful data to a minimally-structured file, so the open source portion is still useable even if not hooked into their closed source product. 18:25:45 @jeffro256:monero.social: Yes 18:26:07 Sorry, this is the real graph: https://github.com/monero-project/monero/pull/9522#issuecomment-2420299652. The previous was FCMP++-tree-specific 18:27:13 Regarding new deployment, I don't think even Cake Wallet is hosting a monero node on AWS. Recommending on banning Azure, Google and Amazon cloud ASN wouldn't be inappropriate 18:27:21 I think the first milestone labor time and costs are reasonable. The second milestone is to collect data on unreachable nodes. I think the labor needed for that may be overestimated in the proposal. Perhaps ProbeLab can further break down the expected process for that milestone. 18:28:25 @syntheticbird:monero.social: Doing that would cut off any honest nodes using those services from the network 18:29:34 I also want an estimate of infrastructure costs alone so it is known what the continued cost of running the monitor would be. The current proposal includes 6 months of monitoring. 18:30:09 This proposal will be discussed next MRL meeting, too. ProbeLab people may be able to join the meeting then. 18:30:32 7. CCS proposal: Grease Payment Channels (https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/651). 18:31:10 The proposers added info about possible KES (Key Exchange Service) options: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/651#note_35871 18:32:08 The protocol still seems to rely on trust and doesn't have a particularly viable path to removing that trust AFAICT 18:32:55 Step 2 says "Deploy the first production KES on the Secret network. We don't particularly like Intel SGX, but it's a relatively cheap deployment, is better than a purely centralized KES, and bridges the gap until..." 18:33:32 I am not surprised they don't particularly like Intel SGX. It had a vulnerability that affected Secret: https://tee.fail/ 18:34:38 sorry to speak on something again without linking code again, but I'll report similarly re: unlock_times that I and a small group have been playing with grease (not in the context of swaps yet, tho) and it was remarkably easy to set up and use on stagenet. I don't have any useful input re: a KES but I can report that the grea [... too long, see https://mrelay.p2pool.observer/e/oJ6v3_kKM09SNVct ] 18:35:24 @jbabb:cypherstack.com: Can you give info on where you see practical use cases for it? 18:36:36 I'd personally rather see a return to the drawing board here and a fleshed out protocol that does not rely on trust at any step 18:37:25 @rucknium:monero.social: not really, just in reducing tx fees for parties that already trust eachother and do regular business afaict atp 18:37:28 XMR would probably be better spent on ideating protocols that don't rely on trust than implementing trusted solutions imo 18:38:16 I tend to agree regarding trust, although it must of course be quite brutal for the authors of Grease if we ask them to "go back to the drawing board" 18:38:53 Yea, I don't know exactly how to sugarcoat my thoughts here 18:39:14 Depositing credits to services is an old trust-based solution. It's used by a lot of service providers that accept cryptocurrency. 18:40:04 Ya, ecash 18:40:05 Yes, unfortunately you don't need complicated payment channels if regarding trust we could just ask somebody we trust to run a simple online database with balances ... 18:40:49 (Wildly simplified, of course.) 18:41:39 The issue with depositing credits is that most (or all) of those services don't offer refunds from the deposit wallets. If they did, it would be like a cryptocurrency options contract. But payment channels would avoid that AFAIK. 18:41:41 I hedge my statements as in "for parties that already trust eachother" due to not having had enough time to look into the conditions around closing a channel uncooperatively. I report we used it and it worked, nothing more 18:42:41 More discussion on this? I want to hit post-quantum and possible Jamtis/Carrot modifications. Sorry the meeting is long. 18:42:49 Wouldn't a centralized KES also be an easy point for any law enforcement agency to bring down? 18:43:25 rbrunner: see samourai->ashigaru and paynym.is->paynym.rs; yes 18:46:22 Would an adversary that takes control of the KES have to cooperate with at least one of the parties to steal or lock funds? 18:46:35 One of the two parties in a channel 18:47:30 8. Discussion: Post-quantum security and ethical considerations over elliptic curve cryptography (https://github.com/monero-project/research-lab/issues/131). Safeguarding cryptocurrency by disclosing quantum vulnerabilities responsibly (https://research.google/blog/safeguarding-cryptocurrency-by-disclosing-quantum-vulnerabilities-responsibly/). 18:47:45 @rucknium: According to this that is the case: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/651#note_34850 18:50:24 Any discussion about post-quantum cryptography in this meeting? (Especially from tevador ?) 18:50:30 Here is the current draft of Jamtis-PQ: https://gist.github.com/tevador/639d083c994c1ef9401832c08e2b7832 18:50:56 The first comment lists 3 questions that need to be discussed before moving on. 18:51:59 I think the most important is the first question, which offers a trade off between privacy and post-quantum security. 18:52:06 > Jamtis is backward compatible with the Carrot transaction protocol, requiring only 132 additional bytes per transaction in tx-extra. Jamtis addresses can coexist with CryptoNote addresses and the resulting transactions are indistinguishable in the blockchain. 18:52:31 Does that mean that Carrot txs would have 132 bytes of random data in tx_extra? 18:52:59 Yes, that's the idea. When sending to a legacy address, the sender will insert a dummy PQ key. 18:53:39 I want to avoid the problem we had with subaddresses when inspecting tx_extra would leak information about recipients. 18:54:52 Regarding the unresolved issues, I'm currently leaning towards 1B and 3C. 18:55:39 Thank you for the write-up, tevador. 18:55:47 More discussion on this for now? 18:57:17 9. More Jamtis features in Carrot (https://github.com/seraphis-migration/monero/issues/310). 18:57:58 Unless there's been an update since last time, I don't have anything else to add 19:00:23 We can end the meeting here. Thanks everyone. 19:00:45 Thanks. 19:02:11 Thanks everyone 19:02:38 Thanx 19:04:10 tevador: I think it would be helpful to rationalize what impact a change from 2^73 to 2^61 T-gates actually means in practice and/or compare to recommendations / standards out there 19:04:45 1B does seem more desirable though 19:14:22 Assuming a fast quantum computer (superconducting qubits), 2^61 is about 5000 years, 2^73 is millions of years. 19:16:00 Some details are in Appendix B including references to papers. 19:27:17 According to ref paper 25, CSIDH-512 is in NIST's PQ security category 1, which is "Any attack that breaks the relevant security definition must require computational resources comparable to or greater than those required for key search on a block cipher with a 128-bit key (e.g. AES128)" 19:27:19 And then security category 2 is: "Any attack that breaks the relevant security definition must require computational resources comparable to or greater than those required for collision search on a 256-bit hash function (e.g. SHA256/ SHA3-256)" 19:27:38 https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization/evaluation-criteria/security-(evaluation-criteria) 19:30:14 so based on that rec, "level 1" security sounds ok for encryption, but not collision resistance to have something comparable to 128 bit security? I'm not entirely sure how to interpret that 19:34:03 seems it would be used for encryption only in this proposal, which seems to line up with expected comparable to 128 bit security 19:37:41