Quantum Migration BIP

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.

Quantum Migration BIP 75f64328db

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: contributor

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).

feedback incorporation c295a43df4

in bip-post-quantum-migration.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.

1BitcoinBoWP1FZ4xwTNkq6XksKidmgYYw 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.

1BitcoinBoWP1FZ4xwTNkq6XksKidmgYYw 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.

1BitcoinBoWP1FZ4xwTNkq6XksKidmgYYw 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.

1BitcoinBoWP1FZ4xwTNkq6XksKidmgYYw 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.

1BitcoinBoWP1FZ4xwTNkq6XksKidmgYYw 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.

1BitcoinBoWP1FZ4xwTNkq6XksKidmgYYw commented at 1:09 pm on July 20, 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.

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.

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

I strongly consider it.

add OP_CHECKSIGADD 4f96ccf22f

1BitcoinBoWP1FZ4xwTNkq6XksKidmgYYw 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.

1BitcoinBoWP1FZ4xwTNkq6XksKidmgYYw 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.

1BitcoinBoWP1FZ4xwTNkq6XksKidmgYYw 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: contributor

@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

segwit version 2 96693d20fc

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.).

1BitcoinBoWP1FZ4xwTNkq6XksKidmgYYw commented at 2:10 am on July 25, 2025: none

@pldallairedemers

I resolved the code issue by integrating SPHINCS+ (also known as NIST SLH-DSA). SHAKE-256f was implemented to ensure a 256-bit security level.

Through my SPHINCS+-SHAKE256f implementation, signature sizes now measure at least 49856 bytes or 49.856 kilobytes. While substantial, SegWit usage mitigates this size concern! Testing with SPHINCS+-SHAKE128f yielded 17088 bytes or 17.088 kilobytes. Since 256-bit security is essential, we must accommodate Bitcoin’s larger signature footprint.

The previous implementation created addresses with random initial characters. The new version generates hybrid addresses that always start with 1 and are shorter due to the correct implementation of RIPEMD-160.

Hybrid Private Key (WIF):

The implementation now includes an enhanced WIF private key format that:

