<jeffro256> Nice.

<rbrunner7> Meeting in a bit more than 1 hour

<jeffro256> @kayabanerve:matrix.org another gentle nudge on monero-oxide/monero-oxide #187 and monero-oxide/monero-oxide #188

<jeffro256> Mainly 188

<rbrunner7> Meeting time. Hello! monero-project/meta #1430

<sneedlewoods_xmr:matrix.org> hey

<jeffro256> Howy

<jeffro256> Howdy

<rbrunner7> Another summer time meeting :)

<jpk68:matrix.org> Hello

<syntheticbird> Hello

<rbrunner7> Alright, what is there to report from last week?

<jberman> waves

<sneedlewoods_xmr:matrix.org> reviews, addressing review comments, rebasing and solving merge conflicts

<rbrunner7> 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!

<jeffro256> me: finishing up on mx25519 PRs (thanks tevador for reviewing!). Waiting on monero-oxide/monero-oxide #188 for monero-project/monero #10963. Reviewing j-berman's FCMP++ PRs, made a Gannt chart for FCMP++/Carrot work

<jpk68:matrix.org> 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 :)

<rbrunner7> i2pd, that's one of the open source server projectes then?

<jeffro256> me: also reworked carrot_core to use the new unclamped API and crypto::x25519 wrapper

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

<jpk68:matrix.org> @rbrunner7: Yes, a C++ implementation of the I2P daemon.

<rbrunner7> I wonder how Monero will fare with a good implementation. Seems always a bit below a critical mass so far to me ...

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

<rbrunner7> @jeffro256:monero.social: Will you proudly present you chart / timeline in the MRL meeting?

<jeffro256> Yes, I can do that

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

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.

<jeffro256> Maybe a targeted attack?

They asked if it's a network issue but I haven't seen evidence for that so far.

No logs unfortunaterly.

<jpk68:matrix.org> Do any other wallets have reports of the same issue?

<rbrunner7> You mean the transactions go from the wallets on the smartphones to their Monero daemons and then get stuck there?

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.

<jeffro256> So the tx never shows up locally?

<jeffro256> Hmmm then it feels like an application issue ngl

could be related? monero-project/monero #9295

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

<rbrunner7> Maybe they didn't change something on the side of their app, but some Android update does not play nice anymore with their software?

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

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

We did have this person who reported a similar issue but was using old software, and they did not have a publicly exposed node: monero-project/monero #10923

<jpk68:matrix.org> I think we'll just be stumbling around in the dark without more info about this

if there was a network wide attack we would get more reports from users that don't use Cake Wallet like exchanges

yes, without logs we won't be able to figure this out

<rbrunner7> Well, depending on what you want to achieve, just attacking the Cake Wallet nodes is already enough

<rbrunner7> But I speculate that would be a kind of attack that is not publicly known until now?

<jpk68:matrix.org> Doesn't Cake Wallet (have the option to) use nodes besides their own?

<sneedlewoods_xmr:matrix.org> yep

<rbrunner7> But many people may not know that

me: multisig update is ready, waiting on hotcold stuff being merged before I can PR

<rbrunner7> That's nice. So multisig is saved for the time being!

<rbrunner7> Still experimental (tm) :)

It's going to need thorough use-testing @rbrunner7

<rbrunner7> I see ...

<jeffro256> UkoeHB: I just rebased the carrot_impl review PR, I will try to merge that ASAP pending feedback on the PR

<jberman> Trail of Bits publicly shared their audit of the FCMP++ integration Phase 1 here: github.com/trailofbits/publications…nerofcmp++crypto-securityreview.pdf

Also I should probably see if the python tests still run...

jeffro256: ty I reset the branch

<jberman> I'll update all the places that publicly reference that audit with that link when I get the chance

<rbrunner7> @jberman:monero.social: How bad is it?

<jberman> The audit? It was all informational issues. The audit went well

<rbrunner7> Good.

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

<jberman> So we've known the informational issues and their rationalethey identified for a while

<rbrunner7> Ok. As it looks we are through with the reports, the obligatory question: Anything to discuss today beyond those?

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

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

