<r​ucknium:monero.social> MRL meeting in this room in two hours

<0​xfffc:monero.social> My apologies in advance. I will be late for the meeting. I have few minor updates. I finished the sync-before-verify PR. But eventually decided ( with boog ) to not move forward with it. If anyone else wants can take a look at it [1]. Instead of it, we decided to move forward with a PR that checks hardfork and verify only if necessary [2].

<0​xfffc:monero.social> Other than these, I have started to work on the issue boog explained here [3]. The gist is to send txis only if it is necessary and peers asks.

<0​xfffc:monero.social> 1. spackle-xmr/monero #13#issuecomment-2234543784

<0​xfffc:monero.social> 2. monero-project/monero #9404

<0​xfffc:monero.social> 3. monero-project/monero #9334

<r​ucknium:monero.social> Meeting time! monero-project/meta #1044

<r​ucknium:monero.social> 1) Greetings

Hello

<j​berman:monero.social> *waves*

<j​effro256:monero.social> howdy

<o​ne-horse-wagon:monero.social> Hello!

<r​ucknium:monero.social> 2) Updates. What is everyone working on?

<c​haser:monero.social> hello

<j​berman:monero.social> me: finishing up initial migration of cryptonote outputs into the curve trees merkle tree for fcmp's + growing the tree as the node syncs, and cleaning up the grow_tree + trim_tree impl as I go

<r​ucknium:monero.social> me: Reading many papers on gossip protocols and network topology. I am writing comments to these two PRs: "tx_memory_pool: make double spends a no-drop offense" monero-project/monero #9218 "Fix embargo timeout in dandelion++" monero-project/monero #9295

<j​effro256:monero.social> me: drafting a distilled document for the the new addressing protocol for legacy addresses for formal auditing (hopefully). will talk more about it later in the meeting...

<r​ucknium:monero.social> 3) Stress testing monerod monero-project/monero #9348

<j​effro256:monero.social> anything interesting break this week? ;)

<r​ucknium:monero.social> AFAIK, no new incidents on stressnet. There is discussion in #monero-stressnet:monero.social ( ##monero-stressnet on IRC) about how long stressnet should continue and how.

<r​ucknium:monero.social> The original plan was to run it for two months (which would end about August 10th), but it could be extended if it is helpful for development.

<r​ucknium:monero.social> and/or the stressnet could be restarted when FCMP++ are ready to test

As you explained, Rucknium, actually stressing amounts to quite some work, right?

<o​ne-horse-wagon:monero.social> Has there been any actionable results from the stress testing so far that could be taken in the Monero codebase?

<j​effro256:monero.social> monero-project/monero #9404 monero-project/monero #9395

Yes. An astonishingly high number, if you ask me.

<r​ucknium:monero.social> Many community volunteers are running stressnet nodes. About 40 nodes at the beginning. Now about 25. They were told at the beginning that it would run for about 2 months and the blockchain would grow to about 50GB. It is 50GB now.

<j​effro256:monero.social> monero-project/monero #9388

<j​berman:monero.social> +1, it's definitely been valuable

<v​tnerd:monero.social> Hi, sorry for being late

<o​ne-horse-wagon:monero.social> I've asked this question before. Does it help the stress net to do some mining on it? I do it and it seems like I'm almost the only one.

<r​ucknium:monero.social> one-horse-wagon: Yes because it creates network conditions to test re-org/orphan block behavior

<r​ucknium:monero.social> But not at a high hash rate

<r​ucknium:monero.social> Actually we wouldn't have found the invalid blocks issue without multiple nodes mining AFAIK

<o​ne-horse-wagon:monero.social> Gotcha. I've toned it down a lot but the coins still come flying in.

<r​ucknium:monero.social> If you have lots of mined coins that you don't plan to spam, it is good to send them to the wallets of people who are spamming so we can use the coins for tx fees. I think that's just spackle and me.

<o​ne-horse-wagon:monero.social> Rucknium: Post your wallet address and I'll send you a few thousand.

