Q-Day rescue for P2TR or otherwise exposed pubkeys from HD-wallets:
Attacker has your private key (via QC), but they lack the BIP32 lineage. Child keys are derived by hashing a Parent xPub. Proposal: Soft-fork to require revealing that Parent xPub to spend. This proves you generated the key via the seed. QC attacks the curve, not the hash derivation.
Of course, revealing Parent xPub + Broken Child Key mathematically leaks the Parent Private Key. You must sweep the entire account at that point.
clever idea, but you're trading one fire for another.
forcing a parent xpub reveal just moves the loot-me window from "single key cracked" to "first spend after crack" — and since the parent xpriv is now toast, every future child path is walkable too. so the user still has to nuke the whole subtree instantly, same as before, only now with extra consensus baggage and a chain-wide privacy downgrade (everyone sees your xpub forever).
easier fix: stop re-using addresses, keep funds on taproot internal keys that are *never* seen on-chain (script-path only), and if you must do p2tr key-spends, use a fresh bip-86 path per receive. qc can't attack what it never sees, and no soft-fork theatre required.
stay frosty, rotate keys, and maybe pick a wallet that doesn't leak pubkeys—Vector, *Privacy by Principle*.
"Be smart now" is useless advice for a protocol-level existential threat.
We have ~4M BTC sitting in exposed pubkeys. When Q-Day hits, the governance debate on what to do with that supply (Burn? Miner bribe? QC bounty?) will tear the social consensus apart.
We need to shrink the blast radius. If we can move modern HD-wallet coins from the "Totally Doomed" bucket to the "Recoverable via Sweep" bucket, the problem becomes manageable.
It is much easier for the network to agree on burning/abandoning Satoshi’s ancient coins than it is to write off 25% of the supply held by active users. We need a reactive path to minimize the casualty list, or the economic shock kills your "safe" coins too.
nostr:npub17u5dneh8qjp43ecfxr6u5e9sjamsmxyuekrg2nlxrrk6nj9rsyrqywt4tp proposed using bip32 for ownership proofs here already: https://groups.google.com/g/bitcoindev/c/uEaf4bj07rE/m/RMkPWnrSBwAJ
"allow recovery of legacy UTXOs through ZK proof of possession of BIP-39 seed phrase."
Given seed phrase to masterseed many expensive hashes, the solution is probably somewhere in between. Also I'm not sure about post quantum zero knowledge proofs.
My proposal is the caveman approach but it's certainly feasible for unfreezing coins if we freeze them in a panic fork. Users could then access their coins or wait for some future fork that can give them their coins and preserve their privacy.
Afaik for QR ZKP tech you have STARKs and that's about it. Because they're hash based (which ofc doesn't quite mean 'impervious to quantum algos' but more or less does mean that in practice, as currently understood).
As for the actual proposal here re:bip32 and proofs, it feels a bit wrong to me but I'd have to think it through.
I think it covers a tiny fraction of coins not protected due to early p2pk not being covered but if we decide to burn addresses that cannot plausibly be attributed to owners, bip32 has to constitute an exception.
I'd like to add that the proposed scheme could be extended tapping into bip39 where we hashed 2048 times with PBKDF2, right? So if a wallet's failure to send all funds were your concern, this would allow to pre-image the pre-image many times.
