> Op 17 mrt 2025, om 13:00 heeft Matt Corallo <[email protected]> het > volgende geschreven: > > I think this is a strong motivation to do "simple PQC" today - while we don't > need to decide on the tough question of seizing non-PQC coins today, we want > to have the option to do so in the future. > > In order for that option to be practical, wallets need to be embedding PQC > public keys in their outputs probably at least a decade before the seizure > occurs, with any additional time giving us an important safety margin.
I don't think that in practice we can deploy a PCQ scheme without at the same time making a decision with regards to burn vs free-for-all. The best we can do is to have all that stuff well researched and tested long before on a signet. Let's say the burn consensus rule is that no pk(), bare multisig, pkh()*, wpkhk() output can be spent, in addition to any tr() key path. To be triggered at some point far enough in the future that people can migrate, but not too late. Let's ignore for now that this will be very hard to agree on, because people will disagree on the nature and timing of the threat until it's undeniable. In principe a PQC (Post-quantum cryptography) tap leaf scheme could be proposed in a BIP and activated in a soft-fork, without having to decide on the burn issue. Any time your wallet needs to generate a new address, it could add such a tap leaf just in case. But this adds a bunch of complexity to wallets, makes descriptor backups longer, etc. So adoption might be minimal. And since no sane person spends from the PQC path, we'd have no idea how much adoption there is. More importantly, the activation of a PQC tapleaf soft fork would not be sufficient to permanently migrate coins. That's because in a free-for-all quantum scenario it's the wrong approach. The quantum attacker would just spend from your key path. In that scenario you'd need to use a NUMS point for the key path. Or maybe that's unsafe, in which case we'd need a new Taproot version without key path support (or BIP360). That's also not a difficult soft fork, but now again you have something that only a small set of users will want to use. This new address type is only suitable for very long term storage since it's more expensive to use in a pre-quantum world (using the a regular Schnorr signature in a script path). So now we'd have two soft forks that ~nobody uses, because it's a bunch of extra wallet complexity and you don't know if you should use the tapleaf or the taproot-without-keypath address for your cold storage. I doubt that soft forks which nobody intends to use will be activated anytime soon. - Sjors --- * See appendix B of BIP380 for notation: https://github.com/bitcoin/bips/blob/master/bip-0380.mediawiki#appendix-b-index-of-script-expressions Since we don't know which public keys are reused, the pkh() underlying public key can be brute force guessed by trying all known keys. There is also no alternative spending path. So it should be included in the burn. sh() and wsh() would not be frozen. Some scripts may be guessable from context, but imo that doesn't outweigh the possibly that someone designed a quantum proof script - even a bad one. Neither would any scriptPubKey that's different from the above standard templates. This allows implementing the freeze rule in a way that doesn't require deep / complicated inspection of the script -- 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/ED96C777-5BBD-4ACE-8821-A53FDE8FA128%40sprovoost.nl.