Prepends version byte 0xEF
Supports full reconstruction of signing capabilities from the WIF

  0import hashlib
  1import ecdsa
  2from ecdsa import SigningKey
  3import base58
  4import os
  5import json
  6from pyspx import shake_256f
  7
  8class QuantumResistantBitcoin:
  9    def __init__(self):
 10        self.ecdsa_key = SigningKey.generate(curve=ecdsa.SECP256k1)
 11        seed = os.urandom(shake_256f.crypto_sign_SEEDBYTES)
 12        self.sphincs_public, self.sphincs_private = shake_256f.generate_keypair(seed)
 13
 14    def create_hybrid_transaction(self, recipient_address, amount):
 15        tx_data = {
 16            'version': 2,
 17            'inputs': [{'prev_tx': '...', 'index': 0}],
 18            'outputs': [{
 19                'address': recipient_address,
 20                'amount': amount
 21            }],
 22            'locktime': 0
 23        }
 24
 25        tx_serialized = self._serialize_transaction(tx_data)
 26
 27        ecdsa_sig = self.ecdsa_key.sign(tx_serialized)
 28        sphincs_sig = shake_256f.sign(tx_serialized, self.sphincs_private)
 29
 30        transaction = {
 31            **tx_data,
 32            'scriptsig': ecdsa_sig.hex(),
 33            'witness': {
 34                'sphincs_sig': sphincs_sig.hex(),
 35                'sphincs_pubkey': self.sphincs_public.hex()
 36            }
 37        }
 38
 39        return transaction
 40
 41    def verify_hybrid_transaction(self, transaction):
 42        tx_copy = {
 43            'version': transaction['version'],
 44            'inputs': transaction['inputs'],
 45            'outputs': transaction['outputs'],
 46            'locktime': transaction['locktime']
 47        }
 48        tx_serialized = self._serialize_transaction(tx_copy)
 49
 50        try:
 51            ecdsa_sig = bytes.fromhex(transaction['scriptsig'])
 52            vk = self.ecdsa_key.get_verifying_key()
 53            if vk.verify(ecdsa_sig, tx_serialized):
 54                return True
 55        except:
 56            pass
 57
 58        if 'witness' in transaction:
 59            witness = transaction['witness']
 60            if 'sphincs_sig' in witness and 'sphincs_pubkey' in witness:
 61                sphincs_sig = bytes.fromhex(witness['sphincs_sig'])
 62                sphincs_pubkey = bytes.fromhex(witness['sphincs_pubkey'])
 63                return shake_256f.verify(tx_serialized, sphincs_sig, sphincs_pubkey)
 64
 65        return False
 66
 67    def get_hybrid_private_key(self):
 68        ecdsa_private = self.ecdsa_key.to_string()
 69        return ecdsa_private + self.sphincs_private
 70
 71    def _serialize_transaction(self, tx_data):
 72        return json.dumps(tx_data, sort_keys=True).encode()
 73
 74def ripemd160(data):
 75    h = hashlib.new('ripemd160')
 76    h.update(data)
 77    return h.digest()
 78
 79def create_hybrid_address(ecdsa_pubkey, sphincs_pubkey):
 80    combined = ecdsa_pubkey + sphincs_pubkey
 81    sha256_hash = hashlib.sha256(combined).digest()
 82    ripemd_hash = ripemd160(sha256_hash)
 83    address_bytes = base58.b58encode_check(b'\x00' + ripemd_hash)
 84    return address_bytes.decode()
 85
 86def private_key_to_wif(private_key):
 87    extended = b'\xef' + private_key
 88    first_sha = hashlib.sha256(extended).digest()
 89    second_sha = hashlib.sha256(first_sha).digest()
 90    checksum = second_sha[:4]
 91    return base58.b58encode(extended + checksum).decode()
 92
 93if __name__ == "__main__":
 94    qrb = QuantumResistantBitcoin()
 95    ecdsa_pubkey = qrb.ecdsa_key.get_verifying_key().to_string("compressed")
 96    sphincs_pubkey = qrb.sphincs_public
 97    hybrid_address = create_hybrid_address(ecdsa_pubkey, sphincs_pubkey)
 98    hybrid_tx = qrb.create_hybrid_transaction(hybrid_address, 1000000)
 99    is_valid = qrb.verify_hybrid_transaction(hybrid_tx)
100    sig_size = len(bytes.fromhex(hybrid_tx['witness']['sphincs_sig']))
101
102    hybrid_private = qrb.get_hybrid_private_key()
103    hybrid_wif = private_key_to_wif(hybrid_private)
104
105    print("Hybrid Address:", hybrid_address)
106    print("Hybrid Private Key (WIF):", hybrid_wif)
107    print("Transaction Valid:", is_valid)
108    print("SPHINCS+ Signature Size:", sig_size, "bytes")

Requirements:

pip install pyspx base58 ecdsa

Output:

└─$ python qbitcoin.py Hybrid Address: 1LZv2w5RwJfP85c9WQnVQjmaHdG3C4mvAg Hybrid Private Key (WIF): 4dWNFjZD5mxwcHHrmdVGwN2j7pc8JUtnjuTGS2wXoGoZG5b6JfP5stkv8WfjTabfwrCtYyM1Q9Wfiz4mnDxvfB618JzsvQEg6X1HoyKFMEWwkUStYtkQL6JGti9VWUhC5uEDVPvCcxyGsw9wcZwMQ97zMasXBsjRUbASdJ3TcHSV9zFr5P27Xg9VvvDkyWMXah2YXBoersCFgUzcBfsxUnRiv9HWMihkcE Transaction Valid: True SPHINCS+ Signature Size: 49856 bytes

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

@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.

Quantum Migration BIP #1895

Hybrid Private Key (WIF):

Requirements:

Output: