bitcoin/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2026-04-20 16:28:39 +00:00
Code Issues Releases Wiki Activity

Fix BIP32 links and consistency

Browse Source 
Co-authored-by: Jon Atack <jon@atack.com>
This commit is contained in:
conduition
2026-04-17 10:44:09 -06:00
committed by GitHub
parent ab2ebe2c5d
commit da7cc678d5
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
bip-0361.mediawiki
View File

@@ -133,7 +133,7 @@ With a clear deadline, industry stakeholders will more readily upgrade existing
The new tighter verification conditions for using ECDSA and Schnorr to spend coins will be designed to rule out quantum attackers, but to permit spends from the authentic coin-holders. Such rescue protocols rely on asymmetry of knowledge between a quantum attacker and the authentic coin-holder. Any context where an asymmetry exists in favor of the authentic holder can theoretically be turned into a rescue protocol. The new tighter verification conditions for using ECDSA and Schnorr to spend coins will be designed to rule out quantum attackers, but to permit spends from the authentic coin-holders. Such rescue protocols rely on asymmetry of knowledge between a quantum attacker and the authentic coin-holder. Any context where an asymmetry exists in favor of the authentic holder can theoretically be turned into a rescue protocol.
For instance, most wallets built since its introduction in 2012 have used [https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP-0032] to construct deterministic HD wallets which derive Bitcoin keypairs from a seed. Any BIP-0032 wallet which uses a hardened derivation step in its key-paths can thus satisfy a rescue protocol which uses BIP32 hardened key derivation to prove knowledge of a parent XPriv which a quantum attacker would be very unlikely to know. [https://groups.google.com/g/bitcoindev/c/Q06piCEJhkI Current research on ZK-STARK-based rescue protocols] suggest proofs could be efficiently scaled, and [https://groups.google.com/g/bitcoindev/c/uUK6py0Yjq0/m/57bQJ3VSCQAJ commit/reveal protocols can likely do so even more efficiently] at the expense of a more challenging multi-step security model. For instance, most wallets built since its introduction in 2012 have used [[bip-0032.mediawiki|BIP-32]] to construct deterministic HD wallets which derive Bitcoin keypairs from a seed. Any BIP-32 wallet which uses a hardened derivation step in its key-paths can thus satisfy a rescue protocol which uses BIP-32 hardened key derivation to prove knowledge of a parent XPriv which a quantum attacker would be very unlikely to know. [https://groups.google.com/g/bitcoindev/c/Q06piCEJhkI Current research on ZK-STARK-based rescue protocols] suggest proofs could be efficiently scaled, and [https://groups.google.com/g/bitcoindev/c/uUK6py0Yjq0/m/57bQJ3VSCQAJ commit/reveal protocols can likely do so even more efficiently] at the expense of a more challenging multi-step security model.
It remains to be seen how much of the legacy Bitcoin supply can be theoretically covered by such rescue protocols. If one or more rescue protocols can be designed to cover the majority of the Bitcoin supply, then restricting ECDSA/Schnorr verification will be at most mildly confiscatory, and will come at little expense to the overall integrity of the Bitcoin network. It remains to be seen how much of the legacy Bitcoin supply can be theoretically covered by such rescue protocols. If one or more rescue protocols can be designed to cover the majority of the Bitcoin supply, then restricting ECDSA/Schnorr verification will be at most mildly confiscatory, and will come at little expense to the overall integrity of the Bitcoin network.