jlopp commented at 2:08 pm on July 15, 2025: contributor

Initial draft of a proposal for how to incentivize migration to post quantum cryptography and safeguard the ecosystem from unnecessary inflation of the circulating supply and the economic turmoil likely to accompany such an event.

in bip-post-quantum-migration.mediawiki:109 in 75f64328db outdated

104+| TBD pending research, demand, and consensus.
105+|}
106+
107+=== Rationale ===
108+
109+Even if Bitcoin is not a primary initial target of a cryptographically relevant quantum computer, widespread knowledge that such a computer exists and is capable of breaking Bitcoin’s cryptography will damage faith in the network .

EthanHeilman commented at 5:37 pm on July 15, 2025:

Extra space slipped in there

0Even if Bitcoin is not a primary initial target of a cryptographically relevant quantum computer, widespread knowledge that such a computer exists and is capable of breaking Bitcoin’s cryptography will damage faith in the network.

jonatack added the label New BIP on Jul 15, 2025

in bip-post-quantum-migration.mediawiki:92 in 75f64328db outdated

87+! What Happens
88+! Who Must Act
89+! Time Horizon
90+|-
91+| A
92+| Permitted sends are from legacy scripts to P2QRH scripts.

EthanHeilman commented at 6:03 pm on July 15, 2025:

Phase A should be P2QRH+ PQ signatures

P2QRH currently only specifies a quantum resistant output. While BIP-360 does describe PQ signatures it is informational. We are working on BIP which specifies PQ signature opcodes.

in bip-post-quantum-migration.mediawiki:97 in 75f64328db outdated

92+| Permitted sends are from legacy scripts to P2QRH scripts.
93+| Everyone holding or accepting BTC.
94+| 3 years after BIP-360 implementation.
95+|-
96+| B
97+| At a predetermined block height, nodes reject transactions that rely on ECDSA/Schnorr keys.

EthanHeilman commented at 6:13 pm on July 15, 2025:

I’d be interested an expanded rationale for the approach of rejecting transactions that rely on ECDSA/Schnorr keys vs freezing quantum vulnerable outputs.

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.

The approach you propose would definitely prevent more thief long term. What is the delta between this and freezing all quantum vulnerable outputs in terms of vulnerable bitcoins?

Is the mechanism to determine if a transaction is reject, if OP_CHECKSIG appears in the script?

If someone did a Schnorr CHECKSIG and a PQ signature CHECKSIG_ML, would that be rejected? Probably right, that would be the more simple check.

jlopp commented at 1:58 pm on July 18, 2025:

Added more details to say reject any of the checksig opcodes. I suppose the logic could be “reject all checksig opcodes unless there is also a checksig_ml opcode” if we felt like someone might footgun their funds.

EthanHeilman commented at 2:22 pm on July 18, 2025:

That’s a good approach since you can still have Schnorr OP_CHECKSIG tapscripts in tapleafs without breaking OP_CHECKSIG_ML tapscripts.

This would break OP_CAT based covenants since they use OP_CHECKSIG in a quantum safe way to verify the txhash of the transaction on the stack. This suggests that if we want OP_CAT, we probably also want OP_PUSH_TXHASH so that people don’t use OP_CHECKSIG for covenants.

EthanHeilman commented at 6:25 pm on July 15, 2025: contributor

Excellent BIP, I like the way you laid out the case here.

deficruncher commented at 6:43 pm on July 15, 2025: none

Allow anyone to steal vulnerable coins, benefitting those who reach quantum capability earliest.

“Quantum recovered coins only make everyone else’s coins worth less. Think of it as a theft from everyone.”

Think of it as a theft from everyone

Not necessarily. Operating quantum computers costs a lot. For example no one will run computations if it costs 100M to break 50M worth UTXO. Of course with technological and algorithmic improvements the cost of breaking a key will go down.

But as costs go down each quantum-computer owner is faced with dillema, they:

either hack the UTXO ASAP pocketing the small difference between value-of-UTXO and cost-to-break-it
or wait for further advancement to increase margin profit

Due to game-theory we can expect quantum-computer-owners to go for option 1. They won’t go for option 2, because they don’t know if other players will also go for option 2. It introduces race-to-the-bottom dynamics between competing players in which cost-to-break-UTXO approaches value-of-the-UTXO.

Does it seem similar to something? Yeah, bitcoin mining in which average-cost-to-mine-one-bitcoin approaches value-of-one-bitcoin.

Quantum UTXO hacking can be framed as another parallel process of proof-of-work mining, but with the quantum-computers instead of SHA hashing chips. And as such I don’t think it is something to deem negative.

shocknet-justin commented at 8:11 pm on July 15, 2025: none

incentivize migration

If the threat were real (super-positional whether it is or not), that is the incentive.

Forced movement is a non-starter, ones desire to quantum-proof their key does not impart a responsibility on anyone else.

jlopp commented at 9:30 pm on July 15, 2025: contributor

No one can be forced to move their coins to quantum safe signature schemes.

On the flip side, no one can be forced to accept coins from quantum vulnerable signature schemes.

in bip-post-quantum-migration.mediawiki:17 in 75f64328db outdated

12+  Comments-URI: TBD
13+  Status: Draft
14+  Type: Standards Track
15+  Created: 2025-07-14
16+  License: BSD-3-Clause
17+  Requires: P2QRH as described in BIP-360

murchandamus commented at 11:15 pm on July 15, 2025:

The Requires header takes one or multiple numbers referring to other BIPs:

0  Requires: 360

in bip-post-quantum-migration.mediawiki:24 in 75f64328db outdated

19+
20+== Introduction ==
21+
22+=== Abstract ===
23+
24+This proposal follows the implementation of post-quantum (PQ) output type (P2QRH) 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.

murchandamus commented at 11:18 pm on July 15, 2025:

Note that BIP 360 currently describes a script tree based output type that differs from P2TR by not having the key path option, i.e., restricting itself to script path spending, but the leaf scripts still rely on BIP 340 Schnorr signatures. My understanding is that the authors of BIP 360 intend to produce another BIP that specifies the addition of PQ-signature schemes.

jlopp commented at 1:59 pm on July 18, 2025:

Gotcha. I think to match current spec it would be more accurate to say only allow sending to segwit v3 outputs?

murchandamus commented at 6:22 pm on July 19, 2025:

Given that BIP 360 is still in flux, it’s either way probably still subject to future change

jlopp commented at 10:49 am on July 25, 2025:

Updated to v2 outputs for now.

in bip-post-quantum-migration.mediawiki:4 in 75f64328db outdated

0@@ -0,0 +1,174 @@
1+<pre>
2+  BIP: TBD
3+  Title: Post Quantum Migration and Legacy Signature Sunset
4+  Layer: Consensus (soft fork)

murchandamus commented at 11:20 pm on July 15, 2025:

Title should follow Layer

murchandamus commented at 11:41 pm on July 15, 2025: member