<j​effro256:monero.social> Do you know of anyone that has used p2pool to mine on the stressnet? Might produce interesting results

<r​ucknium:monero.social> jeffro256: AFAIK, p2pool is not set up on stressnet. Yes, could be interesting if someone wants to set it up.

<r​ucknium:monero.social> AFAIK, the p2pool could merge-mine with Monero mainnet now. Or at least I think that change enabling that is in a PR somewhere.

<r​ucknium:monero.social> 4) Research Pre-Seraphis Full-Chain Membership Proofs. getmonero.org/2024/04/27/fcmps.html

<r​ucknium:monero.social> kayabanerve , kayabanerve : Anything on FCMP for this meeting?

<r​ucknium:monero.social> Or anyone else have something about FCMP?

<r​ucknium:monero.social> 5) Auditing the math of the new addressing protocol for legacy addresses. ( jeffro256 's item)

<j​effro256:monero.social> I would like to have the new addressing protocol, which I call Carrot (Cryptonote Address on Rerandomiable-RingCT-Output Transactions), deployed alonsgide the initial deployment of FCMP++ for two main reasons: 1) so we can actually leverage FCMP++'s forward secrecy and outgoing view key properties ASAP, and 2) once Jamtis is ready for deployment, there will be a smooth transition <clipped messag

<j​effro256:monero.social> without transaction fingerprinting issues. However, I don't want the Carrot integration to slow down FCMP++, so I would like to get it audited as soon as possible. I have written almost all of the code we need to deploy Carrot (there are still kinks with payment IDs to be worked out soon), so that should not be a limiting factor. The limiting factor will probably be auditing the m<clipped messag

<j​effro256:monero.social> ath and code. To this end, I have begun to draft a document that outlines all the details for the Carrot, distilled from @tevador's Jamtis-RCT gist. After this is done, I want to propose that it gets audited with funding from the CCS. This should be a relatively straight forward audit, and I don't forsee any issues. After that, then the code auditing can begin. Luckily, FCMPs and <clipped messag

<j​effro256:monero.social> Carrot mainly touch separate parts of the transaction (inputs and outputs, respectively), so development and integration can be parallelized nicely.

<j​effro256:monero.social> I discussed this earlier in the week in the NWLB meeting

<j​berman:monero.social> fcmp implementation timeline still on pace. I think within 3-4 months it'll be ready for stressnet

Viewed from the outside, a fork to FCMPs without anything Jamtis in it does look like quite a wasted chance, IMHO.

So in a timeframe of 3 to 4 months there could be room for it, yes?

<j​effro256:monero.social> Well the new addressing protocol is not technically Jamtis, but is backwards compatible with existing addresses but obtains nice properties such as forward secrecy, OVKs, and Janus protection

<j​effro256:monero.social> jberman: tx output construction code for Carrot is basically done, scanning code is basically done, if audits go smoothly (which they should), then the only task remaining is to integrate with wallet2, which with your async wallet scanning code we were already planning to do

Ah, yes, I did not read all. So able to separate.

<j​effro256:monero.social> Carrot would also be indistinguishable from Jamtis on-chain, so we can switch to Jamtis easily with no loss of privacy in our own time

<j​berman:monero.social> I have no issue with pushing it forward in parallel. Once fcmp's are done we can see where jamtis-rct is at and decide at that point what the best rollout strategy is

<j​berman:monero.social> so +1 from me pushing auditing forwards

"Jamtis" brings, in addition, new long addresses, which means wallet changes?

<j​effro256:monero.social> rbrunner7: IMO you're right it *would* be a wasted chance if we didn't do *Carrot* because then we don't fully leverage the FCMP features

i.e. wallet UI changes, which could be quite heavy, and might derail the time line

<j​effro256:monero.social> Yes IMO the biggest issue with Jamtis is the friction of updating addresses. Carrot doesn't have that problem which should speed up adoption

