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

<jberman> Unfortunately won't be 100% available for today's meeting, my update: continuing upstream FCMP++ integration PR's (the next PR was approved today) and squashing the rare stressnet wallet double spend errors (with @rucknium's help, who's running the latest set of fixes for the error / observed issues while debugging)

<jberman> On FCMP++ research tasks: we're looking to solicit quotes on a secondary audit of the circuit and gadget impl in the Rust FCMP++ lib and possibly more code as well, next step is drafting a proposal and reaching out to firms

<jberman> No additional material change to report from last week on other FCMP++ items from my end beyond above

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

<rucknium> 1. Greetings

Hi

<vtnerd> Hi

Hello

<articmine> Hi

<gingeropolous> hi

<ravfx:xmr.mx> Hi

<jeffro256> Howdy

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

<rucknium> me: Keeping stressnet stressed. Investigating bugs on stressnet.

<jeffro256> me: upstreaming / reviewing FCMP++/Carrot PRs, working on upstreaming bug fixes, implementing performance enhancements

me: time-locks / payment channels research

<gingeropolous> me: continuing to plug away on monerosim.

<vtnerd> Me: updated ssl stressnet pr, working on separate changes for ssl, and working on testing the p2p slowdown fix

<rucknium> 3. FCMP++ to-do list status. Programming tasks (seraphis-migration/monero #53). Reviews and audits (cryptpad.fr/sheet/#/2/sheet/view/yP…9VF6GYm9bXbPdCerdST3UDEEfBxcM/embed).

<rucknium> @jberman:monero.social gave an update right before the meeting:

Hi

<rucknium> > Unfortunately won't be 100% available for today's meeting, my update: continuing upstream FCMP++ integration PR's (the next PR was approved today) and squashing the rare stressnet wallet double spend errors (with @rucknium's help, who's running the latest set of fixes for the error / observed issues while debugging)

<rucknium> > On FCMP++ research tasks: we're looking to solicit quotes on a secondary audit of the circuit and gadget impl in the Rust FCMP++ lib and possibly more code as well, next step is drafting a proposal and reaching out to firms

me: payment channel security thoughts, making progress on multisig PR bugfixing

<jeffro256> So ToB is done with auditing phase 1. I don't know if j-berman has release the report publicly yet, I think that he wanted to do a pass on it before releasing it. Justin and I want to propose something to move the timeline up: remove phase 2 and 3 audits as a dependency for HF activation and binary release

Is hw wallet support mandatory for hf? Cause those are going to take a while.

<jeffro256> This doesn't mean that phase 2 and phase 3 audits wouldn't happen, but they would happen during the 6-month conventional/mandatory waiting period instead.

<jeffro256> No, at least not in the core repo. That's my opinion

Ok seems reasonable

<rucknium> Are there big technical challenges for HW wallet support, e.g. need to fit big objects on limited wallet RAM?

<jeffro256> The interfaces for HW devices on the non-HW side are done. Ledger is interested in making a CCS proposal to fund R&D on their side.

<jeffro256> @rucknium: I've talked to Kayaba a bit about this a while ago, and IIRC most parts of the SA/L signing can be "streamed" like they are now with CLSAGs. But it does complicate the signing as compared to simply having all the needed parts in-memory

<rucknium> "remove phase 2 and 3 audits as a dependency for HF activation" has confusing wording, IMHO.

<rucknium> "HF activation" means the date that the HF occurs, to me.

<jeffro256> By "HF activation", I meant "HF activation code merge", sorry

What happens if after that a critical problem surfaces that is not correctable within time, as a worst case scenario?

Or, can we "take back" the HF?

<rucknium> Here's a 2020 paper on HW wallets for Monero moneroresearch.info/119 Klinec, D., & Matyas, V. 2020, "Privacy-Friendly Monero Transaction Signing on a Hardware Wallet." Paper presented at ICT Systems Security and Privacy Protection.

(As a result of the on-going audits and reviews)

<jeffro256> rbrunner: Then the date gets pushed back 6 - N months, and people have to re-download binaries, where N is the "remaining time" between problem finding and previous HF activation date

<rucknium> Last HF, the announced date was moved at least once. I don't think any HF binaries were released and then withdrawn.

<jeffro256> rbrunner: We can "take back" the HF before it happens if users/companies stay up-to-date on releases

<rucknium> Anyone who downloads the binaries and neglects to update will be stuck on a bad fork.

Yes, as the possibly worst outcome, however unlikely

<jeffro256> Note that this is something that can happen anyways without audits, with such large update, and we should prepare for it regardless of auditing > <rbrunner> What happens if after that a critical problem surfaces that is not correctable within time, as a worst case scenario?

<rucknium> That's a similar outcome for people who just never update and a HF happens.

Right.

Seems to me the community of Monero users must be pretty "forking aware" now

<jeffro256> Phase 1 has gone well so far, and j-berman and I are somewhat confident that further finding by future audits would likely be mitigatable without causing a HF relative to the current state of the codebase, but it's absolutely possible.

<rucknium> If only we could get Linux package managers to also be forking aware

<rucknium> Could you describe phases 2 and 3 for us, @jeffro256:monero.social ?

<jeffro256> I'm extremely confident that phase 2 and phase 3 could complete within the 6-month convential waiting period. With these assumptions in mind, if we were to take a cautious optimism approach, we could merge the HF activation code before phase 2 and 3 audits complete, and shave months off the timline.

<jeffro256> Then we have a contingency plan in case the audit feedback requires a HF relevant to previous release

<rucknium> You say "the 6-month conventional waiting period" as if a 6-month waiting period has ever happened before :D

<jeffro256> Phases 2 and 3 are defined in this document: seraphis-migration/monero #294

There should generally be at least a 2-3 month code freeze before the HF, if possible.

<articmine> @rucknium: Sometimes I prefer they are not. I have had issues with Bitcoin and Linux package managers

<articmine> Never with Monero

<jeffro256> @tevador before HF activation, correct?

Yes, before the fork activation date.

<jeffro256> I think that that is certainly possible with the planned scopes of phase 2 and phase 3

<jeffro256> I'm working on a Gannt chart today because the timing and dependencies is getting hard to describe in words

<jeffro256> But I wanted to toss the idea of not blocking the first HF-activated release with phase 2 and phase 3 and get feedback on that

maybe "HF enabled release" or "HF ready release" ...

<slstmd> What was the exact definition of code freeze again?

<vtnerd> presumably there would be a branch at the very least

<rucknium> I went back and looked. The previous HF binary was released less than a month before the HF activation date: github.com/monero-project/monero/releases/tag/v0.18.0.0

<rucknium> I don't mean to say that it's a good precedent to follow. But "conventional" 6-month period is probably not the right word.

<jeffro256> lol fair

I think that was always "the idea" :)

