Hi Shinobi, Thanks for raising this item. It's a heavily contentious subject with a lot of misinformation flying around.
Before we even think about rescue protocols like ZKPs, pre-registration, or commit/reveal, it is important to understand what a rescue protocol even does. So let me first define another term: Knowledge Asymmetry. In this context, a knowledge asymmetry (or KA for short) is a witness to a quantum-hard relation that has been committed on-chain before Q-day. In plain words, a KA is some piece of high-entropy information which an honest coin-holder knows, but which a future CRQC will not know and cannot easily compute or guess. Examples of knowledge asymmetries include: - BIP32 parent keys and chain codes (this is what Lalu used in his RISC0 benchmarks) - EC keys hidden behind a hash, e.g. - Hashed address types which haven't been spent from - MuSig peer keys - Taproot internal keys - Pre-registered commitments KA's are distinct from private keys because currently there exists no standardized means to authenticate oneself using these KA's in consensus, and because KA's are not always perfectly private (e.g. hashed public keys). The rescue protocols you cite as examples are all merely different ways to modify consensus so that KA's can be used to rescue coins that don't move onto explicitly quantum-safe addresses in time. - Lalu's ZK-STARK benchmarks show how to authenticate a BIP32 KA using the RISC0 STARK prover, but generally a ZKP can prove any computation, and allows fast verification. - Commit/reveal strategies can prove any KA that can be verified by publishing a witness (e.g. by publishing a preimage and recomputing its hash, in the case of hashed addresses, but it's more general than that). - Pre-registration is a way to create new KA's where they may not already exist (e.g. for exposed-pubkey JBOK wallets), under the assumption we will introduce a way to authenticate those KA's later. Pre-registration is a bit of a red-herring in my view. If a user can pre-register to create a new KA, why not simply move to a quantum-safe address? Or move to any standard BIP32 wallet or hashed address, where known KA's abound? So i will discount pre-registration as a rescue scheme for now because it seems excessively complex and redundant. The other two, ZKPs and commit/reveal, are far more interesting as they let us authenticate existing KA's present on Bitcoin UTXOs, such as BIP32 keys or hashed addresses. Both have their trade-offs. The more relevant fact to consider in regards to your OP is: No matter what tool we use to authenticate KA's, there will exist some UTXOs which have no knowledge asymmetries on Q-day. I suspect Satoshi's coins are chief among them, since they are stored on P2PK addresses generated by Bitcoin Core's old JBOK wallet system. We could theoretically partition the set of all Bitcoin UTXOs into two subsets: Those with KA's, and those without. I like to call these the "recoverable" and "unrecoverable" sets of UTXOs. The unrecoverable set unfortunately cannot be rescued from a QC, no matter what rescue protocol we devise, because there exists no provable mathematical distinction between the honest user and the future CRQC. The only route left there is KYC or "trusted salvage" by a CRQC. For the recoverable set (those with KA's), we can further classify them based on the types of KA available to each UTXO: some UTXOs have multiple KA's. However, these sets all have unknown size and volume because - with the exception of hashed addresses - it's hard to tell at a glance which KA's a particular address has available. This makes it hard to justify what KA's to prioritize authenticating, so we kinda just have to go by dead-reckoning. With this in mind, I would like to correct a few statements in your OP: > However, by layering them, and allowing any single one of them to be used, > complete coverage of any conceivable key generation method can be achieved > for hashed address types. It is still possible to have a UTXO on a hashed address which contains no KA. Consider a paper wallet, generated randomly (not from BIP32), which has already been spent from previously and so has an EC pubkey exposed on chain. Unless a new KA is introduced (by moving coins or pre-registration), no rescue protocol can save this UTXO: it will either be stolen or frozen. > Coverage of non-hashed address types is fundamentally impossible, because the > requirement to allow use of commit-reveal migration would inherently leave > such address types still exposed to a quantum attacker. Not true. P2TR UTXOs can be rescued using internal keys as a KA, which are essentially preimages hidden to the quantum attacker. Pick an internal pubkey `P` with output key `P' = P + H(P) * G`, and give `P'` to the CRQC. Though they can factor `P'`, they cannot guess `P` other than by brute-force (or Grover's search). By default most P2TR software generates the output key with a hidden internal key in this way even if no scripts are present (example), and this is standardized in BIP86 so I believe most P2TR wallets have a KA and so can be rescued. Even if they didn't have an internal key, any P2TR address can use BIP32 as a KA since most P2TR addresses are derived from an HD wallet. The same would apply to any P2PK key generated using hashes, though I think these would be very rare. regards, conduition On Tuesday, July 14th, 2026 at 9:44 AM, 'shinobimonkey' via Bitcoin Development Mailing List <[email protected]> wrote: > Currently the discussion around how to address the potential risk of a viable > quantum computer centers around two primary issues: the quantum-safe > signature schemes (or schemes) to integrate for users to migrate to and use > if need be, and what (if anything) to do about any coins that remain secured > by vulnerable ECC based scripts, specifically should these coins be frozen, > and what mechanisms are available to allow legitimate owners to recover those > coins if possible without an attacker having the ability to do so. > > This second issue is (and always has been) a very socially contentious one, > as the common understanding is it is impossible to guarantee with certainty > that no user is being left in a position where they are incapable of > generating a recovery proof, and therefore are forever prevented from > accessing their coins. > > My motivation for writing this is to solve this contention (at least > partially) in a manner that can hopefully move discussions forward in a > productive direction rather than lead to two opposing plans of action > eventually colliding in the real world with live implementations of > conflicting rules. > > The current solution landscape as it stands to my understanding is: > > > - BIP 32 hierarchical proofs, as proposed a decade or so ago by Adam Back > and recently implemented as a proof-of-concept by roasbeef. > - Non-deterministic stateful proofs constructed and timestamped before a > deadline, showing a vulnerable ECC key signing off on a quantum-safe > authentication mechanism to be used for spending after a post-quantum > spending restriction is activated > - Tim Ruffing/Tadge Dryja's idea (I apologize, but I forget who was the > actual originator of the proposal) of a commit-reveal migration scheme where > a transaction spending vulnerable ECC inputs must have an encrypted > commitment to that exact transaction confirmed in a block with a > pre-determined number of confirmations prior to the decrypted plaintext > transaction's confirmation, or the decrypted transaction is invalid. > > > All three of these proposals leave some subset of coins uncovered. HD proofs > are useless for users who generated their keys any other way than BIP 32, > stateful timestamped proofs are useless for any inactive user or someone who > for any reason does not create them before the creation deadline, and the > commit-reveal migration is useless for anyone with an address type that isn't > hashed because any attacker would have access to the material needed to > create a valid pre-commitment for a spend. > > However, by layering them, and allowing any single one of them to be used, > complete coverage of any conceivable key generation method can be achieved > for hashed address types. Coverage of non-hashed address types is > fundamentally impossible, because the requirement to allow use of > commit-reveal migration would inherently leave such address types still > exposed to a quantum attacker. > > > - Hierarchical proofs cover any BIP 32 user > - Stateful timestamped proofs cover any active/observant non-BIP 32 user > - Commit-reveal covers any non-BIP 32 user who is inactive/not observant > > > The only case in which I can see a restriction of hashed address type spends > using this layered approach of recovery would leave a user unable to recover > their coins is if they have lost access to their private keys. That case is > completely outside of the scope of any of these proposals, and inherently > impossible to cover. > > Shinobi > > Sent with Proton Mail secure email. > > -- > You received this message because you are subscribed to the Google Groups > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/sdGGYMMWowlFff6Yh8usMel61HVYmV8KPMqT9np2kK7GxPbVaogJ2aJSFe4v16VNLef4eDwNgfReiK-7j-sYn1jlXHPoAPWAwNBbSJxEz3M%3D%40protonmail.com. -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/gchRDYHoK2N2rCf0m6qNLWUkR0_rJkO_zL8dvPr7IDCY7FO_iPyzk0hP9L0Y3kwJtvCxnNNc4IkCpNpG5M5Uxa5BR_psT8KR15HtVTeeyQg%3D%40proton.me.
publickey - [email protected] - 0x474891AD.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