Does anything change for hardware wallets with Carrot? Maybe things change anyway because of FCMPs?

With or without Carrot, I mean

<j​berman:monero.social> "transaction fingerprinting issues" -> can you elaborate on the fingerprints?

<j​effro256:monero.social> Yes HWs will have to update for FCMPs anyway on the input / spendkey side of things. For Carrot specifically, the HWs dont have to change *too* much. The ECDH key derivation is exactly the same

<j​effro256:monero.social> Depending on if the HW supports OVKs, the key image derivation might have to change

Thanks. So they will have to move anyway, not a strong argument against Carrot early.

<j​effro256:monero.social> jberman: 3-byte view tags, encrypted address tags / carrot randomness, and X25519 epehemeral pubkeys are not present in the current Cryptonote address protocol

<j​effro256:monero.social> Onetime addresses, amount commitments, and encrypted amounts will look the same to external observers, though

<j​berman:monero.social> "That means wallets can send payments to both new and old addresses and the resulting transactions will be indistinguishable in the blockchain" -> when sending to an old address, would dummy values go on chain?

<j​effro256:monero.social> They aren't really "dummy" tx values in Carrot since all tx elements from Jamtis are used someway or another. For example, the X25519 ephemeral pubkeys are just the the new way to encode analogues of the "main"/"additional" tx pubkeys

<j​berman:monero.social> I see in section 6.7, looks like it takes care of eliminating the fingerprints no?

<j​effro256:monero.social> The place that *would* be used for Jamtis encrypted address tags is used to encode a "randomness" in carrot used to rederive the ephemeral private key to mitigate Janus attacks

<j​effro256:monero.social> Yes, I don't think there's a section explicitly mentioning fingerprinting issues, but that was part of the design

You mean attention was given, while designing things, to avoid such fingerprinting issues?

<j​effro256:monero.social> Yes

Alright. We have to implement this almost for the catchy name alone :)

<j​berman:monero.social> so ultimately whenever jamtis-rct rolls out, and network consensus requires txs to spec, then we won't have fingerprinting issues, no? I'm trying to see why rolling out with fcmp's avoids fingerprinting issues

<j​effro256:monero.social> Okay good question. Scenario 1) we stick with the old cryptonote addressing protocol with FCMP++ rollout and then try to switch to Carrot and Jamtis later. Scenario 2) we rollout with Carrot initially with FCMP++ then support Jamtis later. In scenario 1, there will be instantly noticeable difference between old Cryptonote address txs and Carrot/Jamtis transactions which splits the<clipped messag

<j​effro256:monero.social> network into 2 anonymity pools

<j​effro256:monero.social> With scenario 2, whenever we switch to Jamtis, there is no difference between Jamtis and Carrot transactions; All post FCMP++ txs look the same

<j​effro256:monero.social> That's why I would like to rollout Carrot with FCMP++: to avoid the fingerprinting issues that come with supporting the new Jamtis address types

<k​ayabanerve:matrix.org> Apologies

<j​berman:monero.social> In scenario 1, I figure a hard frok to switch to Carrot/Jamtis is expected to require all txs be to spec, like the switch to requiring view tags at consensus

<j​effro256:monero.social> A switch to Carrot/Jamtis need not be a hardfork

<k​ayabanerve:matrix.org> I'm very interested in Carrot explicitly for F-S.

But only if we already have Carrot, I guess?

I.e. later adding Jamtis to the mix does not need a new hardfork

<j​berman:monero.social> Scenario 2 includes consensus rules that require e.g. 3 byte view tags etc., no?

<j​effro256:monero.social> Nope, we don't need Carrot even to start that addressing protocol since they can just put the scanning data in tx_extra

<j​effro256:monero.social> jberman: what I did initally for testing was put the first byte of the view tag in the `tx_out` and the other 2 in tx_extra

<j​effro256:monero.social> No hardfork needed

It's all a bit confusing. Maybe lay it out all carefully in your document, and then people can study and try to understand.