<jeffro256> I was under the assumption that that was the target for previous HFs

That collided sooner or later with harsh cold reality

<vtnerd> we should’ve created the branch earlier than the 1 mo, and “froze” changes, but I don’t recall now

Code freeze means only bug fixes can be merged... but this rule has not always been followed.

I think it's still a good idea, and maybe *this* time, swapping almost the whole technology stack, we should pull that through

<rucknium> The 2022 HF delay was about multisig IIRC

And also with coin exploits popping up left and right ...

<rucknium> Do we need more time to discuss this, in this meeting? We can give people time to think. I hope the Trail of Bits piece can be published by next meeting, to provide more info.

<rucknium> Will there be a bounty on exploits against the the frozen code before the HF is activated?

Something that goes beyond the usually offered bounties would be a first, as far as I know

The Monero VRP states that "code in all branches; including the master branch and any release branch" are in scope

<rucknium> The VRP scope is wide. Maybe something special isn't necessary:

<rucknium> > This Vulnerability Response Process and subsequent bounty reward apply to the following:

<rucknium> > Code implementation as seen in the Monero Project GitHub repositories

<rucknium> > This includes code in all branches; including the master branch and any release branch

<rucknium> > Written research from the Monero Research Lab which dictates said code implementation

<rucknium> github.com/monero-project/meta/blob…r/VULNERABILITY_RESPONSE_PROCESS.md

