<syntheticbird> Meeting in this room in a lot of time. Probably wasn't worth pointing it out but I wanted to do it still.

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

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

<rucknium> 1. Greetings

👋

<syntheticbird> Hi

<articmine> Hi

Hi

<vtnerd> Hi

<jberman> waves

<iamnew117:matrix.org> hello

Hello

<jpk68:matrix.org> Hello

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

Jamtis-PQ

<jberman> me: using the latest FCMP++ lib changes, preparing for beta

Implementing Polyseed in the Monero core software

<vtnerd> Me: testing lwsf /feed implementation via unit tests

<jeffro256> Howdy

<rucknium> 3. FCMP code integration audit overview (seraphis-migration/monero #294). CCS proposal (repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/663).

<jberman> 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

<jberman> 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

<jberman> 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

<rucknium> 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.

<jberman> while the FCMP++ Research Audit was focused on the more math-focused side of the FCMP++ protocol and lib by @kayabanerve:matrix.org

<jeffro256> @rucknium: IIRC QuarksLab reviewed the BP code, but I could be wrong

<sneedlewoods_xmr:matrix.org> @jberman: I think it received more positive feedback last community meeting

<jberman> @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

<jberman> perhaps moneromooo / selsta have a better answer

<jeffro256> TBF, the FCMP++ integration contains a significantly higher amount of business logic touching crypto, that if done incorrectly, can lead to inflation bugs

<rucknium> I thumbed-up the proposal now :)

FWIW, I have no objections to that CCS proposal.

<rucknium> @jeffro256: @jeffro256:monero.social: Maybe this info could be added to the proposal so the stakes are known.

I don't think we had an audit of mooo's integration PR

<rucknium> Thanks, selsta

<rucknium> More discussion on this item?

<jeffro256> 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 mrelay.p2pool.observer/e/zIGZ3fkKSFNGNG90 ]

<jeffro256> I can add a more accessible blurb to that CCS today

Yes, please do that, will be very valuable

<ofrnxmr> @rucknium: #monero-community:monero.social workgroup is deferring to MRL as to when and whether it is merged

<jberman> would be welcome, thank you @jeffro256:monero.social 🙏

