<rucknium> Should I put CARROT's Outgoing View Keys (OVKs) on the next MRL meeting agenda?

might be interesting to talk it on terms of Carrot transaction output format (how payments are sent, what is being hardforked); Carrot new addressing mode (Carrot wallet, which is something that can be implemented by wallets on their own and is not being hardforked specifically) which has generate image key, OVK

<jeffro256> @rucknium: Sure, I'll be ready to talk about them

<jeffro256> DataHoarder: Just to be clear, none of CARROT needs to necessarily be part of the FCMP++ hard fork. The additional output type was simply to prevent muddying tx_extra further, but you can include all the data you need without changing the output type by storing it in tx_extra

<jeffro256> In my mind, there are two main components: the addressing protocol (the spec on how to send XMR to each other through addresses), and the wallet format (how to derive keys, and then addresses, and then scan/construct txs using those keys)

<kayabanerve:matrix.org> I've been trying to refer to the HF as FCMP++ + Carrot to acknowledge all of @jeffro256:monero.social: 's work and because FCMP++ alone does not offer all the functionality we now expect with the hard fork. rather, it is one part of a complete private payments protocol, as extensively developed by the Monero project (or I've taken to calling it, BSD/Monero + FCMP++ + Carrot#!+).

<jeffro256> Neither of them are necessarily part of the HF, although if you don't use CARROT, the addressing protocol, you won't be able to send XMR correctly to each other with people that DO use CARROT

Yeah the output format afaik is also inherited from Jamtis (so we don't need to do major changes later) indeed. Called out that hardfork part

<jeffro256> The wallet format isn't integrated into wallet2 yet, but hopefully will be at some point, but it shouldn't be a blocker to the HF.

<kayabanerve:matrix.org> Joke aside, I do actually try to use FCMP++ + Carrot when I say what to expect with the new HF because it is their combination which achieves the advertised features.

<kayabanerve:matrix.org> Which also means we can drop CARROT

<kayabanerve:matrix.org> (I'm indispensable, you can't get rid of me, but we can throw jeffro256 to the wolves anyyyy day now 👀)

I have been calling carrot tx output format and carrot addressing protocol (instead of wallet derivations). That is my mistake

<kayabanerve:matrix.org> Which we shouldn't do lol, it's because of CARROT we plan to fix a lot of legacy issues, achieve such strong privacy, and also offer such functionality, but yes, jeffro is correct when they say it isn't technically necessary to be in this HF.

<kayabanerve:matrix.org> There was a simpler proposal when we started this path to extend the current protocol with an extra derivation to solely gain forward secrecy rather immediately.

<kayabanerve:matrix.org> The reason we've been discussing CARROT is because the current protocol sucks, is a nightmare to reimplement, and has many privacy issues. It also doesn't fully take advantage of what's made possible with FCMP++, even if we did the 'simple low-hanging fruit'

<kayabanerve:matrix.org> Moving from TX extra to static typing should be done as it limits transaction malleability and lets limits on arbitrary data not have a floor of 'legitimate data' (the current wallet data shoved into the arbitrary data field)

<kayabanerve:matrix.org> My issue with ever offering a transparent pool would be the non-uniformity, and how wallets may cop out to the 'simpler' option (harming privacy). This is arguably what's done with public LWS schemes (such as MyMonero was), where users are given software trading privacy for UX.

<kayabanerve:matrix.org> The default option in Monero, and a requirement for anyone who writes software for Monero, should be private.

<kayabanerve:matrix.org> I wouldn't consider offering a transparent pool and a private pool, where even a single wallets has a default (if not sole support for) the transparent pool to achieve that. This level of control shouldn't be given to wallet software.

<kayabanerve:matrix.org> Codifying the wallet protocol more and more on-chain continues to ensure a consistent experience and reduce malleability.

<kayabanerve:matrix.org> So would removing the fee field for solely a fee rate, and discrete fee rates, forcing wallets to accurately calculate weights (in order to accurately calculate fees and create a transaction which balances) and reducing how much any fee rate can be fingerprinted.

<rucknium> @jeffro256: @jeffro256:monero.social: If someone with a non-CARROT-enabled wallet sends coins to a CARROT address, what happens?

<kayabanerve:matrix.org> I personally like the idea of setting the fee rate encoding to a u8, where the literal byte encodes an exponent for a power of two.

<kayabanerve:matrix.org> So a fee rate of 8 would effect 2**8 (256) atomic units of XMR per weight.

<syntheticbird> what were the arguments against fee quantization again?

<kayabanerve:matrix.org> Rucknium: Currently, the addresses themselves are indistinguishable. Presumably, the CARROT user wouldn't be able to scan it (as they wouldn't bother running a redundant scan process), but if they did, they'd lose a variety of the benefits to CARROT regarding privacy and security.

<kayabanerve:matrix.org> (I know I wasn't asked, I just wanted to comment a rough blurb in case jeffro doesn't get back to you for a bit)

<syntheticbird> > Presumably, the CARROT user wouldn't be able to scan it

<syntheticbird> oh my god

<rucknium> The recipient wouldn't see it, so they think they haven't received anything. But they could recover the coins, still, with a workaround. Not good at all for merchants of course.

<jeffro256> This is assuming that people decide not to use the CARROT addressing protocol, which I suspect people only object to because it has the same name as the related wallet format

<jeffro256> The wallet format having OVKs, which i think is the thing they object to

<jeffro256> Some people have so lost the plot they're talking about hardforking to remove CARROT, which is nonsense. But I think they're saying that because a lack of understanding where the actual HF boundary lays, and the boundary between the new wallet format and the new wallet addressing protocol

<rucknium> People didn't have the plot in the first place.

<rucknium> They don't understand the technicalities yet.

<jeffro256> "There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors."

<rucknium> Got a paraphrase of an even older quote: "Live by the paranoia, die by the paranoia."

<syntheticbird> @jeffro256: wonderful quote

<br-m> <kayabanerve:matrix.org> Moving from TX extra to static typing should be done

I'd even go further and make v3 to remove all the cruft from previous, and also maybe let's not rename type 0 to carrot when it had a different decoding before (now you need to know if you are decoding a v2 post fork or pre-fork in the wild for the decoder)

I made a TL;DR overview last night of what people are complaining about and quick ways to go at it in #monero but indeed, people are misunderstanding first how monero works, how it'd also work after FCMP++ and what they call carrot

<kayabanerve:matrix.org> If v3 is so great of a proposal, why has no one proposed a v4?

<kayabanerve:matrix.org> I'd support further improvements as time foes on. The immediate discussion/priority is just reducing usage of extra though.

yeah. I have a .patch that at least removes the old parsers for the unused fields for v2, given we are making changes and they were never used since inception

(if it has an unused field that is invalid in network, it errors parsing early)