Skip to content

Commit ac52ed0

Browse files
committed
address feedback
1 parent efcdddb commit ac52ed0

1 file changed

Lines changed: 15 additions & 43 deletions

File tree

bip-0361.mediawiki

Lines changed: 15 additions & 43 deletions
Original file line numberDiff line numberDiff line change
@@ -19,13 +19,13 @@
1919

2020
=== Abstract ===
2121

22-
This proposal follows the implementation of a post-quantum (PQ) output type and introduces a pre-announced sunset of legacy ECDSA/Schnorr signatures. It turns quantum security into a private incentive: fail to upgrade and you will certainly lose access to your funds, creating a certainty where none previously existed.
22+
This proposal follows the implementation of any post-quantum (PQ) output type and introduces a pre-announced sunset of legacy ECDSA/Schnorr signatures. It turns quantum security into a private incentive: fail to upgrade and you will encounter additional friction to access your funds, creating a certainty where none previously existed.
2323

2424
'''Phase A''': Disallows sending of any funds to quantum-vulnerable addresses, hastening the adoption of PQ address types.
2525

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 roughly five years after activation.
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.
2727

28-
'''Phase C''' (optional): Pending further research and demand, a separate BIP proposing a method to allow quantum safe recovery of legacy UTXOs, potentially via ZK proof of possession of a corresponding BIP-39 seed phrase.
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.
2929

3030
=== Copyright ===
3131

@@ -45,7 +45,7 @@ The safety envelope is shrinking by dramatic increases in algorithms even if the
4545

4646
'''Bitcoin's exposed public keys.'''
4747

48-
Roughly 25% of all bitcoin have revealed a public key on-chain; those UTXOs could be stolen with sufficient quantum power.
48+
As of March 1, 2026, over 34% of all bitcoin have revealed a public key on-chain; those UTXOs could be stolen by an attacker with a sufficiently powerful quantum computer.
4949

5050
'''We may not know the attack is underway.'''
5151

@@ -108,9 +108,17 @@ Even if Bitcoin is not a primary initial target of a cryptographically relevant
108108

109109
An attack on Bitcoin may not be economically motivated - an attacker may be politically or maliciously motivated and may attempt to destroy value and trust in Bitcoin rather than extract value. There is no way to know in advance how, when, or why an attack may occur. A defensive position must be taken well in advance of any attack.
110110

111-
Bitcoin's current signatures (ECDSA/Schnorr) will be a tantalizing target: any UTXO that has ever exposed its public key on-chain (roughly 25 % of all bitcoin) could be stolen by a cryptographically relevant quantum computer.
111+
Bitcoin's current signatures (ECDSA/Schnorr) will be a tantalizing target: any UTXO that has ever exposed its public key on-chain could be stolen by a cryptographically relevant quantum computer.
112112

113-
'''Existing Proposals are Insufficient. '''
113+
'''Existing Proposals (as of March 2026) are Insufficient. '''
114+
115+
To date, no quantum related proposal provides protection against:
116+
117+
1. Short-range attacks.
118+
119+
2. Long-range attacks due to address re-use.
120+
121+
3. Long-range attacks against already exposed public keys in P2PK or P2TR outputs.
114122

115123
Any proposal that allows for the quantum theft of "lost" bitcoin is creating a redistribution dilemma. There are 3 types of proposals:
116124

@@ -130,7 +138,7 @@ With a clear deadline, industry stakeholders will more readily upgrade existing
130138

131139
'''Minimizes loss of access to funds '''
132140

133-
If there is sufficient demand and research proves possible, submitting a ZK proof of knowledge 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.
141+
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.
134142

135143
{| class="wikitable"
136144
|- style="text-align:center;"
@@ -165,42 +173,6 @@ If true, the corollary is:
165173

166174
The timelines that we are proposing are meant to find the best balance between giving ample ability for account owners to migrate while maintaining the integrity of the overall ecosystem to avoid catastrophic attacks.
167175

168-
== Deployment ==
169-
170-
For Bitcoin mainnet, testnet4, and signet, this BIP is deployed by "version bits" with the name "postquantum" and bit 5, using [[bip-0009.mediawiki|BIP9]] modified to use a lower threshold, with an additional ''min_activation_height'' parameter and replacing the state transition logic for the DEFINED, STARTED and LOCKED_IN states as follows:
171-
172-
case DEFINED:
173-
if (GetMedianTimePast(block.parent) >= starttime) {
174-
return STARTED;
175-
}
176-
return DEFINED;
177-
178-
case STARTED:
179-
int count = 0;
180-
walk = block;
181-
for (i = 0; i < 2016; i++) {
182-
walk = walk.parent;
183-
if ((walk.nVersion & 0xE0000000) == 0x20000000 && ((walk.nVersion >> bit) & 1) == 1) {
184-
count++;
185-
}
186-
}
187-
if (count >= threshold) {
188-
return LOCKED_IN;
189-
}
190-
return STARTED;
191-
192-
case LOCKED_IN:
193-
if (block.nHeight < min_activation_height) {
194-
return LOCKED_IN;
195-
}
196-
return ACTIVE;
197-
198-
For Bitcoin mainnet, the starttime is epoch timestamp 1798761600 (midnight 1 January 2027 UTC), the threshold is 1815 blocks (90%) instead of 1916 blocks (95%), and the min_activation_height is block 709632.
199-
200-
For Bitcoin testnet4, the starttime is epoch timestamp 1798761600 (midnight 1 January 2027 UTC), the threshold is 1512 blocks (75%), and the min_activation_height is block 0.
201-
202-
For Bitcoin signet, the starttime is epoch timestamp 1798761600 (midnight 1 January 2027 UTC), the threshold is 1512 blocks (75%), and the min_activation_height is block 0.
203-
204176
=== Backward Compatibility ===
205177

206178
As a series of soft forks, older nodes will continue to operate without modification. Non-upgraded nodes, however, will consider all post-quantum witness programs as anyone-can-spend scripts. They are strongly encouraged to upgrade in order to fully validate the new programs.

0 commit comments

Comments
 (0)