<rucknium> But the potential reward isn't defined well.

<jeffro256> tevador: Maybe we should reduce the scope to *current release branches...

<jeffro256> I don't care if there's a vuln in v0.12.0.0 that got fixed 5 years ago

Yes, that scope seems overly broad

<rucknium> More on this agenda item?

<articmine> @jeffro256: Does this include anything that is pre release, or in testing for release etc.

<jeffro256> Does anyone currently object to not blocking the first release with phase 2 and phase 3 audits ?

<articmine> I understand the case of clearly obsolete code

fwiw it has never been an issue that someone argued about old release branches, but yes the wording should be updated

<jeffro256> If it's still in a PR, I think it shouldn't be in-scope for payouts. If it's pre-release, it will probably be in master. If it's a planned release, it will show up in a current release branch

Right now looks like a calculated risk worth taking to me.

<articmine> Fair enough, I just feel we should be careful and precise with the language.

<rucknium> @jeffro256: @jeffro256:monero.social: I would prefer to have the Trail of Bits piece published before making a call on that, but I won't "object" to it.

<jeffro256> That's fair, AFAIK it should be release before next MRL meeting

<jeffro256> *released

I agree with jeffro's proposal, as long as it's timed up so that all audits complete in time before the HF activates, with a small buffer

<articmine> selsta: I agree

"small buffer" should be at least 1 month

<rucknium> How soon, from today, is the expected HF code freeze, i.e. when would the 6-month clock start ticking?

<jeffro256> I'll also release my Gannt chart that I'm working, so we can have something more concrete than a collection of English chat logs to describe the timeline

Are we still branching v0.19 from master to test Guix and other changes in master?

<jeffro256> @rucknium: @tevador were you talking about a pre-first-HF-enabled release code freeze, or a pre-HF-activation code freeze?

tobtoht: I would say yes

Polyseed looks more or less ready

<jeffro256> We should do that ASAP IMO

I think the code freeze should generally precede the first release binaries

<jeffro256> Would that be a code freeze on consensus and node related code. For example, would multisig support / HW support / wallet knowledge proofs / other wallet-specific features be under this code freeze?

what's the status from stressnet for txrelay v2? ready for v0.19?

jeffo256: That's debatable, but generally you want to freeze all features before the release and focus on bug fixes

<vtnerd> yeah theres lws RPC changes for example that someone has to slog through (review)

<rucknium> selsta: I think we should get at least a week of more testing with the latest proposed fix of the double-spend issue, IMHO.

<jeffro256> @tevador If we freeze all features, that would push back the HF activation by several months for features that could be developed in parallel IMO

I have always disliked an overly strict code freeze

<jeffro256> I think that that kind of a freeze is simply too broad

<jeffro256> I would agree that p2p and consensus features should be frozen for some period of time before release

non-consensus changes can go into .1 anyways

<jeffro256> I think that basic sending / receiving / syncing wallet features should be frozen before the first release too

What is the expected timeline for the HF? Can RandomX v2 stil make it?

<jeffro256> But, respectfully, waiting for Trezor and Ledger to activate FCMP++ would be a mistake

<jeffro256> They don't move very fast

<rucknium> Isn't RandomX v2 already ready? sech1 ?

It's ready but not on the daemon side AFAIK?

That's also what I dimmly remember

there is a PR for it on daemon side, jeffro wrote it

RandomX v2 wallet related code is not developed yet but that doesn't require HF

<rucknium> Do any HW wallet manufacturers move fast? Could there at least be one sure to be ready for the HF?

<jeffro256> tevador: The expected timeline for the HF is what I'm trying to decide. RandomX v2 should be able to make it. I have this PR: monero-project/monero #10038. I need to add back the tx count and update the flow charts in the documentation, if we are to keep it