<j​berman:monero.social> but then you'll have 2 anon pools, txs that include that extra data in extra and the ones that don't

<j​effro256:monero.social> jberman: this is the situation that I'm trying to avoid but having Carrot roll out initially *with the upcoming hardfork*

<j​effro256:monero.social> *by having

Anyway, right now for me it sounds as if going for Carrot is worthwhile even if it should not having to do anything with avoiding fingerprinting

Also known as a "no brainer" if that opinion has merit

<j​effro256:monero.social> Ideally, since everyone is updating for FCMPs mandatorily anyways, they also receive the Carrot updates and all post-FCMP++ txs use Carrot (or Jamtis since we can't tell as an external observer)

<j​berman:monero.social> to achieve the goal of indistinguishable txs I figure we'd want consensus to enforce the new tx format / not use extra

Certainly

<j​effro256:monero.social> I disagree to a certain extent. I think view tags shouldn't be inside the `tx_out` structs and should be hoisted to `tx_extra`. Then there should be relay rules which dictate the contents of `tx_extra` to reduce fingerprinting

Sounds strange.

<j​effro256:monero.social> As we've discussed before though, there's not much we can do to stop people from *purposefully* screwing up their fingerprint in txs. However, we *can* prevent accidental mistakes

<j​effro256:monero.social> (or people putting large blobs in tx_extra)

<j​effro256:monero.social> (or other actively so far off from normal that trivial heuristics catches it)

<j​effro256:monero.social> *activity

<k​ayabanerve:matrix.org> The consensus rule of FCMP++s already enables: if fcmp++, xyz, with a hard boundary.

Maybe that's stuff for another meeting, or a discussion after the meeting proper, but a solid argument pro view tags in tx_extra would surprise me

<k​ayabanerve:matrix.org> I disagree we need additional consensus rules.

<k​ayabanerve:matrix.org> I'm unsure I'm for TX v3 at this time though.

Is there something to fear from a new tx version?

<k​ayabanerve:matrix.org> (or any deep structural changes with the fcmp++ fork)

Not sure a component or two more in a tx are already "deep structural changes" ...

Maybe I underestimate?

<j​effro256:monero.social> rbrunner: a new tx version means extra technical debt and requiring a hard fork which adds even more friction to Monero adoption IMO

That tx_extra would't process itself alone either

<j​effro256:monero.social> It's justified for FCMP++ IMO b/c if the privacy benefits

I think now you lost me :)

<j​berman:monero.social> MyMonero is an example of a wallet that uses a pretty heavily modified version of the monero core code to construct txs. I can pretty easily imagine they only end up implementing fcmp++'s and not the other changes necessary for Carrot

Anyway, probably not that important

<k​ayabanerve:matrix.org> TX extra is entirety out if consensus so it would in fact process itself

<k​ayabanerve:matrix.org> jberman: If a TX is FCMP++, just only scan per Carrot.

<k​ayabanerve:matrix.org> MyMonero can legacy send but it'd effectively be a custom protocol and their failure.

<j​berman:monero.social> I guess if relay rules enforce the Carrot changes, then that changes things. Would have to introduce relay rules that parse tx extra etc., which I would argue is more complex than new explicit types

Maybe MyMonero throws in the towel, who knows. Will get interesting.

more like they use the libs others will release

<k​ayabanerve:matrix.org> *I do know wallets would need updating. Updating wallets is simpler to also updating the output definitions :/ IIRC they're unversioned and not an enum.

<j​effro256:monero.social> jberman: Yes I agree that this in an issue. Could be worth discussing relay rules to at least combat fingerprinting. Really, let's say you're a lazy dev and don't care if your users get F-S, Janus protection, or OVKs with Carrot. You can add dummy encrypted address tags and view tags. The only real cryptographic code that you need to implement is the functions converting points fr<clipped messag

<j​effro256:monero.social> om X25519 to Ed25519 and vice versa

