Corrections to BIP-0361 on rescue protocols#2146
Conversation
conduition
commented
Apr 17, 2026
conduition
commented
- 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.
jonatack
added
Proposed BIP modification
Co-authored-by: Jon Atack <jon@atack.com>
| Any proposal that allows for the quantum theft of "lost" bitcoin is creating a redistribution dilemma. There are 3 types of proposals: | ||
|
|
||
| 1. Allow anyone to steal vulnerable coins, benefitting those who reach quantum capability earliest. | ||
| 1. Allow anyone to steal vulnerable coins, benefiting those who reach quantum capability earliest. |
There was a problem hiding this comment.
(It seems both spellings are acceptable, one "t" being more frequent in US English and 2 "t"s more in British English.)
|
ACK |
murchandamus
left a comment
murchandamus
left a comment
There was a problem hiding this comment.
Changes seem reasonable, but acceptance of this PR is subject to the BIP authors’ acceptance.
cc: @jlopp
jlopp
left a comment
jlopp
left a comment
There was a problem hiding this comment.
One minor nit, but otherwise ACK
| '''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. | ||
|
|
||
| '''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. | ||
| '''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. |
There was a problem hiding this comment.
The main issue here is that it loses the nuance that there's probably not a rescue protocol possible for JBOK wallets.
There was a problem hiding this comment.
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
jonatack
removed
the
Pending acceptance
|
Thanks @conduition, @jlopp and @murchandamus. |
| @@ -92,25 +90,20 @@ Coordinating distributed groups is more prone to delay, even if everyone has sim | |||
| | 160,000 blocks (~3 years) after BIP-361 activation. | |||
There was a problem hiding this comment.
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.
5 participants
