00:17:53 Nice. 16:50:47 Meeting in a bit more than 1 hour 17:44:53 @kayabanerve:matrix.org another gentle nudge on https://github.com/monero-oxide/monero-oxide/pull/187 and https://github.com/monero-oxide/monero-oxide/pull/188 17:47:13 Mainly 188 18:00:03 Meeting time. Hello! https://github.com/monero-project/meta/issues/1430 18:00:14 hey 18:00:41 Howy 18:00:43 Howdy 18:01:20 Another summer time meeting :) 18:01:24 Hello 18:02:00 Hello 18:02:21 Alright, what is there to report from last week? 18:02:28 waves 18:02:56 reviews, addressing review comments, rebasing and solving merge conflicts 18:02:59 I can still do one or the other improvement of my Polyseed PR because I still receive review comments. Nice to see how many people engage! 18:03:21 me: finishing up on mx25519 PRs (thanks tevador for reviewing!). Waiting on https://github.com/monero-oxide/monero-oxide/pull/188 for https://github.com/monero-project/monero/pull/10963. Reviewing j-berman's FCMP++ PRs, made a Gannt chart for FCMP++/Carrot work 18:03:47 Me: work on I2P integration, GUI testing for Qt6 migration, and fixing some issues with hardware wallets. I also submitted another CCS proposal for general development, and took a slight detour to fix a few dozen memory safety issues in i2pd :) 18:04:12 i2pd, that's one of the open source server projectes then? 18:04:21 me: also reworked carrot_core to use the new unclamped API and crypto::x25519 wrapper 18:04:29 No significant update on my end, continuing upstream FCMP++ PR's. Have been a bit busy with personal stuff lately, will be back 100% Thursday 18:04:33 @rbrunner7: Yes, a C++ implementation of the I2P daemon. 18:05:25 I wonder how Monero will fare with a good implementation. Seems always a bit below a critical mass so far to me ... 18:05:40 Rebased Ukoe's carrot_impl review PR, will submit comments to that soon, then will implement review feedback, then peel and rework carrot_impl for recent carrot_core changes 18:06:49 @jeffro256:monero.social: Will you proudly present you chart / timeline in the MRL meeting? 18:07:00 Yes, I can do that 18:08:30 My last main change to the Polyseed PR, by the way, was respecting custom restore heights even with Polyseeds. A discussion convinced me that this should be ok. 18:08:50 Cake Wallet is having issues with transactions not getting relayed. I looked a bit into it and so far wasn't able to figure out why. We did not have any relevant changes on the daemon side in a while. 18:09:09 Maybe a targeted attack? 18:09:10 They asked if it's a network issue but I haven't seen evidence for that so far. 18:09:34 No logs unfortunaterly. 18:09:35 Do any other wallets have reports of the same issue? 18:09:52 You mean the transactions go from the wallets on the smartphones to their Monero daemons and then get stuck there? 18:10:45 It's not clear, it looks like the node has no knowledge of the tx, or it's still in the phase where the daemon acts like it doesn't know about it. 18:11:14 So the tx never shows up locally? 18:12:30 Hmmm then it feels like an application issue ngl 18:13:02 could be related? https://github.com/monero-project/monero/pull/9295 18:13:02 Fwiw Rucknium's similar issue stems from a restricted RPC, if it was unrestricted the wallet would detect the tx. So I think unrelated in case that's a thought here 18:13:21 Maybe they didn't change something on the side of their app, but some Android update does not play nice anymore with their software? 18:14:21 a feather wallet user reported one of my nodes dropped a tx, but feather has multi tx broadcast so it was fine. and a 2nd person told me about a similar tx - the node had not seen their txid, with no double spends or failures seen, odd 18:14:29 Wasn't there a few recent change which hid RPC information from restricted clients? Maybe they pulled in those commits, and expected the data and timing to remain the same 18:15:01 We did have this person who reported a similar issue but was using old software, and they did not have a publicly exposed node: https://github.com/monero-project/monero/issues/10923 18:15:42 I think we'll just be stumbling around in the dark without more info about this 18:15:45 if there was a network wide attack we would get more reports from users that don't use Cake Wallet like exchanges 18:16:11 yes, without logs we won't be able to figure this out 18:16:31 Well, depending on what you want to achieve, just attacking the Cake Wallet nodes is already enough 18:17:28 But I speculate that would be a kind of attack that is not publicly known until now? 18:17:49 Doesn't Cake Wallet (have the option to) use nodes besides their own? 18:17:57 yep 18:18:30 But many people may not know that 18:18:59 me: multisig update is ready, waiting on hotcold stuff being merged before I can PR 18:19:25 That's nice. So multisig is saved for the time being! 18:19:42 Still experimental (tm) :) 18:20:05 It's going to need thorough use-testing @rbrunner7 18:20:24 I see ... 18:20:40 UkoeHB: I just rebased the carrot_impl review PR, I will try to merge that ASAP pending feedback on the PR 18:20:46 Trail of Bits publicly shared their audit of the FCMP++ integration Phase 1 here: https://github.com/trailofbits/publications/blob/master/reviews/2026-07-magicgrants-monerofcmp++crypto-securityreview.pdf 18:20:52 Also I should probably see if the python tests still run... 18:21:16 jeffro256: ty I reset the branch 18:21:20 I'll update all the places that publicly reference that audit with that link when I get the chance 18:21:25 @jberman:monero.social: How bad is it? 18:22:41 The audit? It was all informational issues. The audit went well 18:22:55 Good. 18:23:25 It's been complete for a while and we've had the content from the audit for a while, but we've been waiting on them to have it publish-ready 18:23:50 So we've known the informational issues and their rationalethey identified for a while 18:25:32 Ok. As it looks we are through with the reports, the obligatory question: Anything to discuss today beyond those? 18:26:03 I wanted to discuss something before the MRL meeting regarding planning for FCMP++: should we wait 6 months after the beginning of the code freeze, or 6 months after the end of the code freeze to activate the HF? The former would move the schedue for v17 activation by 4 weeks. Sech1 already gave his feedback (thank you): 18:26:03 > wait period is there to let users update their nodes, miners, and maybe some custom code. Mostly the miners and custom code - nodes can be updated much quicker. So 6 months after the code is finalized (except for bugfixes) 18:26:40 *move up 18:27:12 Not sure I understand. What is "the end of the code freeze"? 18:27:50 4 weeks after the merge of the HF table update, and thus the merge of the first commit that is "FCMP++ ready" 18:27:56 or FCMP++ enabled, rather 18:28:31 The beginning of the code freeze the moment that me merge in said change 18:28:34 Hmm. Still not sure about the difference of the two options on the table, sorry 18:28:52 AFAIK there has never been a wait period of 6 months before HF. However, if we want to do it, it should be 6 months from the first production release, IMO. 18:29:49 Then follow-up: would the first production release be prepared ASAP after the HF activation merge? 18:29:58 This is probably a dumb question, but why? 18:29:59 To clarify: I have the same opinion as sech1 18:30:11 The whole 6 months numbers came from me IIRC :D 18:30:17 Isn't a sensible definition of "code freeze" the point in time where we "freeze" the release branch and only do the absolutely necessary changes? 18:30:20 It was related to miners updating their XMRig 18:30:36 But since XMRig is already 4 months in, it's mostly out of the picture now 18:31:01 @rbrunner7: Yes. TBC, I have 2 different code freeze planned in the schedule: a code freeze for all consensus and p2p, then a later freeze for wallet features 18:31:23 Ah, that's the bit I was missing, two freezes 18:31:35 sech1: afaik other randomx features like commitments are still not in xmrig yet? 18:31:37 Because IMO waiting for multisig, hot/cold, HW, knowledge proofs, all sync_tx features, etc is not a good idea 18:31:59 @rbrunner7: Well the 2nd freeze isn't relevant for this specific planning question 18:32:14 XMRig supports commitments for RandomX v2 18:32:18 or well, they are implicit in a way, just one extra step in the pipeline 18:32:20 In Stratum protocol 18:32:24 Just when I thought I understand :( 18:32:24 Pools don't (yet) 18:32:28 6 months from the commit when the first HF-ready monerod binary can be built 18:32:29 But pools can be updated faster 18:32:52 So if we wait 6 months after first production release, where do we place the first production release in relation to the first HF-enabled merge? 18:33:00 then all good. I guess that would need to be updated for mining directly against monerod rpc using the new block format that includes commitment 18:33:06 "the first HF-ready" means it already has the hardfork height hardcoded 18:33:29 tevador: So *don 18:33:46 So don't wait on the first production release then? 18:34:01 sech1: Yes 18:34:03 Monero solo mining is not supported in XMRig yet, but it's a much smaller chunk of the network hashrate 18:34:10 *solo mining for v2 18:34:34 If the first release need all wallet features then no, don't wait 18:35:24 sech1: then that's all good for miners/randomx, and other stuff can update faster 18:36:00 https://github.com/xmrig/xmrig/blob/master/src/backend/cpu/CpuWorker.cpp#L321-L326 18:36:22 If we can say with good conscience "Ok, we are pretty much finished, from now on only urgent fixes, a.k.a. code freeze" won't this be more or less the point where we can risk a first public release? Or do you see there the question of how much wait time? 18:36:58 Okay, can we agree on the following plan?. Event A) HF-enabled merge is merged into master. Event B) First prodution release. Event C) Month-long first consensus/p2p code freeze. Event D) 6-month v17 wait period. Event B depends on A, Event C depends on A, Event D depends on A, and not C nor B 18:38:05 code freeze and the first public release must still be separated by a few weeks to test it and fix the most severe bugs 18:38:14 But we can also agree that wide testing only starts with B)? 18:38:34 This plan may mean that there is less than 6 months of wait between Event B and Event D, depending on long it takes us to prepare/publish the first production release 18:39:10 And you guesstimate right now that between A) and B) we will have about 1 month? 18:39:32 Not necearrily, it could be one day. 18:39:41 I think anything more than 2 months between B and D would be sufficient. 18:39:45 Unless we want to make event B depend on event C 18:40:00 No, I mean, what is realistic. Releases to take their time. 18:40:33 btw first production release also means testnet forks to fcmp++ 18:40:38 It totally depends on how fast it gets pushed out, with the current plan 18:40:54 and everyone tests their stuff on testnet 18:40:59 pools, miners, exchanges etc 18:41:30 6-month wait period can start right at B) 18:41:37 Yeah, rbrunner7 makes a good point for putting out the first point release as soon as possible: the quicker it is out, the faster we get real user testing 18:42:21 sech1: I understand jeffro wants the 6 months start at A) 18:42:23 maybe this: "fisrt release -> a couple weeks wait -> testnet fork -> 6 months wait -> mainnet fork"? 18:42:53 well, testnet fork can be tied to A) 18:43:18 just it will make harder for people to test the actual fork sequence without the released binaries 18:43:22 I think so as well. Anybody bold enough to use testnet deserve what they get :) 18:43:49 sech1: I think that having the 6 month wait start after testnet/stagenet activation is a bit too conservative for more taste, I would prefer the activation is sooner than that 18:44:14 It's not like no one is testing until the offical testnet activation date 18:44:35 We've had a stressnet live since October 18:44:48 6 months is not a sacred number, it can be shorter - given that XMRig miners are mostly updated already 18:45:23 I still need to prepare P2Pool for FCMP++, but I guesstimate it will not take more than 1 month 18:45:44 Remember that all transactions before FCMP activation will be eventually deanonymized, which is a good argument not to delay the fork unnecessarily. 18:45:44 At least this discussion shows that some good labels for all the points in time that are important will be very useful for a good discussion ... 18:46:59 https://github.com/xmrig/xmrig/releases/tag/v6.26.0 - release on Mar 28th, so starting from October XMRig is out of the equation - I assume that most miners will be updated by then 18:47:56 What I wonder a bit: Point A), the day when jeffro, jberman and others proudly declare "FCMP++ coding is done, heureka", that day alone has not much meaning. It only gets meaning through testing, IMHO. 18:48:15 sech1: would you find it acceptable to activate 6 months after HF-enabled merge on master, assuming that the first production release was prepped ASAP after that point, and the announcement was widely disseminated? 18:48:21 I have been testing go-p2pool in stressnet, "as is", most of the work was bringing in the Carrot derivations (and keeping up with changes), so P2Pool should indeed be fairly easy (ofc P2Pool is in C) 18:48:42 jeffro256 yes 18:48:52 in fact, it can be even shorter than 6 months 18:48:59 @rbrunner7: I agree, although, we have been testing, debugging, and reviewing each other's work for well over a year FWIW 18:49:10 but not too much shorter 18:49:16 less than 4 months will be too tight 18:49:42 Does that sound good tevador?> 18:49:55 I'm OK with that 18:49:58 But aren't some pretty big puzzle parts like the "work for submitting big transactions" still missing? 18:50:34 PoWER? Yes, that's a fair point. That hasn't undergone much review, and isn't currently implemented 18:50:34 (Out of the loop, admittedly.) 18:50:55 Or rather, there's a PR for it by hinto, but it has yet to be integrated and throughly tested 18:51:15 But yeah, fair point, extensive stressnet runs do mean something of course 18:51:56 There are also coins merge mining with Monero (Tari on mainnet now, DarkFi on testnet) - they will need to synchronize their forks too, not sure how capable they are and it's secondary to Monero's schedule 18:52:58 Maybe they need the push of an announced hardfork date :) 18:53:00 Surely 6 months is enough time to update to RandomX v2 + commitments, plus the field changes to the block content hash? 18:53:22 I vaguely remember that I helped Tari to untangle Monero block template construction/verification, and FCMP++/Carrot changes it quite a bit, so I'll have to help them again 18:53:43 DarkFi guys seem to be much more capable 18:54:21 Did some Tari devs already leave, taking "low-level knowledge" with them? 18:54:30 yes 18:54:34 sech1: I guess that they now have to use Carrot 18:54:52 Tari is almost all Rust, correct? I do have a Carrot library which they could use 18:55:00 yes, Tari is all Rust 18:55:02 DarkFi too 18:55:04 Tari uses monero-rs 18:55:33 which probably wont last post FCMP 18:55:36 Speaking of my Carrot-rs library, would that be a good candidate to be maintained by monero-oxide? 18:55:52 Or should I maintain it in a personal repo? 18:56:10 I think so, but I can only speak for me 18:56:43 Usually the more "official", the better for the long-term future of something, if you ask me 18:57:02 jeffro256: maybe moved in-tree as a crate into monero-oxide? 18:57:07 It already pulls in a monero-oxide dependency for definitions of H and T 18:57:47 If that would be better for the long-term health of the ecosystem, I'll make a PR to merge it into monero-oxide 18:58:08 Gotta update a couple things first though because of all the recent upstream tweaks to FCMP++ 18:58:11 would https://github.com/jeffro256/carrot be moved to be along where carrot-rs ends up at? 18:58:44 For what it's worth, I currently tend to agree to a "6 months after A)" schedule. Such a schedule would be a success anyway, compared with earlier hardforks. 18:59:41 Alright, I guess discussion will continue in the MRL meeting, if @jeffro256:monero.social brings up the point there. 18:59:49 I'm gonna keep that one ;) 19:00:16 The spec is relevant to other impls beside the Rust impl anyways 19:01:19 It looks like we reached a good point to close. Thanks everybody for attending, read you again in 1 week! 19:01:54 thanks everybody, cu 19:02:00 @jeffro256 Opinions about this PR? https://github.com/tevador/mx25519/pull/19 19:04:05 Thanks :) 19:13:19 Btw, this is something I'd like to include in the FCMP++ HF, pending MRL discussion: https://github.com/seraphis-migration/monero/pull/445 19:14:45 if that changes the tx structure, maybe a cleanup of tx v2 would be nice, given some fields are now unused on FCMP++ (no decoys) and are just extra bytes 19:28:13 I do think that the relative lock idea is cool, but at the risk of being rude, I think that it's a bit to late to be proposing big consensus features for v17 at this point, I don't want it to hold up FCMP++ 19:29:22 I want to prevent suffocation by earmarking 19:30:26 At least I want to loosen the rule that forces unlock_time = 0. That can hardly be considered a "big consensus change". 19:31:29 If consensus allows unlock_time = 0 or 1, relative locks can be soft forked later. 19:32:27 I think the usefulness for payment channels in Monero is currently somewhat questionable. Even Bitcoin, with all of its scaling issues, has made very few accommodations for things like that. Just my two cents 19:33:48 If anyone thinks allowing unlock_time = 1 will hold up FCMP++, I want to hear the arguments. 19:33:57 tevador: Okay, that's fair 19:34:36 tevador: I don't that will, I was talking about adding in signatures (increasing tx size) and validating them 19:35:31 As I wrote here, I consider only the unlock_time based variant to be feasible to implement in time: https://github.com/monero-project/research-lab/issues/161#issuecomment-5095666180 19:35:35 does the FCMP code ignore the unlock_time field? 19:35:57 It's complicated 19:36:02 I know it doesn't for old txs, it delays when txs are added to the tree 19:36:14 or at least I think I know :) 19:38:47 No, but right now, v17 implements a consensus rule that the unlock_time for non-coinbase = 0. For coinbase txs, it is already the case the unlock_time must be equal to height + 60. That stays with FCMP++. For non-coinbase outputs on-chain before v17, the unlock_time, if a block number and at least 10 blocks after its height, i [... too long, see https://mrelay.p2pool.observer/e/yKPW9JoLQ0JWMXQ4 ] 19:39:49 So all txs which unlock in a number of blocks greater than 10 after their insertion into the chain inside a tx are put into a special DB table, so they can be delated for insertion into the FCMP tree 19:40:25 oh wait yeah the field is an absolute lock so setting 1 wouldn't matter for that anyway. 19:40:36 Yes, exactly 19:42:23 So tevador is proposing that we lossen the unlock_time to allow a value of 1. I think that that shouldn't negatively interact with the FCMP++ integration AFAIK 19:42:28 *loosen 19:43:20 AFAIK, any value of unlock_time <= the first v17 block index semantially shouldn't collide with FCMP++. 19:43:59 There's the question of uniformity still, but it shouldn 19:44:13 shouldn't "mean" anything to the consenus rule 20:07:49 @rbrunner7:monero.social: so did we reach consensus that Polyseed users won't type in their Polyseed passphrase after the wallet is loaded into memory ? 20:09:15 Because I have feedback related to that 20:21:57 the passphrase isn't required after the wallet is loaded into memory 20:48:55 It's unclear to me that any sizable population would actually *use* the unlock_time = 1 feature. Any rule/feature added becomes a maintenance burden, even one nominally small (which creeps larger if wallets need to start masking this in normal traffic, opening potential fingerprinting between wallets that do/don't try to mask it). 20:49:08 And if it *is* added, I will lobby hard not to support any PC stuff in the core repo. We don't need another multisig situation. 20:49:25 PC stuff beyond the consensus enforcement* 22:38:30 Did randomx v2 have/need another security audit? 22:42:41 Dont think so 22:42:56 (former) 22:49:35 ack-j:matrix.org: the changes were iterative/minimal on existing design https://github.com/tevador/RandomX/blob/master/doc/design_v2.md 22:53:40 OK