Thanks, this looks great for a first showing. There are a few minor editorial details I noticed, and one aspect regarding BIP 360 (which I see that Ethan also pointed out).

in bip-0361.mediawiki:166 in 75f64328db outdated

161+
162+"Lost coins only make everyone else's coins worth slightly more. Think of it as a donation to everyone." - Satoshi Nakamoto
163+
164+If true, the corollary is:
165+
166+"Quantum recovered coins only make everyone else's coins worth less. Think of it as a theft from everyone."

deficruncher commented at 9:38 am on July 16, 2025:

Quantum recovered coins only make everyone else’s coins worth less. Think of it as a theft from everyone.

This is an opinionated framing of the situation. I believe I provided another framing of it as “additional proof-of-work mining along SHA-pow-mining” (see #1895 (comment) ).

I suggest we keep the BIP as neutral as possible without inserting arbitrary framing that conveys some specific opinion whether something is positive or negative.

murchandamus commented at 4:15 pm on July 16, 2025:

That framing is unfounded, because miners are paid to publish updates to Bitcoin’s blockchain, while there is no direct benefit to the Bitcoin ecosystem to incentivize quantum computer development by allowing quantum computer operators to misappropriate funds.

shocknet-justin commented at 2:27 pm on July 17, 2025: none

On the flip side, no one can be forced to accept coins from quantum vulnerable signature schemes.

If you receive abandoned coins that you suspect were stolen by QC, you can burn them. No one is forced to honor them.

You’re not afraid people will be forced to accept coins, but that they will happily accept them. This undermines your previous argument.

This is not a technical BIP, it’s a vanity one trying to impose a view on the market.

secure the value of the UTXO set

A functional QC would effectively be a winner-take-all coins, candidates in the running to have it already have access to a material number of coins (Google, Microsoft have countless passwords emails 2FA to custodial platforms and password managers containing seeds, backdoored OS’s, softkeyboards… etc).

A QC could also sign for any software distribution as it could bitcoin keys, enabling untold new backdoors into systems. There’s no change to Bitcoin that can protect Bitcoin from a QC threat (hoax) because Bitcoin is not the only link in the chain.

pldallairedemers commented at 4:10 pm on July 18, 2025: none

Allow anyone to steal vulnerable coins, benefitting those who reach quantum capability earliest.

“Quantum recovered coins only make everyone else’s coins worth less. Think of it as a theft from everyone.”

Think of it as a theft from everyone

Not necessarily. Operating quantum computers costs a lot. For example no one will run computations if it costs 100M to break 50M worth UTXO. Of course with technological and algorithmic improvements the cost of breaking a key will go down.

But as costs go down each quantum-computer owner is faced with dillema, they:

either hack the UTXO ASAP pocketing the small difference between value-of-UTXO and cost-to-break-it

or wait for further advancement to increase margin profit

Due to game-theory we can expect quantum-computer-owners to go for option 1. They won’t go for option 2, because they don’t know if other players will also go for option 2. It introduces race-to-the-bottom dynamics between competing players in which cost-to-break-UTXO approaches value-of-the-UTXO.

Does it seem similar to something? Yeah, bitcoin mining in which average-cost-to-mine-one-bitcoin approaches value-of-one-bitcoin.

Quantum UTXO hacking can be framed as another parallel process of proof-of-work mining, but with the quantum-computers instead of SHA hashing chips. And as such I don’t think it is something to deem negative.

Quantum sweeping does not generate consensus, it only funds quantum. Quantum computing isn’t bad in itself, it will advance material science far beyond what can be done with classical supercomputers. But it’s a mess for everyone if it ends up crashing crypto in the process, so it’s better to close as much of the surface of attack as possible to make sure we don’t end up with wicked incentives.

pldallairedemers commented at 4:55 pm on July 18, 2025: none

On the flip side, no one can be forced to accept coins from quantum vulnerable signature schemes.

If you receive abandoned coins that you suspect were stolen by QC, you can burn them. No one is forced to honor them.

There is no way to know, those transactions are indistinguishable from legit ones, the attacker is literally signing with your private key.

You’re not afraid people will be forced to accept coins, but that they will happily accept them. This undermines your previous argument.

This is not a technical BIP, it’s a vanity one trying to impose a view on the market.

secure the value of the UTXO set

A functional QC would effectively be a winner-take-all coins, candidates in the running to have it already have access to a material number of coins (Google, Microsoft have countless passwords emails 2FA to custodial platforms and password managers containing seeds, backdoored OS’s, softkeyboards… etc).

A functional CRQC will be expensive ($1B-$10B) and only break a finite number of keys per year, it’s not infinitely powerful which means that their use will be driven by incentives. The Bitcoin community must decide if they want to be the exit liquidity of quantum computing companies. This BIP proposes a way to reduce the surface of attack as much as possible.

A QC could also sign for any software distribution as it could bitcoin keys, enabling untold new backdoors into systems. There’s no change to Bitcoin that can protect Bitcoin from a QC threat (hoax) because Bitcoin is not the only link in the chain.

A lot of links in the chain have started upgrading. 38% of HTTPS traffic is already using PQC encryption on CloudFlare: https://radar.cloudflare.com/adoption-and-usage#post-quantum-encryption-adoption Kyber has been supported by Chrome since 2023. Software signing must still be upgraded on Github. Banks are roadmapping their own upgrade: https://www.bis.org/publ/bppdf/bispap158.htm Bitcoin is one of the easiest and most profitable target but one of the most difficult to upgrade because of its decentralized nature. While upgrading to stronger signatures, the community must decide what to do with the lost coins.

Mika001i commented at 9:12 pm on July 18, 2025: none

I read about your BIP on CoinDesk. It’s mind-blowing and thank you for leading the way. Post-quantum migration should be pro-active rather than reactive.

unknown commented at 11:32 pm on July 18, 2025: none

(Moderated)

bitcoin deleted a comment on Jul 19, 2025

jonatack commented at 4:53 am on July 19, 2025: member

Please keep the comments focused on technical review – thank you.

unknown commented at 9:43 am on July 19, 2025: none

‘‘‘Phase A’’’: Disallows sending of any funds to quantum-vulnerable locking scripts…

‘‘‘Phase B’’’: Renders ECDSA/Schnorr spends invalid, preventing all spending of funds in quantum-vulnerable UTXOs.

This BIP is hostile for the Bitcoin community and the entire Bitcoin network because it is saying that you can’t spend in the future non-quantum compatible funds.

I think @jlopp also need a disclamer, see: https://qb.tc/team

jlopp commented at 1:32 pm on July 19, 2025: contributor

This BIP is hostile for the Bitcoin community and the entire Bitcoin network because it is saying that you can’t spend in the future non-quantum compatible funds.

Simultaneously, this BIP is hostile for quantum capable adversaries because it is saying that you can’t steal bitcoin with your fancy computer.

I think @jlopp also need a disclamer, see: https://qb.tc/team

When I wrote my initial essay 4 months ago I was not collaborating with anyone. This BIP is a continuation of those same ideas I came up with independently.

scottwalker99 commented at 1:54 pm on July 19, 2025: none

This BIP is hostile for the Bitcoin community and the entire Bitcoin network because it is saying that you can’t spend in the future non-quantum compatible funds.

I think @jlopp also need a disclamer, see: https://qb.tc/team

NOTE: As a miner starting in November of 2013 who has invested more into the ecosystem than most… When I invested in the QBTC team (Great team all Bitcoiners by the way) it was because we agreed with Lopp essay and we reached out to collaborate. Q-day is coming sir and Lopp proposal is the best I have seen and should be supported.

ghost commented at 2:10 pm on July 19, 2025: none

Openly saying that we can’t spend in the future non-quantum compatible funds, is hostile for the Bitcoin community and the Bitcoin network!

If I have Bitcoin from 2011, I will not able to spend it in the future or receive Bitcoin to my address?

jonatack commented at 2:44 pm on July 19, 2025: member

I’ve attempted to remove the ad hominem and replies to it. @1BitcoinBoWP1FZ4xwTNkq6XksKidmgYYw, there’s no need to repeat the same argument.

Let’s keep discussion here focused on technical review of the BIP itself.

ghost commented at 2:48 pm on July 19, 2025: none

@jonatack he proposed nothing technical in nature. He just want us to not able to spend our Bitcoins in the future. I find not a single technical proposal in this BIP draft.

bitcoin deleted a comment on Jul 19, 2025

in bip-post-quantum-migration.mediawiki:97 in c295a43df4 outdated

 95-| 3 years after BIP-360 implementation.
 96+| 160,000 blocks (~3 years) after BIP-360 implementation.
 97 |-
 98 | B
 99-| At a predetermined block height, nodes reject transactions that rely on ECDSA/Schnorr keys.
100+| At a predetermined block height, nodes reject transactions spending funds locked by scripts that rely on ECDSA/Schnorr keys via OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG, or OP_CHECKMULTISIGVERIFY.

murchandamus commented at 3:39 pm on July 19, 2025:

Thanks for being more specific. You may also want to mention OP_CHECKSIGADD that was introduced by Tapscript in this context.

jlopp commented at 12:35 pm on July 20, 2025: contributor

@jonatack he proposed nothing technical in nature. He just want us to not able to spend our Bitcoins in the future.

False. In the event that quantum computers become a reasonable threat, I want people not to be able to spend their coins in a manner that is indistinguishable from quantum theft. As such, I want spending restricted so that it requires a quantum safe cryptographic proof accompanying it.

ghost commented at 12:55 pm on July 20, 2025: none

You don’t have to restrict any spending! That is just absurd. You should instead just propose hybrid addresses that are quantum resistant and also backwards compatible with ECDSA.

I also don’t understand what is this rush. You seem like someone who very much would like to enforce on us the “spending restriction”.

Quantum computers would need ≥ 1 million physical qubits and this must be logical qubits (error-corrected). We are very-very far from any quantum computer that would pose a threat to Bitcoin.

Estimates suggest this kind of quantum computers would exist after the year of 2040. So don’t need to rush and block transactions now just because you’re afraid of imaginary quantum computers.

jlopp commented at 1:04 pm on July 20, 2025: contributor

You don’t have to restrict any spending! That is just absurd. You should instead just propose hybrid addresses that are quantum resistant and also backwards compatible with ECDSA.

This BIP has no intention of addressing the separate issue of what post quantum cryptographic scheme to implement.

I also don’t understand what is this rush. You seem like someone who very much would like to enforce on us the “spending restriction”.

This BIP has no intention of addressing the separate issue of when to implement a post quantum cryptographic scheme.

This BIP only addresses the migration and incentives issues that arrive AFTER those questions have been resolved.

In short, it sounds like you have not comprehended the actual timeline and preconditions of activating this BIP.

jlopp commented at 1:31 pm on July 20, 2025: contributor

You’re free to propose a BIP to compete with BIP-360 and then we’d evaluate how it would affect the need for this BIP.

ghost commented at 1:35 pm on July 20, 2025: none

I strongly consider it.

ghost commented at 3:19 pm on July 20, 2025: none

@jlopp Here is our BIP titled: Quantum-Resistant Transition Framework for Bitcoin https://github.com/bitcoin-foundation/bips/blob/master/bip-quantum-resistant-transition-framework-for-bitcoin.mediawiki

Will send it now to the mailing list before opening a new PR.

ghost commented at 5:36 pm on July 20, 2025: none

@jlopp Feel free to review or use the linked BIP instead of your current version.

The mailing list is not showing our email, even though we’re members of the group.

Would it be acceptable to proceed with a PR directly, or is mailing list discussion still required?

jlopp commented at 12:43 pm on July 21, 2025: contributor

Let me see if I’ve got this straight.

After a multitude of comments claiming that restricting spending and freezing funds is absolutely unconscionable and unnecessary because there are other solutions, your proposal is effectively a slightly modified rewrite of my proposal that still restricts spending and ultimately freezes funds?

Whatever happened to

You don’t have to restrict any spending! That is just absurd. You should instead just propose hybrid addresses that are quantum resistant and also backwards compatible with ECDSA.

I struggle to justify spending any more time on this conversation as I simply can’t take it seriously.

ghost commented at 5:10 pm on July 21, 2025: none

There is a significant difference between your BIP and our BIP.

Your BIP proposal states:

Phase A: Disallows sending of any funds to quantum-vulnerable locking scripts…

In contrast, our BIP allows the spending of classical UTXOs for up to 8 years after activation. (After the first 5 years, users receive error prompts when sending from classical UTXOs, but the funds remain spendable.)

In other words, you propose to immediately block all spending/receiving from classical UTXOs upon activation—which is an unreasonable approach.

murchandamus commented at 5:32 pm on July 21, 2025: member

@1BitcoinBoWP1FZ4xwTNkq6XksKidmgYYw: Thank you for taking the time to compile your own variant of @jlopp’s proposal. It appears to have helped you better understand the approach taken in this proposal. Skimming your draft, the main difference appears to be a slightly altered timeline, as your proposal aims to start restricting spending of non-PQ output types after eight years from an undetermined time zero, and @jlopp’s proposal proposes to do so 3 years after PQ signatures have been deployed without guessing at the timeline for this prior work. Discussing the timeline of this proposal and making alternative suggestions is well within the scope of review for this proposal, so it is unclear what benefit opening a duplicate proposal would provide at this time.

As the Bitcoin Developer mailing list is moderated, it might take a moment for your email to go through. Please feel free to open a pull request, if the discussion on the mailing list results in an evolution of your proposal that significantly differs from this proposal to a point where other mailing list participants encourage you to put it up for consideration separately.

bitcoin deleted a comment on Jul 22, 2025

pldallairedemers commented at 4:16 pm on July 23, 2025: none

You don’t have to restrict any spending! That is just absurd. You should instead just propose hybrid addresses that are quantum resistant and also backwards compatible with ECDSA.

I also don’t understand what is this rush. You seem like someone who very much would like to enforce on us the “spending restriction”.

Quantum computers would need ≥ 1 million physical qubits and this must be logical qubits (error-corrected). We are very-very far from any quantum computer that would pose a threat to Bitcoin.

This is word salad, the point of distinguishing physical qubits from the logical ones is that they are not the same. It takes 2500 logical qubits to break 256-bit ECDLP, this translates in about 40k to 900k physical qubits. All roadmaps hit that milestone around 2029-2031.

Estimates suggest this kind of quantum computers would exist after the year of 2040. So don’t need to rush and block transactions now just because you’re afraid of imaginary quantum computers.

You’re making up numbers, this is worthless.

pldallairedemers commented at 4:26 pm on July 23, 2025: none

Check this out, this is a theoretical python implementation of quantum resistant Bitcoin with backward compatibility with ECDSA:

 0import hashlib
 1import ecdsa
 2from ecdsa import SigningKey, VerifyingKey
 3import base58
 4import os
 5
 6class QuantumResistantBitcoin:
 7    def __init__(self):
 8        self.ecdsa_key = SigningKey.generate(curve=ecdsa.SECP256k1)
 9        self.merkle_secret = os.urandom(32)
10        self.merkle_pubkey = self._generate_merkle_pubkey()
11        
12    def create_hybrid_transaction(self, recipient_address, amount):
13        tx_data = {
14            'version': 2,
15            'inputs': [{'prev_tx': '...', 'index': 0}],
16            'outputs': [{'address': recipient_address, 'amount': amount}],
17            'locktime': 0
18        }
19        
20        tx_serialized = self._serialize_transaction(tx_data)
21        
22        ecdsa_sig = self.ecdsa_key.sign(tx_serialized)
23        merkle_sig = self._merkle_sign(tx_serialized)
24        
25        transaction = {
26            **tx_data,
27            'scriptsig': ecdsa_sig,
28            'witness': {
29                'merkle_sig': merkle_sig,
30                'merkle_pubkey': self.merkle_pubkey
31            }
32        }
33        
34        return transaction
35    
36    def verify_hybrid_transaction(self, transaction):
37        tx_serialized = self._serialize_transaction({
38            'version': transaction['version'],
39            'inputs': transaction['inputs'],
40            'outputs': transaction['outputs'],
41            'locktime': transaction['locktime']
42        })
43        
44        try:
45            vk = self.ecdsa_key.get_verifying_key()
46            if vk.verify(transaction['scriptsig'], tx_serialized):
47                return True
48        except:
49            pass
50        
51        if 'witness' in transaction and 'merkle_sig' in transaction['witness']:
52            return self._merkle_verify(
53                transaction['witness']['merkle_pubkey'],
54                tx_serialized,
55                transaction['witness']['merkle_sig']
56            )
57        
58        return False
59    
60    def _serialize_transaction(self, tx_data):
61        return hashlib.sha256(str(tx_data).encode()).digest()
62    
63    def _generate_merkle_pubkey(self):
64        return hashlib.sha256(self.merkle_secret).digest()
65    
66    def _merkle_sign(self, data):
67        return hashlib.sha256(self.merkle_secret + data).digest()
68    
69    def _merkle_verify(self, pubkey, data, signature):
70        test_pubkey = hashlib.sha256(hashlib.sha256(signature).digest() + data).digest()
71        return pubkey == test_pubkey
72
73def create_hybrid_address(ecdsa_pubkey, merkle_pubkey):
74    combined = hashlib.sha256(ecdsa_pubkey + merkle_pubkey).digest()
75    return base58.b58encode_check(combined)
76
77qrb = QuantumResistantBitcoin()
78ecdsa_pubkey = qrb.ecdsa_key.get_verifying_key().to_string()
79merkle_pubkey = qrb.merkle_pubkey
80hybrid_address = create_hybrid_address(ecdsa_pubkey, merkle_pubkey)
81
82hybrid_tx = qrb.create_hybrid_transaction(hybrid_address, 0.01)
83is_valid = qrb.verify_hybrid_transaction(hybrid_tx)
84
85print("Hybrid Address:", hybrid_address)
86print("Transaction Valid:", is_valid)

Such implementation would require a soft fork to enable new opcodes (e.g., OP_PQVERIFY)

Old Bitcoin nodes validate the scriptsig (ECDSA).
Updated nodes check the witness field.

This code won’t work, review how hash-based signatures actually work (Lamport, Winternitz, XMSS, Sphincs+, etc.).

murchandamus commented at 6:30 pm on July 25, 2025: member

@1BitcoinBoWP1FZ4xwTNkq6XksKidmgYYw and @pldallairedemers: The scheme you are discussing is orthogonal to this proposal. In this PR, please focus on technical review of the document proposed here.

murchandamus commented at 8:42 pm on July 31, 2025: member

Banned @1BitcoinBoWP1FZ4xwTNkq6XksKidmgYYw for 7 days for continuing to be off-topic after warning.

In this PR, please contribute technical review for this proposal. Whether the proposal should be adopted by the community is a separate conversation that is not on-topic here.

in bip-post-quantum-migration.mediawiki:62 in 96693d20fc outdated

57+
58+Assuming that quantum computers are able to maintain their current trajectories and overcome existing engineering obstacles, there is a near certain chance that all P2PK (and other outputs with exposed pubkeys) private keys will be found and used to steal the funds.
59+
60+'''Impossible to know motivations.'''
61+
62+Prior to a quantum attack, it is impossible to know the motivations of the attacker.  An economically motivated attacker will try to remain undetected for as long as possible, while a malicious attacker will attempt to destroy as much value as possible.

arminsabouri commented at 1:13 pm on August 6, 2025:

Nit: double space

0Prior to a quantum attack, it is impossible to know the motivations of the attacker. An economically motivated attacker will try to remain undetected for as long as possible, while a malicious attacker will attempt to destroy as much value as possible.

in bip-post-quantum-migration.mediawiki:26 in 75f64328db outdated

21+
22+=== Abstract ===
23+
24+This proposal follows the implementation of post-quantum (PQ) output type (P2QRH) 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.
25+
26+'''Phase A''': Disallows sending of any funds to quantum-vulnerable addresses, hastening the adoption of P2QRH address types.

stwenhao commented at 5:34 am on August 8, 2025:

It should be non-standard, instead of being entirely blocked. Because OP_CHECKSIG can still remain useful, if you will do something more, than just <pubkey> OP_CHECKSIG. For example: if you use OP_SIZE on top of some DER signature, then you won’t spend it, without also breaking SHA-256. By knowing a private key to secp256k1 point with one-byte x-value, you can go from 60-byte signatures into 40-byte signatures. But going further will require grinding SHA-256 hashes, which may be harder for quantum devices, than it is for classical ones. See also: https://bitcointalk.org/index.php?topic=5551080.0

in bip-0361.mediawiki:28 in 75f64328db outdated

23+
24+This proposal follows the implementation of post-quantum (PQ) output type (P2QRH) 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.
25+
26+'''Phase A''': Disallows sending of any funds to quantum-vulnerable addresses, hastening the adoption of P2QRH address types.
27+
28+'''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.

stwenhao commented at 5:39 am on August 8, 2025:

It should be timelocked, and that timelock can be many years into the future. It could be also expressed as some future block number. Timelocking is better than burning, because then, future adjustments can be made as soft-forks, instead of being hard-forks. Also, in the meantime, people with frozen funds can still make second-layer transactions, protected by quantum proofs, to change on-chain coin ownership, without making any on-chain transactions, for the time when funds will be frozen. And then, the last coin owners could make a valid on-chain transaction, with classical ECDSA signature, and with quantum proof, that the whole chain of quantum signatures is correct.

jonatack commented at 8:48 pm on March 2, 2026:

@jlopp mind replying to this feedback?

in bip-0361.mediawiki:30 in 75f64328db outdated

25+
26+'''Phase A''': Disallows sending of any funds to quantum-vulnerable addresses, hastening the adoption of P2QRH address types.
27+
28+'''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.
29+
30+'''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.

stwenhao commented at 5:46 am on August 8, 2025:

Legacy UTXOs should be moved in exactly the same way as they are today, to let old nodes understand it, and follow the heaviest chain in a backward-compatible way. New quantum commitments can be stored in the witness space, or some kind of second witness (which I call “commitment”). Existing non-quantum nodes should not process any quantum data at all, just like non-Segwit nodes don’t know anything about witness space in Segwit transactions. For each and every OP_CHECKSIG call in any existing form, there should be a valid commitment, which would be processed only by upgraded nodes. It would also let some new quantum schemes to compete more fairly with others, because then, the size of the quantum proof is not restricted by the current max block size limit, and can be changed by a future soft-fork, if needed. For example: instead of 4*legacy+witness, it could be factor*(4*legacy+witness)+commitment.

jonatack commented at 8:48 pm on March 2, 2026:

@jlopp mind replying to this feedback?

murchandamus commented at 11:12 pm on August 8, 2025: member

Hey @jlopp, beside the currently open feedback, how do you perceive the status of your draft? Are you still planning changes or hope to get more feedback about specific aspects of it?

ghost commented at 12:01 pm on August 11, 2025: none

Compared to the BIP from @jlopp and other entities, the Quantum-resistant Bitcoin proposal (resources below) demonstrates a higher level of detail and professionalism.

Bitcoin Development Mailing List: https://groups.google.com/g/bitcoindev/c/2mQEyxHUskc
BIP Website: https://quantum-resistant-bitcoin.bitcoin.foundation

Note: As a member of the Bitcoin Foundation (publisher of this BIP), I wish to highlight key differences from @jlopp’s proposal:

Longer Migration Period: Provides a more realistic timeframe for upgrade adoption.
Concrete Algorithm Choice: Specifies a particular quantum-resistant algorithm for implementation.
Non-Commercial Origin: Developed by a non-profit foundation, distinct from proposals authored by corporations with commercial interests in post-quantum wallet solutions (potentially mitigating perceived conflicts of interest).

jlopp commented at 2:45 pm on August 12, 2025: contributor

Hey @jlopp, beside the currently open feedback, how do you perceive the status of your draft? Are you still planning changes or hope to get more feedback about specific aspects of it?

I think it’s stabilized for the forseeable future; expecting more tweaks as other proposals are created / modified and as R&D on quantum safe recovery schemes progresses.

ghost commented at 3:50 pm on August 12, 2025: none

@jlopp,

Regarding commit c64b817: I’m surprised this required a co-authored tag for a whitespace correction. Such minor edits typically don’t warrant attribution.

Because “Armin Sabouri” is working / worked for your company, promotion for “CASA” here seems inappropriate

Separately, I’d like to address the BIP author section: The current corporate affiliations (including custodial wallet providers) already feel disproportionately represented

Request: Please keep this space focused on individual contributors rather than corporate entities

The BIP repository should prioritize technical merit over commercial visibility.

jonatack commented at 4:16 pm on August 12, 2025: member

Please focus on technical review. Co-author choices, author backgrounds, and promotion of other proposals are not on-topic here.

jonatack renamed this:
~~Quantum Migration BIP~~
BIP draft: Quantum Migration
on Aug 12, 2025

in bip-post-quantum-migration.mediawiki:44 in c64b817f94 outdated

39+
40+'''Accelerating quantum progress.'''
41+
42+NIST ratified three production-grade PQ signature schemes in 2024; some academic road-maps now estimate a cryptographically-relevant quantum computer as early as 2027-2030, [https://www.mckinsey.com/~/media/mckinsey/business%20functions/mckinsey%20digital/our%20insights/the%20year%20of%20quantum%20from%20concept%20to%20reality%20in%202025/quantum-monitor-2025.pdf?shouldIndex=false per McKinsey].
43+
44+'''Quantum algorithms are rapidly improving'''

jonatack commented at 10:51 pm on August 19, 2025:

nit, all the other subtitles in this section end with a period

0'''Quantum algorithms are rapidly improving.'''

jonatack commented at 11:23 pm on August 19, 2025: member

I may have overlooked it, but there doesn’t appear to be much discussion in the current draft of the soft forks involved here, apart from quite succinctly in the last section on Backward Compatibility and in the sentence on line 28 in the Abstract that mentions a flag day.

Might it be helpful to discuss and specify these forks more in the Specification section and/or in a Deployment section? (See those of other soft fork BIPs for examples.)

My impression has been that this draft excels in communicating context, but is light on the Specification and Deployment(s) involved.

ghost commented at 6:06 am on August 20, 2025: none

The assertion that ‘‘‘quantum algorithms are rapidly improving’’’ is misleading. The specific algorithm that jeopardizes Bitcoin’s cryptography, Shor’s algorithm, has been a known entity since the 1990s and has not undergone fundamental change.

This BIP proposal strikes me as highly alarmist and unprofessional. Moreover, it appears to have bypassed the essential, consensus-driven process of the Bitcoin Development Mailing List, as I have not observed any discussion indicating this proposal was ready for a formal pull request.

Note: I am an author of a competing draft BIP presently under review on the mailing list.

EthanHeilman commented at 2:52 pm on August 20, 2025: contributor

The assertion that ‘‘‘quantum algorithms are rapidly improving’’’ is misleading. The specific algorithm that jeopardizes Bitcoin’s cryptography, Shor’s algorithm, has been a known entity since the 1990s and has not undergone fundamental change.

The algorithm here is referring to underlying algorithms that make the QC hardware more effective and require fewer physical qubits for a factoring task.

Shor’s algorithm requires a certain number of logical qubits to perform a task in a period of time. The hardware provides a certain number of physical qubits, so the question then becomes how many physical qubits are needed to make a logical qubit and thus how many physical qubits are needed to run Shor’s algorithm attack on a particular key size. We are seeing rapid progress in the quantum algorithms that reduce the number of physical qubits needed for a logical qubit and thus accelerate Shor’s Algorithm.

In the specific of this work How to factor 2048 bit RSA integers with less than a million noisy qubits (may, 2025) which states:

“In Gidney+Ekerå 2019, I copublished an estimate stating that 2048 bit RSA integers could be factored in eight hours by a quantum computer with 20 million noisy qubits. In this paper, I substantially reduce the number of qubits required. I estimate that a 2048 bit RSA integer could be factored in less than a week by a quantum computer with less than a million noisy qubits.”

That’s a 20x improvement. Now as far as I can tell, this specific paper uses a technique that only applies to RSA and doesn’t improve on factoring attacks against the elliptic curve cryptography used by Bitcoin. That said, the very fact that we are seeing this sort of rapid improvements in quantum factoring is worrying.

murchandamus commented at 4:49 pm on August 20, 2025: member

Moreover, it appears to have bypassed the essential, consensus-driven process of the Bitcoin Development Mailing List, as I have not observed any discussion indicating this proposal was ready for a formal pull request.

It seems to me that there are some misconceptions about the BIPs process and the purpose of the BIPs repository. BIPs start as personal recommendations by the authors to the community. The BIPs repository is a central publication medium for collating these author documents in one highly visible location. Generally, it’s preferable if ideas are met with interest and encouragement before they are elaborated into fleshed out submissions, and there are editorial standards to help keep the repository’s content relevant. Other than that, publication basically only hinges on the submission being on-topic and sufficiently mature. As proposals get adopted by the community, the community takes on more ownership of proposals, but especially in the Draft stage and even up to the Proposed stage, BIPs should not be construed as endorsed whatsoever by anyone except the authors and other explicit proponents.

For this particular proposal, the mailing list thread presenting the idea for this BIP collected 22 emails and a number of replies indicated interest or support for the idea which absolutely should encourage the would-be BIP author to submit their document to this repository.

21btc12VnSa25vj8pWh2wvBScs16Hx commented at 2:56 pm on August 25, 2025: none

Concerning Potential Conflicts of Interest in Bitcoin BIP Governance

Hello everyone, I wanted to bring up some relatively unsettling observations on what appears to be a wide-spread conflict of interest involving the current BIP editor on GitHub (@murchandamus, Mark Erhardt). This is worthy of our community’s attention because it is quite possibly compromising the validity of Bitcoin improvement proposals and their judging process.

Professional Relationships and Suspicious Collaborations

Here’s why this is causing red flags for me: Mark Erhardt and Jameson Lopp (@jlopp) used to work together at BitGo, the cryptocurrency security firm. Although they have since departed to other entities, their working together persists in ways that appear to advance certain corporate agendas over Bitcoin’s decentralized philosophy.

Most alarming is the manner in which they appear to be coordinating efforts to push through a specific BIP written by Jameson for-profit associates. Their prior relationship leads towards potential bias in handling specific proposals in the BIP repository in which Mark has admin privileges.

In problematic advocacy patterns

If evidence of this concerted push is needed, simply observe their engagement in Bitcoin Optech discussions where these two men eagerly encourage swift adoption of this contentious BIP. In a very revealing April 2025 conversation, they’re essentially planning how to speed up this proposal in spite of community reservations:

https://bitcoinops.org/en/podcast/2025/04/08/#draft-bip-for-destroying-quantum-insecure-bitcoins-transcript

What’s frustrating is their apparent eagerness to “force on users” this particular standard without what I would call due scrutiny or consensus building in the broader community. This is not how Bitcoin governance is meant to occur; especially for something as simple as a BIP.

Misrepresenting Quantum Computing Risks

Now let’s speak to the substance of their proposal: they’re making what I believe are inflated claims about the dangers to Bitcoin’s security model posed by quantum computers. Having been following quantum computing advancements for many years, I can say their account rings false at worst and deliberately alarmist at best.

They’re presenting quantum vulnerability as an immediate threat when most experts believe we’re likely years away from being capable of having the power of quantum computers needed to crack Bitcoin’s cryptography. This so-called urgency seems to be to try and push through their plan without enough debate and review it has received.

Questionable Authorship and Fake Trademarks

And this is where things get really disturbing: one of the primary authors of this BIP is a company called The Pauli Group (https://pauli.group). This Canadian company founded in 2021 has on its website some pretty sensational claims to the effect that it holds trademarks including:

“Anchor™ Secure Wallet”
“Proof-of-quantum™”

But the problem is, these trademarks do not exist. If you go take the trouble to search the World Intellectual Property Organization’s Global Brand Database (https://branddb.wipo.int/en/similarname), you’ll receive a zero response on these supposed trademarks .

Isn’t it deeply troubling that we’re supposed to trust authors who openly misrepresent their intellectual property? If they’re willing to be this deceptive about their trademarks, how can we trust their technical contributions to Bitcoin?

Pattern of Problematic Behavior

This is not an isolated instance either; I’ve come across several discussions between Mark Erhardt and Jameson Lopp that are having this same disturbing trajectory. Since I won’t be quoting everything here (I recommend that everyone do some digging on their own), the overall picture suggests a coordinated effort toward advancing specific agendas as opposed to strictly objective Bitcoin improvement.

The fact that Mark continues to run the BIP repository despite maintaining this relationship with somebody actively proposing contentious changes is what I see as a blatant conflict of interest. It abandons the impartiality and justice we need from BIP editors.

Call to Action

With all these scary developments, I believe that @murchandamus should seriously consider resigning his admin position in the BIP repository. At a minimum, he should recuse himself from ruling on proposals involving his former colleagues and their corporate affiliations.

We need to maintain high ethical standards in Bitcoin’s decision-making procedures. Appearance of impropriety can already damage community trust, and what we’re seeing here seems more than appearance; it seems to be actual conflict of interest.

I encourage the whole community to look into this matter themselves and form their own opinions. We need to continue to keep Bitcoin development open, decentralized, and free of corporate or individual agenda capture.

Mark Erhardt aka murchandamus

Note: Above image is of Mark Erhardt, the current BIP editor whose actions and connections are in question in this article.

Archived: https://web.archive.org/web/20250825145808/https://github.com/bitcoin/bips/pull/1895 https://archive.md/aN8wg

(Archived for the people in the Bitcoin community whom may want to see this serious issue in the future)

in bip-0361.mediawiki:15 in 10ee8756c8 outdated

10+          Pierre-Luc Dallaire-Demers <pierre-luc@pauli.group>
11+  Comments-Summary: No comments yet.
12+  Comments-URI: TBD
13+  Status: Draft
14+  Type: Standards Track
15+  Created: 2025-07-14

murchandamus commented at 10:27 pm on February 10, 2026:

0  Authors: Jameson Lopp <jameson@lopp.net>
1           Christian Papathanasiou <chris@qb.tc>
2           Ian Smith <ianquantum2027@gmail.com>
3           Joe Ross <joeross7878@gmail.com>
4           Steve Vaile <steve@qsecdef.com>
5           Pierre-Luc Dallaire-Demers <pierre-luc@pauli.group>
6  Status: Draft
7  Type: [Specification|Informational]
8  Assigned: ?

in bip-post-quantum-migration.mediawiki:92 in 10ee8756c8

87+! What Happens
88+! Who Must Act
89+! Time Horizon
90+|-
91+| A
92+| Permitted sends are from legacy scripts to PQ scripts. Per BIP-360, this would be SegWit version 2 outputs.

murchandamus commented at 10:27 pm on February 10, 2026:

BIP 360 no longer proposes a post-quantum signature scheme.

murchandamus commented at 10:28 pm on February 10, 2026: member

I was just revisiting this proposal with BIP 360 getting close to publication. Given that this proposal is currently not implementable and presumably will not be for quite some time, I was wondering whether it might make sense to read this proposal rather as a potential roadmap to address the quantum threat and categorize it as an Informational BIP.

Also, the preamble would need some tweaks now that BIP 3 was deployed.

murchandamus commented at 9:31 pm on February 11, 2026: member

Let’s refer to this as BIP 361. Please:

Update the BIP header in the preamble
Update the Assigned header in the preamble to 2026-02-11
Add an entry for your BIP in the README.mediawiki file
Rename your document’s file to bip-0361.mediawiki

murchandamus renamed this:
~~BIP draft: Quantum Migration~~
BIP361: Quantum Migration
on Feb 11, 2026

murchandamus renamed this:
~~BIP361: Quantum Migration~~
BIP361: Post Quantum Migration and Legacy Signature Sunset
on Feb 11, 2026

jlopp commented at 10:40 pm on February 11, 2026: contributor

Alright, there are still several things I’ve been wanting to add, just hasn’t been a high priority since this is a far-future plan. Will aim to get some updates pushed in the next week.

jlopp force-pushed on Feb 16, 2026

BIP-361 de293ff0a5

jlopp force-pushed on Feb 16, 2026

jlopp commented at 5:31 pm on February 16, 2026: contributor

Made the requested changes though I’m not clear on how to resolve the current failing diff check.

bip361: Fix background color efcdddb244

in README.mediawiki:1257 in de293ff0a5

1252+| Consensus (soft fork)
1253+| Post Quantum Migration and Legacy Signature Sunset
1254+| Jameson Lopp, Christian Papathanasiou, Ian Smith, Joe Ross, Steve Vaile, Pierre-Luc Dallaire-Demers
1255+| Informational
1256+| Draft
1257+|-

murchandamus commented at 10:28 pm on February 17, 2026:

The line with the BIP number is the second number of the BIP! TBH, I can’t tell you why we color the table, but the line with the background color belonged to BIP 370. :)

0|-
1| [[bip-0361.mediawiki|361]]
2| Consensus (soft fork)
3| Post Quantum Migration and Legacy Signature Sunset
4| Jameson Lopp, Christian Papathanasiou, Ian Smith, Joe Ross, Steve Vaile, Pierre-Luc Dallaire-Demers
5| Informational
6| Draft
7|- style="background-color: #cfffcf"

murchandamus commented at 10:34 pm on February 17, 2026: member

Thanks for the update. I think I see what the issue is and pushed the fix.

murchandamus commented at 0:57 am on February 28, 2026: member

Given that proposals can be further developed in Draft stage and this is predominantly a proposed outline how to further react to the quantum thread, would you perceive your document to be ready for publication?

SHAKE256 commented at 3:34 am on February 28, 2026: none

Given that proposals can be further developed in Draft stage and this is predominantly a proposed outline how to further react to the quantum thread, would you perceive your document to be ready for publication?

This BIP has absolutely nothing to do with solving any quantum related threats!

It’s pure marketing by your friend with whom you worked at BitGo.

As a Bitcoin Core contributor (secp256k1) I oppose this or the other nonsensical BIP 360 to become even Drafts.

You guys have very clear conflict of interest.

SHAKE256 commented at 9:38 am on February 28, 2026: none

@jlopp said above:

This BIP only addresses the migration and incentives issues that arrive AFTER those questions have been resolved.

I suggest to keep Bitcoin IMPLEMENTATION Proposals free from spammers who looking for fame and promoting essay like @jlopp.

This and the other BIP from “Hunter Beast” are nonsense and marketing hype.

None of these people propose anything meaningful that is worth considering as PERMANENT BIP that stick with us for the rest of the future of Bitcoin.

These proposals have no merits, zero solutions, all just bla-bla-bla.

As I said I’m strongly against allowing these to add anything to the BIP repository.

You as a BIP editor must remain neutral and not push your BitGo friend’ nonsense proposal just because now you had become a BIP editor.

This is the BITCOIN IMPLEMENTATION PROPOSAL repository not some personal blog for essay and media attention grabbing that in essence completely nonsense masquerading as a solution.

jlopp commented at 11:52 am on February 28, 2026: contributor

Given that proposals can be further developed in Draft stage and this is predominantly a proposed outline how to further react to the quantum thread, would you perceive your document to be ready for publication?

Yes, I think it’s pretty well baked for now. The 2 outstanding issues are going to need a lot of time for R & D.

A quantum resistant scheme that gains consensus.
A quantum resistant zero knowledge proof scheme for recovering funds that don’t migrate before the ECC deprecation deadline.

SHAKE256 commented at 11:58 am on February 28, 2026: none

Nothing should be merged from @jlopp he very clearly ignores very serious claims by other people. Nothing should be allowed to be merged to BIP if anyone opposes it especially when raising conflict of interest between the proposer and a BIP editor! Loop’s document is not worth to be added as a BIP. It has zero technical or implementation proposal. It’s a big trash that put together based on his essay. BIP repository is NOT a blog!

murchandamus commented at 7:25 pm on February 28, 2026: member

This is the BITCOIN IMPLEMENTATION PROPOSAL repository not some personal blog for essay and media attention grabbing that in essence completely nonsense masquerading as a solution. @SHAKE256: The Bitcoin Improvement Proposals repository is a publication medium to put proposals forth to the Bitcoin community. This document is a recommendation by Lopp et al to the community. My assessment is that this document is nearing sufficient maturity to be published in Draft status to the repository. Neither number assignment nor publication should be construed as endorsement by the BIP Editors. Publication does not convey anything about the community sentiment or likelihood of ecosystem adoption either. It simply means that it’s on-topic; and its publication serves to facilitate community consideration.

It’s not clear to me what conflict of interest you perceive. I’m not, nor have I ever been, paid by Jameson, I do not financially benefit from adoption of this proposal. I do not have any stake in any pro- or anti-quantum computing ventures. In fact, I don’t think that the quantum threat is going to substantiate at all in the next few decades. However, it still seems pertinent that these ideas be discussed as others obviously are already concerned about quantum threats.

If you have any arguments why you think this is not on-topic or not ready, or would like to raise specific issues concerning the content of the proposal that have been insufficiently addressed, those might be relevant regarding its readiness for publication—just thinking that it shouldn’t be adopted is not.

Your style reminds me of two other accounts that posted here before: https://github.com/1BitcoinBoWP1FZ4xwTNkq6XksKidmgYYw and https://github.com/21btc12VnSa25vj8pWh2wvBScs16Hx. Would you happen to be the same person?

SHAKE256 commented at 12:20 pm on March 1, 2026: none

Jameson Lopp (@jlopp) worked at BitGo from 2015 to 2018. You @murchandamus worked at BitGo from 2017 to 2020 according to your own words in the “Bitcoin Optech” newsletter.

This means that you and Jameson Lopp worked together at least 1 year.

You had become BIP editor recently and now you pushing for NON-TECHNICAL nonsense spam as BIP.

You clearly have conflict of interest as a BIP editor regarding Jameson Lopp’s nonsense.

The BIP repository is not a blog where you can just submit all kinds of nonsense and getting a BIP number assigned.

This is for IMPLEMENTATION proposals not personal enrichment, media attention etc.

You as a BIP editor especially because you personally know and worked with Jameson Lopp shouldn’t be trusted to review this impartially.

in bip-0361.mediawiki:48 in efcdddb244

43+
44+The safety envelope is shrinking by dramatic increases in algorithms even if the pace of hardware improvements is slower. Algorithms are [https://security.googleblog.com/2025/05/tracking-cost-of-quantum-factori.html improving up to 20X], lowering the theoretical hardware requirements for breaking classical encryption.
45+
46+'''Bitcoin's exposed public keys.'''
47+
48+Roughly 25% of all bitcoin have revealed a public key on-chain; those UTXOs could be stolen with sufficient quantum power.

jonatack commented at 8:51 pm on March 2, 2026:

Should the “Roughly 25%” figure refer to a date or time period?

in bip-0361.mediawiki:22 in efcdddb244

17+
18+== Introduction ==
19+
20+=== Abstract ===
21+
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.

jonatack commented at 8:54 pm on March 2, 2026:

This proposal follows the implementation of a post-quantum (PQ) output type

Does this refer to a particular implementation? BIP360, other? Or the general concept of one? Be good to clarify here.

incentive: fail to upgrade and you will certainly lose access to your funds

This centerpiece of the proposal seems controversial.

jlopp commented at 10:23 pm on March 2, 2026:

Correct, and much as BIP-360 morphed over time, so has our thinking on this. I don’t think the BIP would have any chance of success without the ZK recovery option. My current thinking is ZK recovery + hourglass on P2PK outputs being the recommendation in order to make actual likelihood of funds loss a very tiny edge case.

in bip-0361.mediawiki:113 in efcdddb244

108+
109+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.  
110+
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.
112+
113+'''Existing Proposals are Insufficient. '''

jonatack commented at 8:56 pm on March 2, 2026:

It might be relevant or of interest, to clarify if and how this assertion applies to pre-existing BIP360.

This title probably should also have a date or time period.

SHAKE256 commented at 9:05 pm on March 2, 2026: none

Let me tell all of you a secret.

While you think that quantum computers pose a threat to Bitcoin in reality reconstructing the Windows XP state of Satoshi Nakamoto and combining that state with the “Patoshi Pattern” will allow the recovery of 1 Million Bitcoin that mined by Satoshi.

We know what OpenSSL he used, we know the weaknesses of the “random number generator” all we need to know is the time of system booting.

AI pose significantly bigger threat to that 1 Million Bitcoin than quantum computers.

I know for a fact that Satoshi was not started mining 40 minutes after the booting of XP.

Also note that there is a 6 day gap before he began mining continuously. This doesn’t mean he was booted 5 days before but I think he was well aware of this vulnerability at that time.

Realistically if he booted 3 hours before began mining and didn’t did much the entropy could be reconstructed. Windows XP source code is available publicly and you can study how much entropy he may had.

Recovering his private keys is more than possible with sufficient computing power.

Think about what I said here.

Also note that according to my research he used a custom Bitcoin version not what he published thought Bitcoin 0.1.0 gives you a good idea about his version.

in bip-0361.mediawiki:198 in efcdddb244 outdated

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.

jonatack commented at 9:40 pm on March 2, 2026:

The starttime refers to the beginning of Phase A?

jlopp commented at 10:40 pm on March 2, 2026:

Phase A (disallowing sending to quantum vulnerable outputs) would occur 160,000 blocks after activation. Thus the current logic is stating that Jan 2027 is the earlier possible activation which would make the earliest possible enforcement of phase A to be Jan 2030.

Of course, none of this can possibly happen without a PQC BIP first being activated.

jonatack commented at 9:40 pm on March 2, 2026: member

A quick look. I didn’t yet review carefully the Deployment section (and code), nor consider edge/failure cases in general.

SHAKE256 commented at 9:48 pm on March 2, 2026: none

@jonatack

Isn’t this “BIP” depends on another one? This should not be allowed to be merged until the other is properly adopted.

Also note that Lattice-based schemes are not recommended for the long term. Forcing Bitcoin to use lattice-based ones very likely will force Bitcoin in the next 10-20 years to migrate again.

Need to use HASH based schemes using schemes designed for KEM makes no sense.

I’m strongly against this “BIP” and the other one as well. They make no sense for Bitcoin.

jonatack commented at 9:53 pm on March 2, 2026: member

@SHAKE256 I understand some of your points, e.g., that this in some ways seems more a blog post than a technical BIP (and the “fail to upgrade and you will certainly lose access to your funds” aspect seems potentially controversial). However, please keep your comments focused here on technical review. I’ve “hidden” some of them, but they are still viewable. It isn’t helpful to repeat them. Rather, it would add more value to omit further personal and/or blanket criticism in favor of specific comments to improve here.

SHAKE256 commented at 9:58 pm on March 2, 2026: none

@jonatack

I’m well aware what you are trying to say but when you say “technical review” you completely ignore the fact that there is NOTHING TECHNICAL in this BIP. It’s pure IF/WHEN/MAYBE.

jonatack commented at 10:01 pm on March 2, 2026: member

Isn’t this “BIP” depends on another one? This should not be allowed to be merged until the other is properly adopted.

I think that aspect could be clearer in this draft (at least, to me), but apart from clarity I believe it’s not a blocker in terms of BIPs process as specified in BIP 3.

address feedback caebc9e7ab

jlopp force-pushed on Mar 2, 2026

BIP361: Post Quantum Migration and Legacy Signature Sunset #1895

Concerning Potential Conflicts of Interest in Bitcoin BIP Governance

Professional Relationships and Suspicious Collaborations

In problematic advocacy patterns

Misrepresenting Quantum Computing Risks

Questionable Authorship and Fake Trademarks

Pattern of Problematic Behavior

Call to Action