15:01:05 MRL meeting in this room in two hours. 16:59:04 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) 16:59:22 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 17:00:04 No additional material change to report from last week on other FCMP++ items from my end beyond above 17:01:08 Meeting time! https://github.com/monero-project/meta/issues/1426 17:01:11 1. Greetings 17:01:13 Hi 17:01:51 Hi 17:01:57 Hello 17:02:06 Hi 17:02:07 hi 17:02:24 Hi 17:02:46 Howdy 17:03:20 2. Updates. What is everyone working on? 17:03:53 me: Keeping stressnet stressed. Investigating bugs on stressnet. 17:04:02 me: upstreaming / reviewing FCMP++/Carrot PRs, working on upstreaming bug fixes, implementing performance enhancements 17:04:37 me: time-locks / payment channels research 17:04:37 me: continuing to plug away on monerosim. 17:05:13 Me: updated ssl stressnet pr, working on separate changes for ssl, and working on testing the p2p slowdown fix 17:06:38 3. FCMP++ to-do list status. Programming tasks (https://github.com/seraphis-migration/monero/issues/53). Reviews and audits (https://cryptpad.fr/sheet/#/2/sheet/view/yPVIUywwA9-deE9VF6GYm9bXbPdCerdST3UDEEfBxcM/embed/). 17:06:54 @jberman:monero.social gave an update right before the meeting: 17:06:58 Hi 17:07:25 > 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) 17:07:36 > 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 17:07:56 me: payment channel security thoughts, making progress on multisig PR bugfixing 17:08:52 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 17:10:06 Is hw wallet support mandatory for hf? Cause those are going to take a while. 17:10:07 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. 17:10:30 No, at least not in the core repo. That's my opinion 17:11:26 Ok seems reasonable 17:11:36 Are there big technical challenges for HW wallet support, e.g. need to fit big objects on limited wallet RAM? 17:11:40 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. 17:13:08 @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 17:14:03 "remove phase 2 and 3 audits as a dependency for HF activation" has confusing wording, IMHO. 17:14:35 "HF activation" means the date that the HF occurs, to me. 17:15:04 By "HF activation", I meant "HF activation code merge", sorry 17:16:34 What happens if after that a critical problem surfaces that is not correctable within time, as a worst case scenario? 17:16:44 Or, can we "take back" the HF? 17:16:54 Here's a 2020 paper on HW wallets for Monero https://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. 17:17:06 (As a result of the on-going audits and reviews) 17:17:44 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 17:17:57 Last HF, the announced date was moved at least once. I don't think any HF binaries were released and then withdrawn. 17:18:32 rbrunner: We can "take back" the HF before it happens if users/companies stay up-to-date on releases 17:18:37 Anyone who downloads the binaries and neglects to update will be stuck on a bad fork. 17:19:06 Yes, as the possibly worst outcome, however unlikely 17:19:37 Note that this is something that can happen anyways without audits, with such large update, and we should prepare for it regardless of auditing > What happens if after that a critical problem surfaces that is not correctable within time, as a worst case scenario? 17:19:43 That's a similar outcome for people who just never update and a HF happens. 17:19:56 Right. 17:21:02 Seems to me the community of Monero users must be pretty "forking aware" now 17:22:07 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. 17:22:17 If only we could get Linux package managers to also be forking aware 17:23:34 Could you describe phases 2 and 3 for us, @jeffro256:monero.social ? 17:24:09 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. 17:24:51 Then we have a contingency plan in case the audit feedback requires a HF relevant to previous release 17:25:06 You say "the 6-month conventional waiting period" as if a 6-month waiting period has ever happened before :D 17:25:16 Phases 2 and 3 are defined in this document: https://github.com/seraphis-migration/monero/issues/294 17:25:19 There should generally be at least a 2-3 month code freeze before the HF, if possible. 17:25:35 @rucknium: Sometimes I prefer they are not. I have had issues with Bitcoin and Linux package managers 17:25:48 Never with Monero 17:25:53 @tevador before HF activation, correct? 17:26:49 Yes, before the fork activation date. 17:28:03 I think that that is certainly possible with the planned scopes of phase 2 and phase 3 17:28:37 I'm working on a Gannt chart today because the timing and dependencies is getting hard to describe in words 17:29:30 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 17:30:10 maybe "HF enabled release" or "HF ready release" ... 17:30:19 What was the exact definition of code freeze again? 17:30:43 presumably there would be a branch at the very least 17:30:47 I went back and looked. The previous HF binary was released less than a month before the HF activation date: https://github.com/monero-project/monero/releases/tag/v0.18.0.0 17:30:47 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. 17:30:58 lol fair 17:31:14 I think that was always "the idea" :) 17:31:25 I was under the assumption that that was the target for previous HFs 17:31:29 That collided sooner or later with harsh cold reality 17:32:07 we should’ve created the branch earlier than the 1 mo, and “froze” changes, but I don’t recall now 17:32:16 Code freeze means only bug fixes can be merged... but this rule has not always been followed. 17:32:23 I think it's still a good idea, and maybe *this* time, swapping almost the whole technology stack, we should pull that through 17:32:43 The 2022 HF delay was about multisig IIRC 17:33:38 And also with coin exploits popping up left and right ... 17:35:19 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. 17:36:24 Will there be a bounty on exploits against the the frozen code before the HF is activated? 17:37:08 Something that goes beyond the usually offered bounties would be a first, as far as I know 17:39:06 The Monero VRP states that "code in all branches; including the master branch and any release branch" are in scope 17:39:11 The VRP scope is wide. Maybe something special isn't necessary: 17:39:20 > This Vulnerability Response Process and subsequent bounty reward apply to the following: 17:39:20 > Code implementation as seen in the Monero Project GitHub repositories 17:39:20 > This includes code in all branches; including the master branch and any release branch 17:39:20 > Written research from the Monero Research Lab which dictates said code implementation 17:39:30 https://github.com/monero-project/meta/blob/master/VULNERABILITY_RESPONSE_PROCESS.md 17:39:47 But the potential reward isn't defined well. 17:40:09 tevador: Maybe we should reduce the scope to *current release branches... 17:40:45 I don't care if there's a vuln in v0.12.0.0 that got fixed 5 years ago 17:41:21 Yes, that scope seems overly broad 17:42:54 More on this agenda item? 17:44:05 @jeffro256: Does this include anything that is pre release, or in testing for release etc. 17:44:24 Does anyone currently object to not blocking the first release with phase 2 and phase 3 audits ? 17:44:29 I understand the case of clearly obsolete code 17:45:11 fwiw it has never been an issue that someone argued about old release branches, but yes the wording should be updated 17:45:37 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 17:46:47 Right now looks like a calculated risk worth taking to me. 17:47:31 Fair enough, I just feel we should be careful and precise with the language. 17:48:02 @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. 17:48:31 That's fair, AFAIK it should be release before next MRL meeting 17:48:36 *released 17:49:23 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 17:49:59 selsta: I agree 17:50:04 "small buffer" should be at least 1 month 17:51:38 How soon, from today, is the expected HF code freeze, i.e. when would the 6-month clock start ticking? 17:51:52 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 17:52:56 Are we still branching v0.19 from master to test Guix and other changes in master? 17:53:08 @rucknium: @tevador were you talking about a pre-first-HF-enabled release code freeze, or a pre-HF-activation code freeze? 17:53:19 tobtoht: I would say yes 17:53:34 Polyseed looks more or less ready 17:54:05 We should do that ASAP IMO 17:54:22 I think the code freeze should generally precede the first release binaries 17:55:27 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? 17:56:41 what's the status from stressnet for txrelay v2? ready for v0.19? 17:56:59 jeffo256: That's debatable, but generally you want to freeze all features before the release and focus on bug fixes 17:57:45 yeah theres lws RPC changes for example that someone has to slog through (review) 17:58:00 selsta: I think we should get at least a week of more testing with the latest proposed fix of the double-spend issue, IMHO. 17:58:14 @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 17:58:43 I have always disliked an overly strict code freeze 17:58:45 I think that that kind of a freeze is simply too broad 17:59:56 I would agree that p2p and consensus features should be frozen for some period of time before release 18:01:00 non-consensus changes can go into .1 anyways 18:01:51 I think that basic sending / receiving / syncing wallet features should be frozen before the first release too 18:01:59 What is the expected timeline for the HF? Can RandomX v2 stil make it? 18:02:28 But, respectfully, waiting for Trezor and Ledger to activate FCMP++ would be a mistake 18:02:56 They don't move very fast 18:02:59 Isn't RandomX v2 already ready? sech1 ? 18:03:19 It's ready but not on the daemon side AFAIK? 18:03:26 That's also what I dimmly remember 18:03:41 there is a PR for it on daemon side, jeffro wrote it 18:03:49 RandomX v2 wallet related code is not developed yet but that doesn't require HF 18:03:59 Do any HW wallet manufacturers move fast? Could there at least be one sure to be ready for the HF? 18:04:12 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: https://github.com/monero-project/monero/pull/10038. I need to add back the tx count and update the flow charts in the documentation, if we are to keep it 18:04:22 But besides that, the consensus changes are done 18:05:02 I plan to integrate DoS-resistant header-only sync after #10038 is merged, but that shouldn't be a blocker to the FCMP++ release 18:05:07 Thanks, I missed that PR 18:05:31 @rucknium: I'm trying my damndest 18:05:50 It would probably help to have a bunch of people bug them, IDK 18:06:06 @jeffro256:monero.social: I know you are. Thanks. But would users have an alternative in time for the HF? 18:06:50 realistically Ledger/Trezor will use LLMs to implement FCMP++ so I assume it won't take too long 18:07:40 oh no 18:07:58 i ponder if we should add things to make the codebase llm friendly 18:08:07 Maybe their revenue isn't great right now. 18:08:20 Many, many comments help. Something we are proudly famous for :) 18:08:45 rbrunner: Is that sarcasm from you? 18:08:53 Yes, of course ... 18:09:25 I think we should move the agenda along. Feel free to discuss this agenda item after the meeting. 18:09:32 Well, not the comment bit. They do support the work of LLMs greatly, from the little I know so far 18:09:36 4. Relative locks with FCMP++ (https://github.com/monero-project/research-lab/issues/161). 18:10:03 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. 18:10:37 Thank you, tevador 18:10:58 Just wondering: If that proposal fully works out, may this result in the best Monero channel proposal so far? 18:11:20 > The approximate size of a 7-ring signature is 256 bytes, which is relatively small compared to the size of the FCMP++ proof. 18:11:36 Would the 256 bytes go into the tx_extra only of txs that need it? 18:12:00 No, this would be a hard forking change for all transactions 18:12:16 I think that it need to be validated by consensus for it to be relied upon by a counterparty 18:12:55 It is still a very small cost from a scaling perspective 18:13:09 tevador: Technically, it could be a soft fork if v17 doesn't enforce unlock_time=0 18:13:10 The ring signature definitely has to be validated by consensus, otherwise transactions could spend enotes not present in the chain. 18:13:55 I'm not very enthusiastic about adding to blockchain size in every tx for payment channels. 18:14:25 Would this be useful to simplify atomic swaps? 18:14:32 on the flip side, it's all prunable data 18:14:45 Yes, it can also help for atomic swaps 18:14:52 Prunable data does help 18:15:15 From a scaling perspective a payment channel that actually works can be very helpful 18:15:51 The small extra transaction weight is well worth it 18:16:09 I think this is the only way to get payment channels without a trusted 3rd party. 18:16:35 what % of txs would have to be done off chain for this to be worth it? 18:16:47 RandomX v2 is ready and released, XMRig version with v2 support is also released. Monero doesn't have v2 support yet. 18:18:07 @boog900:monero.social: About 5% to break even, right? 18:18:24 boog900: If the average fcmp++ tx size is 10K then about 2.5% unless I'm mistaken 18:19:24 My original proposal was using unlock_time = 1, which is an existing field, so 0 extra bytes, but it leaks. 18:19:37 @boog900: 256/(tx size in bytes) 18:19:43 do we know how much lightning does? 18:19:49 of bitcoin's network 18:20:35 Lighting is broken because of a broken later 1 on scaliny 18:20:47 Layer 1 18:20:58 @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. 18:21:19 So maybe motivation to use Monero payment channels is less than with lightning? 18:21:34 a quick search gives 200K lightning txs/day and 500K bitcoin txs/day 18:21:40 Monero's low fees would push fewer user to use a PCN (payment channel network). 18:21:52 It is not a fair comparison to use LN on BTC 18:22:24 If only LN would work consistently. 18:22:24 You need to have like many channels well connected (like 4-5, to big centralized node). For it to be usable. 18:22:24 I test it on average, one time a year 18:23:02 @rucknium: Not necessarily. Low fees will make the payment channel secure 18:23:15 Unlike BTC 18:23:49 I think we also have many unknowns here. E.g. how far we try to go with routing payments over multiple hops. 18:24:12 We don't need routing 18:24:40 I think payment channels are most useful for small single hop channels (repeated payments) 18:24:51 This is one of the problems with LN on BTC 18:24:58 Have to try all possible route til it fine one that work right or abort (if it work similar to LN). 18:24:58 Can it actually be made without routing? 18:25:19 tevador: Yeah, create a channel with the entity you are going to pay to, that's what work better 18:25:19 tevador: I agree with that. But that's a small use case. 18:25:40 Could turn out be a pretty small market right now, repeated XMR payments ... 18:26:08 Everything related to IT stuff (VPS, VPN, etc, etc... repeated XMR payments 18:26:15 Won't you still need an always-alive process to be running somewhere, with internet access? 18:26:23 I am sitting at a Starbucks. It is not a small use case 18:26:35 256 bytes isn't crazy but it's not so small where I think this is definitely worth it. 18:27:31 Could be reduced down to ~100 bytes with just 2 possible lock times (e.g. 10 blocks and 720 blocks) 18:27:56 The leaky version is 0 bytes 18:28:23 The leak is "I am a channel related tx", right? 18:28:40 One of the only advantage of BTC LN, is that they are instant (when they work). Do we need a 10 lock timer? 18:28:40 More or less, if people don't lock for other purposes 18:28:42 Yes, eveyone could see unlock_time = 1 in the tx 18:28:55 tevador: tevador: After analysis, does your 0-byte leaky version still work, with the same features as the 256-byte one? 18:29:20 rbrunner: More lile "I am possibly a channel-related tx. I may also be a normal spent outside where the age is >= 24 hours" 18:29:34 *like 18:29:43 *normal spent enote 18:29:44 gah 18:29:50 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). 18:29:59 Ok. That's not really terrible, as leaks go :) 18:30:13 It t like ~3% of a 2in 2out tx 18:30:27 256 bytes 18:30:31 Technically, the leaky version can support more lock times at the cost of more leakage 18:31:34 Isn't Lightning's HTLC use standardized to a specific lock time? 18:31:54 If people think 256 bytes is too much, I can put the leaky version back into the proposal as an option 18:32:28 I personally found 256 prunable bytes a rounding error 18:32:36 "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? > I think this is the only way to get payment channels without a trusted 3rd party. 18:33:08 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. 18:34:19 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. 18:34:31 Search for "payment channel" here: https://moneroresearch.info 18:34:57 https://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. 18:35:12 I didn't look too closely for hidden assumptions. 18:36:47 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. 18:37:04 I don't remember if @fiatdemise:matrix.org has commented on payment channels. 18:39:25 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? 18:39:25 Normal txs will set this minimum height field too so no txs stand out? 18:40:15 @boog900: It would leak the signing date for pre-signed txs 18:40:41 ah yeah :( 18:41:16 We could have some txs set it to 0 randomly? 18:42:17 the curve tree root is the issue 18:42:49