Corrections to BIP-0361 on rescue protocols #2146

conduition commented at 3:26 PM on April 17, 2026: contributor

Merge phase B and C. They cannot be deployed independently without a hard-fork.
Clarify phase B should not lock EC spending, but instead should tighten verification conditions, so as to still allow rescue using commit/reveal or STARK protocols (design left unspecified)
Elaborate on future options for rescue protocols and current research directions.
Some whitespace trimming which my editor applied automatically.

Corrections to BIP-0361 on rescue protocols ab2ebe2c5d

jonatack added the label Proposed BIP modification on Apr 17, 2026

jonatack added the label Pending acceptance on Apr 17, 2026

in bip-0361.mediawiki:136 in ab2ebe2c5d

 136 |  '''Minimizes loss of access to funds '''
 137 |  
 138 | -Submitting a zero knowledge proof of possession of a BIP-39 seed phrase corresponding to a public key hash or script hash would provide a trustless means for legacy outputs to be spent in a quantum resistant manner, even after the sunset.
 139 | +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.
 140 | +
 141 | +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.

jonatack commented at 4:11 PM on April 17, 2026:

Suggested link and consistency touch-ups.

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.

jonatack commented at 4:15 PM on April 17, 2026: member

LGTM, pending approval by BIP author(s) @jlopp et al.

Fix BIP32 links and consistency

Co-authored-by: Jon Atack <jon@atack.com>

da7cc678d5

in bip-0361.mediawiki:118 in da7cc678d5

 114 | @@ -122,25 +115,29 @@ To date, no quantum related proposal provides protection against:
 115 |  
 116 |  Any proposal that allows for the quantum theft of "lost" bitcoin is creating a redistribution dilemma. There are 3 types of proposals:
 117 |  
 118 | -1. Allow anyone to steal vulnerable coins, benefitting those who reach quantum capability earliest.
 119 | +1. Allow anyone to steal vulnerable coins, benefiting those who reach quantum capability earliest.

jonatack commented at 5:38 PM on April 17, 2026:

(It seems both spellings are acceptable, one "t" being more frequent in US English and 2 "t"s more in British English.)

jonatack commented at 5:39 PM on April 17, 2026: member

ACK

murchandamus commented at 6:02 PM on April 17, 2026: member

Changes seem reasonable, but acceptance of this PR is subject to the BIP authors’ acceptance.

cc: @jlopp

in bip-0361.mediawiki:26 in da7cc678d5

  22 | @@ -23,17 +23,15 @@ This proposal follows the implementation of any post-quantum (PQ) output type an
  23 |  
  24 |  '''Phase A''': Disallows sending of any funds to quantum-vulnerable addresses, hastening the adoption of PQ address types.
  25 |  
  26 | -'''Phase B''': Renders ECDSA/Schnorr spends invalid, preventing all spending of funds in quantum-vulnerable UTXOs. This is triggered by a well-publicized flag-day five years after activation.
  27 | -
  28 | -'''Phase C''' (TBD): Pending further research, a separate BIP proposing a method to allow quantum safe recovery of legacy UTXOs, likely via zero knowledge proof of possession of a corresponding BIP-39 seed phrase.  
  29 | +'''Phase B''': Restricts ECDSA/Schnorr spends by encumbering them with a quantum-safe rescue protocol, preventing theft of funds in quantum-vulnerable UTXOs. This is triggered by a well-publicized flag-day five years after activation.

jlopp commented at 8:53 AM on April 19, 2026:

The main issue here is that it loses the nuance that there's probably not a rescue protocol possible for JBOK wallets.

conduition commented at 4:37 PM on April 19, 2026:

Actually, JBOK wallets can be rescued provided they have not exposed their EC pubkeys.

https://delvingbitcoin.org/t/pq-provers-for-p2pkh-outputs/2287

There is a lot of subtlety to address in this question of what is and isn't quantum-rescuable, so i left this purposely vague

jlopp commented at 8:56 AM on April 19, 2026: contributor

One minor nit, but otherwise ACK

jonatack removed the label Pending acceptance on Apr 20, 2026

jonatack merged this on Apr 20, 2026

jonatack closed this on Apr 20, 2026

jonatack commented at 2:50 PM on April 20, 2026: member

Thanks @conduition, @jlopp and @murchandamus.

in bip-0361.mediawiki:90 in da7cc678d5

  89 | @@ -92,25 +90,20 @@ Coordinating distributed groups is more prone to delay, even if everyone has sim
  90 |  | 160,000 blocks (~3 years) after BIP-361 activation.

hayashi1225 commented at 7:38 AM on April 23, 2026:

I believe we should take advancement of quantum computer into account. e.g. "[demonstration of a fault-tolerant machine with more than 100(*) logical qubits & 3 months after BIP-361 activation] or [3 years after BIP-361 activation], whichever is earlier."

This proposal cannot be indifferent from advancement of quantum computer. If quantum computer is advancing faster, we need to accept shorter time frame. (*) As we know 1,000 logical qubit (with enough low logical error rate) era is a dead zone, 100 logical qubit era could already be a danger zone. Some of this BIP's co-authors should have better knowledge on this line.