<jeffro256> But besides that, the consensus changes are done

<jeffro256> I plan to integrate DoS-resistant header-only sync after #10038 is merged, but that shouldn't be a blocker to the FCMP++ release

Thanks, I missed that PR

<jeffro256> @rucknium: I'm trying my damndest

<jeffro256> It would probably help to have a bunch of people bug them, IDK

<rucknium> @jeffro256:monero.social: I know you are. Thanks. But would users have an alternative in time for the HF?

realistically Ledger/Trezor will use LLMs to implement FCMP++ so I assume it won't take too long

<rucknium> oh no

<gingeropolous> i ponder if we should add things to make the codebase llm friendly

<rucknium> Maybe their revenue isn't great right now.

Many, many comments help. Something we are proudly famous for :)

<rucknium> rbrunner: Is that sarcasm from you?

Yes, of course ...

<rucknium> I think we should move the agenda along. Feel free to discuss this agenda item after the meeting.

Well, not the comment bit. They do support the work of LLMs greatly, from the little I know so far

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

I updated the proposal. Thanks to UkoeHB and kayabaNerve's comments, the new proposal includes completely private relative time-locks using ring signatures. I also posted a trustless payment channel protocol enabled by the proposal.

<rucknium> Thank you, tevador

Just wondering: If that proposal fully works out, may this result in the best Monero channel proposal so far?

<rucknium> > The approximate size of a 7-ring signature is 256 bytes, which is relatively small compared to the size of the FCMP++ proof.

<rucknium> Would the 256 bytes go into the tx_extra only of txs that need it?

No, this would be a hard forking change for all transactions

<jeffro256> I think that it need to be validated by consensus for it to be relied upon by a counterparty

<articmine> It is still a very small cost from a scaling perspective

<jeffro256> tevador: Technically, it could be a soft fork if v17 doesn't enforce unlock_time=0

The ring signature definitely has to be validated by consensus, otherwise transactions could spend enotes not present in the chain.

<rucknium> I'm not very enthusiastic about adding to blockchain size in every tx for payment channels.

<rucknium> Would this be useful to simplify atomic swaps?

on the flip side, it's all prunable data

Yes, it can also help for atomic swaps

<rucknium> Prunable data does help

<articmine> From a scaling perspective a payment channel that actually works can be very helpful

<articmine> The small extra transaction weight is well worth it

I think this is the only way to get payment channels without a trusted 3rd party.

<boog900> what % of txs would have to be done off chain for this to be worth it?

RandomX v2 is ready and released, XMRig version with v2 support is also released. Monero doesn't have v2 support yet.

<rucknium> @boog900:monero.social: About 5% to break even, right?

boog900: If the average fcmp++ tx size is 10K then about 2.5% unless I'm mistaken

My original proposal was using unlock_time = 1, which is an existing field, so 0 extra bytes, but it leaks.

<articmine> @boog900: 256/(tx size in bytes)

<boog900> do we know how much lightning does?

<boog900> of bitcoin's network

<articmine> Lighting is broken because of a broken later 1 on scaliny

<articmine> Layer 1

<rucknium> @boog900:monero.social: AFAIK, it has not been measured at the whole network scale, but some merchants have on-chain BTC and lightning enabled. That could give a hint.

So maybe motivation to use Monero payment channels is less than with lightning?

a quick search gives 200K lightning txs/day and 500K bitcoin txs/day

<rucknium> Monero's low fees would push fewer user to use a PCN (payment channel network).

<articmine> It is not a fair comparison to use LN on BTC

<ravfx:xmr.mx> If only LN would work consistently.

<ravfx:xmr.mx> You need to have like many channels well connected (like 4-5, to big centralized node). For it to be usable.

<ravfx:xmr.mx> I test it on average, one time a year

<articmine> @rucknium: Not necessarily. Low fees will make the payment channel secure

<articmine> Unlike BTC

