00:03:18 You can't do this at time of the migration TX jeffro256: 00:03:40 No, it wouldn't, unless we don't migrate those into FCMP++ and restore the hard migration 00:04:01 No, there isn't, that only holds true for honestly formed outputs 00:04:19 I can make an output, today, which is 1G+1T and unspendable. 00:04:46 The moment FCMP++ goes live, it'll be spendable with a key image of 1 H(1G+1T) 00:05:19 The moment we enable migrations, under your proposal, it'd be given a key image of dlog_G(1G + 1T) H(1G + 1T). 00:05:56 We'd need to not migrate all current outputs with public amounts into the FCMP++ tree to enable their PQ migration. 00:07:36 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 00:08:30 PoKs? 00:09:22 That would make coinbase outputs not to an address but to an already-derived non-reusable key and strip their forward secrecy. 00:09:38 *the PoKs over G for coinbase outputs idea would... 00:09:50 SyntheticBird: Proofs of knowledge 00:11:21 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. 00:25:23 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 ++ 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 00:26:45 All pre-FCMP++ coinbase outputs and all pre-RingCT outputs already have no forward secrecy 00:29:42 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 00:29:58 I don't think we should cater the PQ migration to that small niche IMHO 00:30:45 Especially considering that we know ~9% of the supply is still tied up in unspent pre-RingCT outputs 00:51:43 No? Because an adversary with a QC can spend during FCMP++ and migrate jeffro256: 00:52:16 This lets a QC double-spend 00:53:15 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 00:54:03 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 01:07:28 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 01:08:34 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 01:09:04 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 03:40:22 jeffro256: Sorry, we're still talking past each other. 03:40:41 I'll reach out elsewhere 05:06:58 ^^^^ Ok yes we can't do my fun idea b/c kayaba ruined it with math or whatever 05:14:05 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 05:16:01 So yeah it might end up being better to just forget about them 05:16:33 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. 05:18:33 By *old outputs* here, you mean pre-FCMP++? 05:20:22 No, any EC outputs which don't have the necessary binding to be migratable. 05:20:40 So it's old by age of wallet, not by time of presence on-chain. 05:22:35 Okay, then yes I agree