<rbrunner7> Never mind all this PQ stuff, that goes way over my head, but I have some comments about an earlier statement from @jeffro256:monero.social : "Whether or not the core repo should have explicit support for it [ = the Carrot key hierarchy] I guess is another issue."

<rbrunner7> I have a strong opinion regarding this issue: Of course support for that would belong into the "core repo".

<rbrunner7> My reasoning is as follows: Seen over the whole Monero software ecosystem, software development is pretty chaotic IMHO. We don't have a formal voting process about where to go, nobody has some final last word in any matter if a decision cannot be reached in any other way, we have only a bare minimum of what you could call "project management". This is of course both a strength and a weakness.

<rbrunner7> But we do have an instrument that works pretty well, and that is implementing something in the core codebase. Thus, if come to a pretty good "loose consensus" that people should be able to use the Carrot key hierarchy while we all wait for some Jamtis PQ magic, by all means put that into the core code base.

<rbrunner7> If we don't, we risk that it doesn't get a critical mass of wallet apps supporting it, risk that some people "do it wrong", and that some people do something else instead.

<tomdooley:matrix.org> New Monero PoS for Mac:

<tomdooley:matrix.org> x.com/MgkMshrmBrkfst/status/2042541020689371197?s=20

<syntheticbird> wrong channel

<ixr3:matrix.org> Interesting read

<ixr3:matrix.org> Do I understand correctly that a quantum computer could recover the seed from a Monero public address under the current key hierarchy, but not under the new Carrot key hierarchy? > <@jeffro256> So the preconditions for the attack are laid out in the gist:

<ixr3:matrix.org> > <@jeffro256> So if the QA knows Alice and Bob's addresses, then they can link their portions of the traction graph together

<ixr3:matrix.org> I don't like this. A few years ago building transaction graphs and linking transactions was laborious and rarely worth the effort. AI has already made that much faster. Last week Chainalysis released their first AI agent (chainalysis.com/blog/introducing-fi…blockchain-intelligence-agents-2026), which speeds the [... too long, see mrelay.p2pool.observer/e/pt65hvgKeHlFbVM2 ]

<ixr3:matrix.org> This is much better. It's easy to explain to people how to churn if they want to benefit from some QA protections. > <@jeffro256> Unless Alice uses the new key hierarchy listed in the CARROT spec and churns her received enote before sending to Bob

<rbrunner7> @ixr3:matrix.org: "A few years ago building transaction graphs and linking transactions was laborious and rarely worth the effort. AI has already made that much faster. " That transaction graph danger will go away once and for all with FCMP++, which we will definitely hardfork to, whatever we will decide regarding supporting t [... too long, see mrelay.p2pool.observer/e/zrDohvgKUUVLLTdX ]

<ixr3:matrix.org> @rbrunner7: I'm aware, but Jeffro says a QA can still link portions of transactions across different wallets if the public addresses are known?

<syntheticbird> Don't panic. Actual PQ algorithms will be cracked one day and the entire graph will be revealed

<rbrunner7> Unlike AIs, QAs don't exist, and it's unclear when they will. You can worry about all kinds of things in the future, but I am not sure that is healthy.

<ixr3:matrix.org> @ixr3:matrix.org: Post-quantum, Chainalysis could scrape large numbers of addresses from exchanges, peer-to-peer platforms forced to share data, decentralized swappers like Thorchain, and other sources, then try to correlate them. Exchanges are sharing increasingly more information. Who knows what the landscape will look like in the future?

<rbrunner7> Why would that have to be post-quantum? If you want to worry about such a scenario, you can do so very well today.

<syntheticbird> You seems to be under the impression that FCMP++ will be vulnerable to a pseudo-black-marble attack in which if Chainanlysis can reduce the privacy of all the participants of chain by linking two participant together. That is is specifically what FCMP++ has been designed to prevent

<rbrunner7> And you know that exchanges progressively drop XMR all over the world?

<ixr3:matrix.org> @rbrunner7: Today yes. After FCMP++ less

<syntheticbird> so that two participants are linked together by a QA have, no realistically privacy implications for other participants

<syntheticbird> s/if Chainanlysis/Chainanalysis

<ixr3:matrix.org> @rbrunner7: They are many swappers that use the same few exchanges

<rbrunner7> Yes, and the dangers of them doing so will mostly go away with FCMP++. Only the people who swap will put themselves into harm's way, by handing them addresses. Don't be like that, problem mostly solved - for you.

<rbrunner7> By the way, maybe this discussion would be more apt for the "Monero Research Lounge" room.

<rbrunner7> Soon the researchers will come back and talking about stuff that mere mortals like us won't understand :)

<ixr3:matrix.org> > <@koe000:matrix.org> You say this a lot about how other wallets could adopt their own key hierarchies. While technically true, in practice it's very unlikely. What matters and is relevant is core dev planning.

<ixr3:matrix.org> From a developer’s perspective I understand your concern. Adding code to the corebase that needs to be maintained in perpetuity and extra wallet complexity for a “temporary” solution isn’t ideal.

<ixr3:matrix.org> That said, if Jeffro can add the Carrot key hierarchy quickly and it meaningfully increases post‑quantum secrecy without greatly delaying Jamtis‑PQ, I think we should do it. The reasoning is explained in the Moratorium: monero-project/research-lab #131. It's better if Monero is 10 years ahead

<ixr3:matrix.org> [... more lines follow, see mrelay.p2pool.observer/e/zs30h_gKV1N4Y3pT ]

<ixr3:matrix.org> @rbrunner7: Ok