I think we also have many unknowns here. E.g. how far we try to go with routing payments over multiple hops.

<articmine> We don't need routing

I think payment channels are most useful for small single hop channels (repeated payments)

<articmine> This is one of the problems with LN on BTC

<ravfx:xmr.mx> Have to try all possible route til it fine one that work right or abort (if it work similar to LN).

<ravfx:xmr.mx> Can it actually be made without routing?

<ravfx:xmr.mx> tevador: Yeah, create a channel with the entity you are going to pay to, that's what work better

<rucknium> tevador: I agree with that. But that's a small use case.

Could turn out be a pretty small market right now, repeated XMR payments ...

<ravfx:xmr.mx> Everything related to IT stuff (VPS, VPN, etc, etc... repeated XMR payments

<rucknium> Won't you still need an always-alive process to be running somewhere, with internet access?

<articmine> I am sitting at a Starbucks. It is not a small use case

<boog900> 256 bytes isn't crazy but it's not so small where I think this is definitely worth it.

Could be reduced down to ~100 bytes with just 2 possible lock times (e.g. 10 blocks and 720 blocks)

The leaky version is 0 bytes

The leak is "I am a channel related tx", right?

<ravfx:xmr.mx> One of the only advantage of BTC LN, is that they are instant (when they work). Do we need a 10 lock timer?

More or less, if people don't lock for other purposes

Yes, eveyone could see unlock_time = 1 in the tx

<rucknium> tevador: tevador: After analysis, does your 0-byte leaky version still work, with the same features as the 256-byte one?

<jeffro256> rbrunner: More lile "I am possibly a channel-related tx. I may also be a normal spent outside where the age is >= 24 hours"

<jeffro256> *like

<jeffro256> *normal spent enote

<jeffro256> gah

The leaky version only supports 2 locks times. The ring signature-based one can have many possible times (the proposal currently lists 7 lock times from 10 blocks to 8 years).

Ok. That's not really terrible, as leaks go :)

<articmine> It t like ~3% of a 2in 2out tx

<articmine> 256 bytes

Technically, the leaky version can support more lock times at the cost of more leakage

<rucknium> Isn't Lightning's HTLC use standardized to a specific lock time?

If people think 256 bytes is too much, I can put the leaky version back into the proposal as an option

I personally found 256 prunable bytes a rounding error

<rucknium> "I think this is the only way to get payment channels without a trusted 3rd party." Have you looked at all the Monero payment channel papers to check this claim? > <tevador> I think this is the only way to get payment channels without a trusted 3rd party.

We could still switch / elevate to the hidden version if payment channels should become widely popular? After starting with the dead-simple leaky version, I mean.

rucknium: I checked published papers about Monero payment channels and they all use a key escrow. However, it's possible that I missed some paper. I'm not aware of any proposal without a trusted 3rd party.

<rucknium> Search for "payment channel" here: moneroresearch.info

<rucknium> moneroresearch.info/203 Wang, X., Lin, C., Huang, X., & He, D. (2023). Anonymity-Enhancing Multi-Hop Locks for Monero-Enabled Payment Channel Networks. IEEE Transactions on Information Forensics and Security, 1–1.

<rucknium> I didn't look too closely for hidden assumptions.

<rucknium> To me, the clearest use case for payment channels is XMRChat or similar services. You want to send multiple payments to the same recipient in less time than the 10 block lock.

<rucknium> I don't remember if @fiatdemise:matrix.org has commented on payment channels.

<boog900> I don't know if this would work but we have tx pre-signing where anyone can make the membership proof right? Could we add a minimum height field to the pre-signed part of a tx and then make the membership proof when it becomes spendable?

<boog900> Normal txs will set this minimum height field too so no txs stand out?

<jeffro256> @boog900: It would leak the signing date for pre-signed txs

<boog900> ah yeah :(

<boog900> We could have some txs set it to 0 randomly?

<vtnerd> the curve tree root is the issue

<vtnerd> or maybe Im mistaken on how that works

payment channels need a relative lock, a minimum height restriction is an absolute lock

a relative lock is more useful - you can simulate an absolute lock using a relative lock but not vice versa

<boog900> its a minimum height on when you can add the tx to the chain, this is the same as setting unlock_time requiring the tree root to be so many blocks old

<boog900> in the original

if it's the min height *difference* then it's exactly my "leaky" proposal with unlock_time = 1

The point is that you have 2 offline pre-signed transactions TA and TB. TB spends from TB. You don't know when TA will be submitted.

TB spends from TA*

<boog900> Kinda but it allows you to use the most up to date tree root so doesn't require locked txs to expose that they are spending an output over a day old.

<boog900> It keeps the fact the tx was locked private

Your proposal is an absolute lock, which won't work for payment channels

<boog900> I don't see how it is any different

You can comment your proposal in issue #161, but you are proposing an absolute lock (i.e. the signer signs the height)

<rucknium> 5. Post-quantum encryption (monero-project/research-lab #151#issuecomment-4412416686). Jamtis (gist.github.com/tevador/639d083c994…32#appendix-c-instant-sync-protocol).

I have no comments on this agenda item

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

<rucknium> @jberman:monero.social and I are working on the wallet-forgetting-it-spent-a-coin problem. This might be the code that fixes it.

<rucknium> I think we are at 100GB unpruned blockchain size now.

<rucknium> Anything else on stressnet?

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

<jeffro256> Thanks everyone!

rucknium: I checked the "multi-hop locks" paper you linked earlier. It doesn't define a payment channel protocol for Monero. It provides a method how to extend an existing single-hop PC into a multi-hop network. So naturally, it requires a pre-existing payments channel protocol (it mentions PayMo).

PayMo is an existing PC protocol for Monero, but it has expiring channels, which is a big disadvantage (shared with all protocols that use absolute locks) and requires a trusted setup.

<rucknium> tevador: Thanks for giving it a look

ravfx: re: 10 block lock. You’d need the lock for opening/closing/recover tx submission (so a minimum 30min to open/close channel + multisig setup). But state changes would be fast (a few messages back and forth).

60min* 30 blocks

<gingeropolous> if anyone has any ideas for experiments for monerosim on the MRC, let me know. I know someone recently mentioned the p2p ssl PR . Unfortunately anything PoW is off the table (proper PoW hooks require modding monero code). ( of course, anyone can use monerosim on their hardware or rent some beefy stuff to run big sims or use it on the MRC themselves)

<boog900> @gingeropolous: What RPC endpoints do you need for monerosim? Cuprate has the ones wallet use working

<boog900> Or working enough for wallets, some stuff that isn't needed for wallets is still stubbed

<boog900> We are currently testing wallet RPC before a beta release so more testing is welcome :)

<rucknium> @boog900:monero.social: I don't think any RPC endpoints are needed. Some nodes in the simulation just act as P2P tx relay nodes. There may be other blockers to dropping cuprate into the simulation.

<boog900> Ah I thought RPC was the blocker from previous conversations

<boog900> I am happy to look at adding whatever is needed to cuprate to get it working in the sim though

<gingeropolous> yeah i can point the bot at cuprate integration, then we can compare the networks in the sim with/without cuprate etc.

<gingeropolous> github.com/cuprate/cuprate >>>> use a release or master?

<rucknium> @boog900:monero.social: Maybe you were thinking about stressnet monitoring.

<boog900> @gingeropolous: Main

<boog900> matrix.to/#/!zPLCnZSsyeFFxUiqUZ:mon…l&via=matrix.org&via=unredacted.org

<boog900> @rucknium: I remember that, I'll have the ones used there ready when we have FCMP ready, hopefully in time to still have a stressnet running :)

<rucknium> @boog900: Yes you'll need RPC endpoints if you want a cuprate-only Monerosim because txs have to be submitted to nodes.

<boog900> Ah ok, we should support that now as that'll just fall under what wallets need