<jeffro256> *move up

<rbrunner7> Not sure I understand. What is "the end of the code freeze"?

<jeffro256> 4 weeks after the merge of the HF table update, and thus the merge of the first commit that is "FCMP++ ready"

<jeffro256> or FCMP++ enabled, rather

<jeffro256> The beginning of the code freeze the moment that me merge in said change

<rbrunner7> Hmm. Still not sure about the difference of the two options on the table, sorry

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.

<jeffro256> Then follow-up: would the first production release be prepared ASAP after the HF activation merge?

<jpk68:matrix.org> This is probably a dumb question, but why?

To clarify: I have the same opinion as sech1

The whole 6 months numbers came from me IIRC :D

<rbrunner7> 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?

It was related to miners updating their XMRig

But since XMRig is already 4 months in, it's mostly out of the picture now

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

<rbrunner7> Ah, that's the bit I was missing, two freezes

sech1: afaik other randomx features like commitments are still not in xmrig yet?

<jeffro256> Because IMO waiting for multisig, hot/cold, HW, knowledge proofs, all sync_tx features, etc is not a good idea

<jeffro256> @rbrunner7: Well the 2nd freeze isn't relevant for this specific planning question

XMRig supports commitments for RandomX v2

or well, they are implicit in a way, just one extra step in the pipeline

In Stratum protocol

<rbrunner7> Just when I thought I understand :(

Pools don't (yet)

6 months from the commit when the first HF-ready monerod binary can be built

But pools can be updated faster

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

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

"the first HF-ready" means it already has the hardfork height hardcoded

<jeffro256> tevador: So *don

<jeffro256> So don't wait on the first production release then?

<jeffro256> sech1: Yes

Monero solo mining is not supported in XMRig yet, but it's a much smaller chunk of the network hashrate

*solo mining for v2

If the first release need all wallet features then no, don't wait

sech1: then that's all good for miners/randomx, and other stuff can update faster

<rbrunner7> 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?

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

code freeze and the first public release must still be separated by a few weeks to test it and fix the most severe bugs

<rbrunner7> But we can also agree that wide testing only starts with B)?

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

<rbrunner7> And you guesstimate right now that between A) and B) we will have about 1 month?

<jeffro256> Not necearrily, it could be one day.

I think anything more than 2 months between B and D would be sufficient.

<jeffro256> Unless we want to make event B depend on event C

<rbrunner7> No, I mean, what is realistic. Releases to take their time.

btw first production release also means testnet forks to fcmp++

<jeffro256> It totally depends on how fast it gets pushed out, with the current plan

and everyone tests their stuff on testnet

pools, miners, exchanges etc

6-month wait period can start right at B)

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

<rbrunner7> sech1: I understand jeffro wants the 6 months start at A)

maybe this: "fisrt release -> a couple weeks wait -> testnet fork -> 6 months wait -> mainnet fork"?

well, testnet fork can be tied to A)

just it will make harder for people to test the actual fork sequence without the released binaries

<rbrunner7> I think so as well. Anybody bold enough to use testnet deserve what they get :)

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

<jeffro256> It's not like no one is testing until the offical testnet activation date

<jeffro256> We've had a stressnet live since October

6 months is not a sacred number, it can be shorter - given that XMRig miners are mostly updated already

I still need to prepare P2Pool for FCMP++, but I guesstimate it will not take more than 1 month

Remember that all transactions before FCMP activation will be eventually deanonymized, which is a good argument not to delay the fork unnecessarily.

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

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

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

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

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)

jeffro256 yes

in fact, it can be even shorter than 6 months

<jeffro256> @rbrunner7: I agree, although, we have been testing, debugging, and reviewing each other's work for well over a year FWIW

but not too much shorter

less than 4 months will be too tight

<jeffro256> Does that sound good tevador?>

I'm OK with that

<rbrunner7> But aren't some pretty big puzzle parts like the "work for submitting big transactions" still missing?

<jeffro256> PoWER? Yes, that's a fair point. That hasn't undergone much review, and isn't currently implemented