<j​effro256:monero.social> So even for the laziest wallet devs, you only really need `CovertPubkey1`, `CovertPubkey2`, and `NormalizeX` functions from Jamtis-RCT

<k​ayabanerve:matrix.org> jberman: We don't need relay rules if we just don't scan TXs with legacy extra.

I really think we shouldn't even explain to lazy devs how to be maximally lazy :)

And get away with it.

<k​ayabanerve:matrix.org> As jeffro says, there's ways to cheat implementing Carrot and one can do so. Relay rules/strict typing wouldn't catch that.

<j​berman:monero.social> ya, fair arguments

<k​ayabanerve:matrix.org> But if we only scan Carrot, it does mandate sending as Carrot.

And everybody will still find all transactions?

<k​ayabanerve:matrix.org> No relay rules needed.

<j​berman:monero.social> I mean they have to change scanning on their end too

<k​ayabanerve:matrix.org> FCMP++ TXs would have a distinct scan procedure (Carrot). All prior TXs would be fine.

If somebody can just put in any old random data, I don't see how that would work out for everybody overall.

For things they don't feel like implementing

Maybe it is so, but somehow does not sound right

<k​ayabanerve:matrix.org> That's presumably always a risk, yet wallet2 would handle it. The concern is completely custom impls aiui

<j​berman:monero.social> Carrot scanning is distinct code from FCMP++ scanning

<k​ayabanerve:matrix.org> Wat

so make custom impls. everyone will adapt

<k​ayabanerve:matrix.org> What's FCMP++ scanning in your context?

myMonero doesn't even really have a scale advantage

so it's not worth worrying about whether or not they're going to be able to scale their implementation

<k​ayabanerve:matrix.org> Outputs are versioned, my bad, sorry. I drop my strict typing concerns.

that's very kind of you guys to worry about someone who scammed the entire community though

lol

<j​berman:monero.social> it's not worrying about them necessarily, it's about what goes on the chain / maximizing the anon set

<k​ayabanerve:matrix.org> Ignoring that, if we do change Carrot, I do think we need multiple months of the finalized spec *and a full d/wallet-rpc* available.

<j​effro256:monero.social> Agreed

<s​yntheticbird:monero.social> multiple months ? more than 3-4 months ?

<j​effro256:monero.social> Which is why it's nice that the code is mainly done

*smile*

<k​ayabanerve:matrix.org> I'm not asking the final FCMP++ + Carrot (FCMP+++? FCMP#?) bins be available for three months (I'm unsure HF timelines). I'm asking the Carrot spec and bin be available for four.

<j​effro256:monero.social> I will try to work out a first draft the formal doc by next MRL meeting if y'all think its a good idea

<j​berman:monero.social> fcmp++ scanning for full wallets = keeping full paths in the tree saved locally, light wallet fcmp++ scanning = nothing really for legacy

<k​ayabanerve:matrix.org> SyntheticBird: if it's public for one month, and I take a month to implement, the new monero-serai is available for 0 days prior to fork.

<k​ayabanerve:matrix.org> I need to impl it, test it, have it audited, and release with my own distance to the fork.

<k​ayabanerve:matrix.org> I can do that once I have a final spec and ref impl (even if unaudited with potential slight changes upcoming) but I do need that.

So, to put it a bit bluntly, with Serai you have one of those "custom implementations" on your hand

<k​ayabanerve:matrix.org> jberman: I'd more call that tree management and think it's fine to say scanning an output, determining if you can spend it, would be Carrot for all FCMP++ TXs. We wouldn't even attempt the legacy scan protocol. I hear you if you want to note the FCMP++ pipeline re: scanning is more involved though.

Is the goal a public release of Serai together with the FCMP++ hardfork?

<k​ayabanerve:matrix.org> rbrunner: and downstream consumers :D People like my work :D

Yes, yes :)

<k​ayabanerve:matrix.org> But yes, and I do plan to follow the specification properly.