<rucknium> 4. Increased FCMP++ membership proof size, marginally slower 1-input verification time (seraphis-migration/monero #317).

<jberman> 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: seraphis-migration/monero #317

<jberman> 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

<rucknium> Can we consider the mathematics of the new protocol (+33% tx size) to be fully reviewed?

<syntheticbird> 3 more months before FCMP++ HF

<syntheticbird> unless this can be done in parallel

<rucknium> 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.

<articmine> @rucknium: It has a small impact on scaling

I also support going ahead with the new sizes, perhaps adjusting the reference tx size if needed.

<jpk68:matrix.org> @syntheticbird: Until the fork, or until its date is announced?

<jberman> @rucknium: No, @kayabanerve:matrix.org has 2 follow-up questions posted here: github.com/cypherstack/generalized-bulletproofs-fix/issues , and has explicitly mentioned intent to do a round of deeper review

<syntheticbird> @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.

<articmine> ... and likely on fees

Do we have a checklist of items that need to be completed before tagging the HF version?

<jberman> Commit description here indicates @kayabanerve:matrix.org 's blockers on it: monero-oxide/monero-oxide cba7117

<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

<jberman> tevador: I'll update this checklist with tasks like "Complete all outstanding Research items", "Audit integration", "beta stressnet", etc.: seraphis-migration/monero #53

<jeffro256> I feel like a 33% increase in tx size will affect beta scaling ...

jberman: thanks, I missed that issue

<jberman> This was my initial take on scaling impact fwiw

<jberman> 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

<jberman> And faster increasing membership proof size as n inputs increases fits within the rationale for choosing weight to roughly follow byte size: seraphis-migration/monero #44#issuecomment-3423391977

<rucknium> @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

<articmine> We need to increase the transaction weights accordingly and also increase fees

<jberman> Tx weights roughly follow byte size, they are increased as a result of this change

<articmine> Which means a small fee increase

<articmine> The reference tx weight would need to increase which in turn means an initial fee increase

<jberman> is that the only change in mind?

<jberman> it's currently 10k bytes

<jberman> which is still larger than the new 2-in/2-out

<jberman> or sorry, new 2-in/2-out is 10,425 bytes

yes, the reference size might need to be increased slightly

<articmine> Vs ~8000 before

<articmine> Bytes

<jberman> Shall we make it 10.5k bytes to roughly match 2-in/2-out?

<articmine> I am thinking ~ 12500 bytes

<jberman> I'm ok with that

that's approx a +56% fee increase

<articmine> Correct

sounds reasonable

<rucknium> 5. Proposal for FCMP++ HF Activation Rule to Retroactively Ignore Future unlock_time (monero-project/research-lab #125).

<ofrnxmr> @articmine: In whole numbers, i assume thats like ~0.00012 xmr for a 2in/2out tx?

<jberman> hang on, before moving to this item, I think we should finish discussion on scaling / beta

<rucknium> @jberman:monero.social: Ok

I think the only constant in the code that needs to be changed is the reference tx size

<jberman> sounds good to you ArticMine ?

<articmine> Yes

<jeffro256> Okay then I will open the PR

<jberman> 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

<rucknium> That sounds good to me

<jeffro256> Should we simply add 33% as an empty byte buffer to the beta txs to mimic bandwidth loads?

<jeffro256> Or whatever the actual change would be

<jberman> 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

<rucknium> I misunderstood. The code for the new changes hasn't been written yet?

<jberman> @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

<jberman> the benchmarks I posted are using the changes kayaba implemented

<jberman> i.e. you understood correctly @rucknium:monero.social

<rucknium> Then the 33% empty byte buffer would be unnecessary?

<jberman> yes, that would be unnecessary

<jeffro256> Ah okay, so we can use the actual code (or something ostensibly similar to final production version) in the beta stressnet branch?

<jberman> yep

<jeffro256> If so, then I misunderstood, as I thought that the code wasn't done yet. Kayaba is just waiting for CS to sign off?

<jberman> no kayaba is just busy with other work at the moment

<jberman> I'm ok with moving forward with using the latest changes and launching beta

<jeffro256> Okay yeah, if it is complete (not necessarily sound) and will have similar performance characteristics, then I agree

<jberman> 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.

<jeffro256> SGTM

<rucknium> That would be great. Thank you.

<rucknium> More discussion on this item?

<jberman> nothing from me

<rucknium> 5. Proposal for FCMP++ HF Activation Rule to Retroactively Ignore Future unlock_time (monero-project/research-lab #125).

<jberman> Firstly, we should have been on top of the May 1, 2025 date and announced it more formally, I apologize for that

<jeffro256> 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

Is a getmonero.org blog post planned?

<jberman> 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)

<jeffro256> tevador: It should be

<jberman> And then yes, make a blog post and announce

There shouldn't be many nonzero unlock_times due to the relay rule

<jeffro256> @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

<rucknium> I can check the volume of those txs.

I also tried to find any discussion of this decision on Reddit, and failed. Found only discussions predating the decision.

<jeffro256> But because of the relay rule introduction, it also might not make much sense to reset the date

<jberman> 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

<rucknium> gist.github.com/Rucknium/48dd80d52c26ab461035e4da5b1e5230

<rucknium> > 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).

<rucknium> > 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: github.com/monero-project/monero/releases/tag/v0.18.3.4

<jbabb:cypherstack.com> is the intention to sunset unlock_times across the board entirely?

<rucknium> That's the older data

<rucknium> @jbabb:cypherstack.com: Yes. Having custom unlock time would make FCMP code a lot more complicated.

<jberman> @jbabb:cypherstack.com: The plan already in place is to not allow custom unlock_time at consensus at the fork

most of the unlock times in rucknium's gist are invalid anyways

<jeffro256> @rucknium: We have had multiple vulnerability fix releases since then, so hopefully those pools have updated in the last 1.5 years

<jberman> The plan we're discussing now is to retroactively not respect any custom unlock_time created after x date once the fork happens

<jberman> and x date would be a date before the fork

I think it's quite likely there have not been any unlock_time values with a future time at all since May 2025.

<jberman> 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

<jbabb:cypherstack.com> 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

<jbabb:cypherstack.com> better to solidify it at consensus imo rather than left to relay rules

<rucknium> @jbabb:cypherstack.com: Which protocols?

<jbabb:cypherstack.com> toys at this point, nothing production ready anyways

<jberman> 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

AFAIK no production atomic swaps have used it. It's quite useless actually.

Who can prepare a getmonero.org blog post?

<jberman> I or @jeffro256:monero.social can handle it

<jeffro256> 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

<rucknium> Maybe prep the blog post, extract the mainnet chain data (me), then finalize decision on the date next meeting?

<jberman> @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

rucknium: sounds good

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

<rucknium> ProbeLab has discussed their preliminary network scan results here previously.

<rucknium> @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.

<rucknium> 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.

<rucknium> This new deployment is more dangerous than previous ones because more of the nodes are scattered into their own subnets. The subnet deduplication countermeasure (monero-project/monero #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.

<rucknium> That data is here: 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.

<rucknium> Two issues I see with ProbeLab's proposal are 1) Mixing open source with a closed source backend and 2) Cost.

<rucknium> 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 (repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/217).

<jeffro256> > <@rucknium> Maybe prep the blog post, extract the mainnet chain data (me), then finalize decision on the date next meeting?

<jeffro256> 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: monero-project/monero #9522#issuecomment-2420662734

<rucknium> 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.

<rucknium> @jeffro256:monero.social: Yes

<jeffro256> Sorry, this is the real graph: monero-project/monero #9522#issuecomment-2420299652. The previous was FCMP++-tree-specific

<syntheticbird> 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

<rucknium> 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.

<rucknium> @syntheticbird:monero.social: Doing that would cut off any honest nodes using those services from the network

<rucknium> 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.

<rucknium> This proposal will be discussed next MRL meeting, too. ProbeLab people may be able to join the meeting then.

<rucknium> 7. CCS proposal: Grease Payment Channels (repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/651).

<rucknium> The proposers added info about possible KES (Key Exchange Service) options: repo.getmonero.org/monero-project/c…als/-/merge_requests/651#note_35871

<jberman> The protocol still seems to rely on trust and doesn't have a particularly viable path to removing that trust AFAICT

<rucknium> 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..."

<rucknium> I am not surprised they don't particularly like Intel SGX. It had a vulnerability that affected Secret: tee.fail

<jbabb:cypherstack.com> 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 mrelay.p2pool.observer/e/oJ6v3_kKM09SNVct ]

<rucknium> @jbabb:cypherstack.com: Can you give info on where you see practical use cases for it?

<jberman> 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

<jbabb:cypherstack.com> @rucknium:monero.social: not really, just in reducing tx fees for parties that already trust eachother and do regular business afaict atp

<jberman> XMR would probably be better spent on ideating protocols that don't rely on trust than implementing trusted solutions imo

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"

<jberman> Yea, I don't know exactly how to sugarcoat my thoughts here

<rucknium> Depositing credits to services is an old trust-based solution. It's used by a lot of service providers that accept cryptocurrency.

<jberman> Ya, ecash

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 ...

(Wildly simplified, of course.)

<rucknium> 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.

<jbabb:cypherstack.com> 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

<rucknium> More discussion on this? I want to hit post-quantum and possible Jamtis/Carrot modifications. Sorry the meeting is long.

Wouldn't a centralized KES also be an easy point for any law enforcement agency to bring down?

<jbabb:cypherstack.com> rbrunner: see samourai->ashigaru and paynym.is->paynym.rs; yes

<rucknium> Would an adversary that takes control of the KES have to cooperate with at least one of the parties to steal or lock funds?

<rucknium> One of the two parties in a channel

<rucknium> 8. Discussion: Post-quantum security and ethical considerations over elliptic curve cryptography (monero-project/research-lab #131). Safeguarding cryptocurrency by disclosing quantum vulnerabilities responsibly (research.google/blog/safeguarding-c…quantum-vulnerabilities-responsibly).

<jberman> @rucknium: According to this that is the case: repo.getmonero.org/monero-project/c…als/-/merge_requests/651#note_34850

<rucknium> Any discussion about post-quantum cryptography in this meeting? (Especially from tevador ?)

Here is the current draft of Jamtis-PQ: gist.github.com/tevador/639d083c994c1ef9401832c08e2b7832

The first comment lists 3 questions that need to be discussed before moving on.

I think the most important is the first question, which offers a trade off between privacy and post-quantum security.

<rucknium> > 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.

<rucknium> Does that mean that Carrot txs would have 132 bytes of random data in tx_extra?

Yes, that's the idea. When sending to a legacy address, the sender will insert a dummy PQ key.

I want to avoid the problem we had with subaddresses when inspecting tx_extra would leak information about recipients.

Regarding the unresolved issues, I'm currently leaning towards 1B and 3C.

<rucknium> Thank you for the write-up, tevador.

<rucknium> More discussion on this for now?

<rucknium> 9. More Jamtis features in Carrot (seraphis-migration/monero #310).

<jeffro256> Unless there's been an update since last time, I don't have anything else to add

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

Thanks.

<jeffro256> Thanks everyone

<ofrnxmr> Thanx

<jberman> 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

<jberman> 1B does seem more desirable though

Assuming a fast quantum computer (superconducting qubits), 2^61 is about 5000 years, 2^73 is millions of years.

Some details are in Appendix B including references to papers.

<jberman> 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)"

<jberman> 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)"

<jberman> csrc.nist.gov/projects/post-quantum…eria/security-(evaluation-criteria)

<jberman> 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

<jberman> seems it would be used for encryption only in this proposal, which seems to line up with expected comparable to 128 bit security

CSIDH-512 was initially thought to be in NIST category 1, but it was later shown to fall short of that category.

NIST category 1 is from 2^80 T-gates, so both CSIDH-512 and CSIDH-1024 fall short. But that doesn't mean they are insecure.

For comparison, Curve25519 is about 2^26 T-gates, so the difference is at least a factor of 2^35 if we ignore the much higher memory cost of CSIDH (~1 million qubits compared to ~1200 for Curve25519).

<jberman> ack

FCMP++ Integration Audit CCS has been moved to funding require ccs.getmonero.org/proposals/fcmp++-integration-audit.html

I agree with selsta that I do not think my integration PR was audited. It was certainly well reviewed though.