<k​ayabanerve:matrix.org> You can't do this at time of the migration TX jeffro256:

<k​ayabanerve:matrix.org> No, it wouldn't, unless we don't migrate those into FCMP++ and restore the hard migration

<k​ayabanerve:matrix.org> No, there isn't, that only holds true for honestly formed outputs

<k​ayabanerve:matrix.org> I can make an output, today, which is 1G+1T and unspendable.

<k​ayabanerve:matrix.org> The moment FCMP++ goes live, it'll be spendable with a key image of 1 H(1G+1T)

<k​ayabanerve:matrix.org> The moment we enable migrations, under your proposal, it'd be given a key image of dlog_G(1G + 1T) H(1G + 1T).

<k​ayabanerve:matrix.org> We'd need to not migrate all current outputs with public amounts into the FCMP++ tree to enable their PQ migration.

<k​ayabanerve:matrix.org> Or you add an assumption that no one made such malicious outputs before a certain date in time, or you add PoKs over G to coinbase outputs now, or you just have anyone with historical outputs move to a new, properly bound, wallet anytime over the next ~five years and don't bother with any of these bad ideas

<s​yntheticbird:monero.social> PoKs?

<k​ayabanerve:matrix.org> That would make coinbase outputs not to an address but to an already-derived non-reusable key and strip their forward secrecy.

<k​ayabanerve:matrix.org> *the PoKs over G for coinbase outputs idea would...

<k​ayabanerve:matrix.org> SyntheticBird: Proofs of knowledge

<k​ayabanerve:matrix.org> There was a similar bug noted during the work on the integration of FCMP++. The originally sketched flow calculated the HtP inserted into the tree after torsion clearing. That'd give a torsioned output a distinct key image generator now/after FCMP++, allowing double spending across protocol versions.

<j​effro256:monero.social> I'm proposing that we do the equality-of-discrete-log input proof EXCLUSIVELY for pre-FCMP++ outputs, and do the properly-bound-wallet-address input proof EXCLUSIVELY for post-FCMP++ outputs. Under this proposal, the people who would get screwed are those who added a non-zero `T` component to their output pubkey *before* the FCMP++ fork AND didn't spent it between the time of FCMP<clipped messag

<j​effro256:monero.social> ++ activation and the PQ migration. This way, the FCMP++ fork is still migrationless, since we can soak everything up into the same pool assuming the hardness of the discrete log. But when it comes time for the PQ migration, spending them requires separated input proofs

<j​effro256:monero.social> All pre-FCMP++ coinbase outputs and all pre-RingCT outputs already have no forward secrecy

<j​effro256:monero.social> Except for that subsection of pre-FCMP++ outputs which preemptively include a `T` component, being okay with not being able to spend, and praying that nothing changes about FCMP++ between then and the time of activation

<j​effro256:monero.social> I don't think we should cater the PQ migration to that small niche IMHO

<j​effro256:monero.social> Especially considering that we know ~9% of the supply is still tied up in unspent pre-RingCT outputs

<k​ayabanerve:matrix.org> No? Because an adversary with a QC can spend during FCMP++ and migrate jeffro256:

<k​ayabanerve:matrix.org> This lets a QC double-spend

<k​ayabanerve:matrix.org> Unless you limit the migration to only when a QC can't break ECC but then they can do a standard EC inputs (full privacy), PQ outputs

<k​ayabanerve:matrix.org> It's only once a QC exists we need to discuss all of this mess, and once a QC exists, a QC can migrate spent outputs under your proposal as you assume historical outputs are xG when that isn't guaranteed

<j​effro256:monero.social> We must assume that we trigger the PQ migration and stop creating any FCMP++ outputs *before* the first feasible quantum computer can break a single discrete log, otherwise all this discussion is useless anyways

<j​effro256:monero.social> Because if there is ever a single discrete log broken while we are still doing partial amount verification (BP+s), then that one output could contain any amount of XMR < 2^64, and a turnstile is largely pointless if it all gets gobbled up by one guy

<j​effro256:monero.social> We can assume some breakage after the PQ migration is activated but we're more or less hosed if we assume any breakage while FCMP++ verification is still in place

<k​ayabanerve:matrix.org> jeffro256: Sorry, we're still talking past each other.

<k​ayabanerve:matrix.org> I'll reach out elsewhere

<j​effro256:monero.social> ^^^^ Ok yes we can't do my fun idea b/c kayaba ruined it with math or whatever

<j​effro256:monero.social> But by the time we have a PQ migration, and aren't assuming hardness of DLP, then there's a good chance that if we let people race to spend pre-RingCT (AKA pre-2018) outputs, it would just end with QC key breakers acquiring and then dumping 9% of the XMR supply

<j​effro256:monero.social> So yeah it might end up being better to just forget about them

<k​ayabanerve:matrix.org> I support only supporting PQ-safe methods after a QC is a sufficient threat to exist, banning spending old outputs entirely. We're discussing roughly five years to be able to migrate to a wallet which has a PQ-safe migration method.

<j​effro256:monero.social> By *old outputs* here, you mean pre-FCMP++?

<k​ayabanerve:matrix.org> No, any EC outputs which don't have the necessary binding to be migratable.

<k​ayabanerve:matrix.org> So it's old by age of wallet, not by time of presence on-chain.

<j​effro256:monero.social> Okay, then yes I agree