<rbrunner7> (Out of the loop, admittedly.)

<jeffro256> Or rather, there's a PR for it by hinto, but it has yet to be integrated and throughly tested

<rbrunner7> But yeah, fair point, extensive stressnet runs do mean something of course

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

<rbrunner7> Maybe they need the push of an announced hardfork date :)

<jeffro256> Surely 6 months is enough time to update to RandomX v2 + commitments, plus the field changes to the block content hash?

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

DarkFi guys seem to be much more capable

<rbrunner7> Did some Tari devs already leave, taking "low-level knowledge" with them?

yes

<jeffro256> sech1: I guess that they now have to use Carrot

<jeffro256> Tari is almost all Rust, correct? I do have a Carrot library which they could use

yes, Tari is all Rust

DarkFi too

<boog900> Tari uses monero-rs

<boog900> which probably wont last post FCMP

<jeffro256> Speaking of my Carrot-rs library, would that be a good candidate to be maintained by monero-oxide?

<jeffro256> Or should I maintain it in a personal repo?

<boog900> I think so, but I can only speak for me

<rbrunner7> Usually the more "official", the better for the long-term future of something, if you ask me

jeffro256: maybe moved in-tree as a crate into monero-oxide?

<jeffro256> It already pulls in a monero-oxide dependency for definitions of H and T

<jeffro256> If that would be better for the long-term health of the ecosystem, I'll make a PR to merge it into monero-oxide

<jeffro256> Gotta update a couple things first though because of all the recent upstream tweaks to FCMP++

would github.com/jeffro256/carrot be moved to be along where carrot-rs ends up at?

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

<rbrunner7> Alright, I guess discussion will continue in the MRL meeting, if @jeffro256:monero.social brings up the point there.

<jeffro256> I'm gonna keep that one ;)

<jeffro256> The spec is relevant to other impls beside the Rust impl anyways

<rbrunner7> It looks like we reached a good point to close. Thanks everybody for attending, read you again in 1 week!

<sneedlewoods_xmr:matrix.org> thanks everybody, cu

@jeffro256 Opinions about this PR? tevador/mx25519 #19

<jpk68:matrix.org> Thanks :)

Btw, this is something I'd like to include in the FCMP++ HF, pending MRL discussion: seraphis-migration/monero #445

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

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

<jeffro256> I want to prevent suffocation by earmarking

At least I want to loosen the rule that forces unlock_time = 0. That can hardly be considered a "big consensus change".

If consensus allows unlock_time = 0 or 1, relative locks can be soft forked later.

<jpk68:matrix.org> 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

If anyone thinks allowing unlock_time = 1 will hold up FCMP++, I want to hear the arguments.

<jeffro256> tevador: Okay, that's fair

<jeffro256> tevador: I don't that will, I was talking about adding in signatures (increasing tx size) and validating them

As I wrote here, I consider only the unlock_time based variant to be feasible to implement in time: monero-project/research-lab #161#issuecomment-5095666180

<boog900> does the FCMP code ignore the unlock_time field?

<jeffro256> It's complicated

<boog900> I know it doesn't for old txs, it delays when txs are added to the tree

<boog900> or at least I think I know :)

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

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

<boog900> oh wait yeah the field is an absolute lock so setting 1 wouldn't matter for that anyway.

<jeffro256> Yes, exactly

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

<jeffro256> *loosen

<jeffro256> AFAIK, any value of unlock_time <= the first v17 block index semantially shouldn't collide with FCMP++.

<jeffro256> There's the question of uniformity still, but it shouldn

<jeffro256> shouldn't "mean" anything to the consenus rule

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

<jeffro256> Because I have feedback related to that

the passphrase isn't required after the wallet is loaded into memory

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

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.

PC stuff beyond the consensus enforcement*

<ack-j:matrix.org> Did randomx v2 have/need another security audit?

<ofrnxmr> Dont think so

<ofrnxmr> (former)

ack-j:matrix.org: the changes were iterative/minimal on existing design github.com/tevador/RandomX/blob/master/doc/design_v2.md

<ack-j:matrix.org> OK