<j​effro256:monero.social> jberman: TBF the light wallet servers themselves have to do the FCMP changes to the wallet. Most of the time the development of the LW clients and LWS is tightly couple / done by the same people

I just only now understand that yet one more ball is up in the air that may complicate things then

<k​ayabanerve:matrix.org> I wouldn't shim it unless there was no other way to do it in a sufficiently timely fashion.

<j​berman:monero.social> actually ... ! ... light wallet servers should do the same thing as full wallets when scanning, no? at least for legacy. I don't think light wallet impls need decoy paths at all. light wallet servers just keep full paths saved for all received outputs

<j​berman:monero.social> (sorry slightly off topic)

<k​ayabanerve:matrix.org> Re: timeline, that hasn't been the plan prior. I think Serai may beat FCMP++s.

If no Carrot derails the poor thing :)

<j​berman:monero.social> anyway yes, I'm noting that tree management is distinct code necessary to scan for fcmp++'s, compared to code necessary for Carrot scanning

<j​effro256:monero.social> jberman: true yeah as long as the LWS has access to a *trusted* daemon they can just trivially store paths in a databse yeah?

<j​berman:monero.social> all this to say, Carrot isn't a trivial amount of code on top of fcmp++'s. all the more reason to make progress on it asap, but I'm still pretty iffy on rolling it out with fcmp++'s

<k​ayabanerve:matrix.org> I'd rather just do burning bug + F-S.

<k​ayabanerve:matrix.org> I'm not against Carrot if it's made accessible to review, implement, and test by devs not working on FCMP++ but I do share the concerns.

<j​effro256:monero.social> AFAIK almost all full wallets in use *today* use `wallet2` for tx construction, correct?

<j​berman:monero.social> afaik yep

<j​effro256:monero.social> So it's mainly light wallet codebases that would need explicit updating?

<k​ayabanerve:matrix.org> I'm right here :(

<j​berman:monero.social> sending to the new addresses will probably require some trivial changes too

<k​ayabanerve:matrix.org> My codebase would need explicit updating :(

<j​effro256:monero.social> I know I know !! lol

<j​effro256:monero.social> Not to exclude kayaba....

<j​effro256:monero.social> I was just trying to think of other more obscure wallets

<j​effro256:monero.social> That don't use `wallet2`

<k​ayabanerve:matrix.org> Ledger has on-device scanning

<k​ayabanerve:matrix.org> Trezor has a python reimpl of sending

<j​berman:monero.social> also UI changes for handling the new addresses. e.g. let's say no UI changes are made, then you recover a seed that has received to a new address

<j​effro256:monero.social> Wdym by "new addresses" here? Jamtis or regenerated Cryptonote-style addresses?

<j​effro256:monero.social> Sending is exactly the same for old/new Cryptonote addresses

<j​berman:monero.social> true trezor reimplemented wallet2, forgot that

<j​effro256:monero.social> Scanning is slightly different if you use a new address with OVKs

<j​berman:monero.social> Jamtis generated addresses = new addresses

<j​berman:monero.social> I'm thinking I will await your spec and think on it more then

<j​effro256:monero.social> For Jamtis addresses, weren't we going to use a different seed format anyways (Polyseed)?

<j​effro256:monero.social> That would signal to the wallet which type of scanning to do

<j​effro256:monero.social> But Trezor / Ledger DO have their own seed formats...

<j​berman:monero.social> Feather and Cake (not sure of others in production) support polyseed today

<j​effro256:monero.social> I did not know that. That makes the UI problems hairier

<j​effro256:monero.social> Is there not a "Jamtis" flag bit in the Polyseed specs?

<j​berman:monero.social> probably would make sense for there to be one

<j​effro256:monero.social> Okay just looked I don't think it's in there explicitly, maybe tevadoe mentioned it at some point... this is probably a good application for those feature bits

<j​effro256:monero.social> As long as we make sure production wallets today aren't already using them for vendor specific things

<j​effro256:monero.social> BTW thanks everyone for all the helpful input!