J. Lopp's Post-Quantum Migration BIP

[Pmalek]

If there happens to be a majority NO to any kind of freezing or mandatory migration, I would not consider any compromise at all with those that propose these things. Let them fork themselves away to their own "Bitcoin Quantum Safe", they take the the BQS ticker. 

I don't think anyone is crazy enough to propose another hard fork and I hope it won't come to that. A split like that can hurt both camps if you get plenty of proponents on either side. A hard fork should be the last option after everything else have been tried. The enemies of Bitcoin would rejoice and support any weakening of the system.

[stwenhao]

Before anyone start thinking about making any forks, new things should be tested first. Which means for example deploying some kind of "quantum testnet", where people could see quantum-resistant algorithms, try to break them classically, measure how many transactions can be confirmed, and how quickly spammers will post JPEGs by using "OP_CHECKQUANTUMSIG OP_NOT" or similar scripts, and so on.

[ABCbits]

Am I missing something or did you not read the original post? That is the key point of the whole proposal. To be precise you can't force someone to migrate per say but by disallowing the spending of previous signature types you are in practice doing just that, forcing them to migrate or lose their coins.

Yes, apologies.  What I meant is that some of us are not in favor of a "mandatory migration", but rather an optional one.  To not freeze any coin, but leave them on the fate of their security.  

All clear now! Yes I agree with you even if I mentioned a last resort compromise in my previous proposal. It really depends on how this "war" will play out within the community. If there happens to be a majority NO to any kind of freezing or mandatory migration, I would not consider any compromise at all with those that propose these things. Let them fork themselves away to their own "Bitcoin Quantum Safe", they take the the BQS ticker. 

FWIW the community can accept addition of new QC-resistant cryptography and address alone, but later reject follow-up change/fork they don't like. In past, SegWit got activated but SegWit2x never got activated[1].

Before anyone start thinking about making any forks, new things should be tested first. Which means for example deploying some kind of "quantum testnet", where people could see quantum-resistant algorithms, try to break them classically, measure how many transactions can be confirmed, and how quickly spammers will post JPEGs by using "OP_CHECKQUANTUMSIG OP_NOT" or similar scripts, and so on.

Looking at past, Bitcoin developer already does such thing. For example, there were test network for SegWit called SegNet[2]. I don't remember whether there were dedicated test network for Taproot or other changes though.

[1] https://bitcoinmagazine.com/technical/now-segwit2x-hard-fork-has-really-failed-activate
[2] https://bitcoinmagazine.com/technical/segregated-witness-deployed-on-new-bitcoin-testnet-segnet-1452277172.

[FFFFKeyGen]

I support Phase B and agree with this statement:


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

I believe that keep having both quantum-vulnerable and quantum-safe scripts could seriously undermine Bitcoin's overall trustworthiness.
If malicious actors with access to quantum computers steal coins, even with various blockchain analysis tools available, none of them perfectly prevents launderings, and attackers would likely succeed in laundering the stolen funds.

This could lead to Bitcoin losing public trust - creating a lose-lose situation for both society and the Bitcoin community as a whole.
There has been some academic research conducted on signature transition procedures, and long term unforgeability of signature is obviously one of the critical requirement of persistent blockchain.

[1] M. Sato and S. Matsuo, "Long-Term Public Blockchain: Resilience against Compromise of Underlying Cryptography," 2017 26th International Conference on Computer Communication and Networks (ICCCN), Vancouver, BC, Canada, 2017, pp. 1-8, doi: 10.1109/ICCCN.2017.8038516
[2]L. Meng and L. Chen, "An Enhanced Long-term Blockchain Scheme Against Compromise of Cryptography," Cryptology ePrint Archive, Paper 2021/1606, 2021.

[Pmalek]

If malicious actors with access to quantum computers steal coins, even with various blockchain analysis tools available, none of them perfectly prevents launderings, and attackers would likely succeed in laundering the stolen funds.

This could lead to Bitcoin losing public trust - creating a lose-lose situation for both society and the Bitcoin community as a whole.

Bitcoin's security would be impacted and people would lose trust in the network. However, the solution proposed in this BIP doesn't increase trust in Bitcoin either. It doesn't look trustworthy if a decision is made that your coins will become non-spendable in the future.

It's not good either way.

[FFFFKeyGen]

Bitcoin's security would be impacted and people would lose trust in the network. However, the solution proposed in this BIP doesn't increase trust in Bitcoin either. It doesn't look trustworthy if a decision is made that your coins will become non-spendable in the future.

I believe this is why Phase C was proposed:

Users with frozen quantum vulnerable funds and a HD wallet seed phrase can construct a quantum safe proof to recover funds.

This phase is designed to preserve trust in Bitcoin by ensuring that users don't permanently lose access to their funds.
I think phase C should be mandatory rather than optional, as it provides a safeguard that maintains the network's trustworthiness while addressing quantum vulnerabilities.

[Pmalek]

I believe this is why Phase C was proposed:

Users with frozen quantum vulnerable funds and a HD wallet seed phrase can construct a quantum safe proof to recover funds.

This phase is designed to preserve trust in Bitcoin by ensuring that users don't permanently lose access to their funds.
I think phase C should be mandatory rather than optional, as it provides a safeguard that maintains the network's trustworthiness while addressing quantum vulnerabilities.

I think Phase C or a better variant of it should be mandatory as well if the community agreed to go along with this proposal. But there is a big problem and it's mentioned in the part that you quoted. The recovery proposed would only work for wallets with HD wallet seed phrases. This excludes satoshi and satoshi-era coins. They would remain unspendable even if Phase C became mandatory. In those days we didn't have HD (Hierarchical Deterministic) seed phrases. You needed a backup of each individual private key whose address you used.

That private key alone wouldn't be enough proof that you are the legitimate owner of that bitcoin because a quantum computer could also brute force that same key. And Bitcoin doesn't care. 

[Medusah]

This could lead to Bitcoin losing public trust - creating a lose-lose situation for both society and the Bitcoin community as a whole.

And how is freezing those coins anyhow different?  In both cases, people lose access to their coins.  This, also, undermines trustworthiness.  Imagine going into your wallet after 5 years and realizing your transaction is invalid, because bitcoin "upgraded" to rules that consider your coins "too dangerous" for the network to have them vulnerable. 

This phase is designed to preserve trust in Bitcoin by ensuring that users don't permanently lose access to their funds.

And what about paper wallets?  Or bitcoin wallets that weren't generated using some HD standard?  Or timelocked coins?  Or any coin sitting on a public key? 


Freezing coins provides no benefit to the network, as a whole.  Only potentially to bitcoin holders, as the supply of money declines.  If coins are not frozen, then there's a time period during which a quantum attacker might be able to recover many of them.  This will result in victim holders losing access to their coins, and non-victim holders losing purchasing power.  If they do get frozen, victim holders still lose access to their coins, and non-victim holders might not lose purchasing power.  The only difference is that in the latter, pro-freezing scenario, we make sure that every single victim holder, with coins sitting in quantum-unsafe addresses, will certainly lose access to their coins long before a quantum attacker appears; we are precautionarily violating their property, which is something deeply against the philosophy of bitcoin, in my opinion.

[Pmalek]

Jameson Lopp took part in a podcast where he talked more about the threat of quantum computing and this BIP proposal with the host Pete Rizzo. It's a 45-min podcast and you can watch it below if you are intereted:
https://x.com/SupplyShockBW/status/1948749357316276516

Jameson talks about how the network can't afford to wait until quantum computers become an unpredictable threat and that the Bitcoin community needs to plan ahead. He talks about quantum computers becoming a global phenomena in the future. Even if the US managed to regulate the development somehow, there is nothing they can do to stop Russia or China, for example, to do the same. Jameson doesn't believe QCs are anywhere near to breaking Bitcoin's cryptography at the moment but it's impossible to predict future advancements.

On the current quantum-resistant algorithms, Lopp doesn't believe any is good enough for Bitcoin. He even said "they suck" if I remember it correctly. They take up too much space. The signatures and keys are longer and they are slower to verify. He clarified that the idea of the BIP is not to choose a post-quantum algorithm, but how to get the community to migrate to a new system asap after one is chosen.

He mentioned satoshi's coins as an example. He said that freezing his coins violates the principles of Bitcoin but if they didn't migrate, quantum computers might steal them eventually, dump them on the market, and harm Bitcoin as a whole. It feels like he is saying if we do something, it's bad but if we don't do anything it's also bad.   

[Medusah]

On the current quantum-resistant algorithms, Lopp doesn't believe any is good enough for Bitcoin. He even said "they suck" if I remember it correctly. They take up too much space. The signatures and keys are longer and they are slower to verify. He clarified that the idea of the BIP is not to choose a post-quantum algorithm, but how to get the community to migrate to a new system asap after one is chosen.

These are the proposed solutions:

The least worst, in my opinion, is FALCON-512.  Easier to verify (0.6x), and "only" 10x in size, in comparison with Schnorr.  It will be 24x slower to sign it, but that's completely fine, IMO.

[ABCbits]

On the current quantum-resistant algorithms, Lopp doesn't believe any is good enough for Bitcoin. He even said "they suck" if I remember it correctly. They take up too much space. The signatures and keys are longer and they are slower to verify. He clarified that the idea of the BIP is not to choose a post-quantum algorithm, but how to get the community to migrate to a new system asap after one is chosen.

These are the proposed solutions:

FYI source of that image is https://chaincode.com/bitcoin-post-quantum.pdf page 18.

The least worst, in my opinion, is FALCON-512.  Easier to verify (0.6x), and "only" 10x in size, in comparison with Schnorr.  It will be 24x slower to sign it, but that's completely fine, IMO.

According to https://falcon-sign.info/, FALCON-512 can perform 5948.1 signing per second on i5-8259U CPU. No one would notice 2ms to perform signing.

[Satofan44]

He mentioned satoshi's coins as an example. He said that freezing his coins violates the principles of Bitcoin but if they didn't migrate, quantum computers might steal them eventually, dump them on the market, and harm Bitcoin as a whole. It feels like he is saying if we do something, it's bad but if we don't do anything it's also bad.  

That's right. It is primarily a question of which action will lead to the least amount of harm. I believe leaving them as they are probably will do less harm, but nobody can know this for sure. If they are claiming otherwise, they are lying.

The least worst, in my opinion, is FALCON-512.  Easier to verify (0.6x), and "only" 10x in size, in comparison with Schnorr.  It will be 24x slower to sign it, but that's completely fine, IMO.

According to https://falcon-sign.info/, FALCON-512 can perform 5948.1 signing per second on i5-8259U CPU. No one would notice 2ms to perform signing.

Signing speed is practically irrelevant compared to verification speed at least in terms of the traditional concerns relating to scaling the chain, I agree. That said, the size of FALCON-512 signatures is insane. To keep similar throughput capabilities we'd need to increase the block size several fold. This is one of the reasons why I said this won't be easy. Even if you strip away the controversial freezing and determine that FALCON-512 is in fact the best, it would require a block size increase which is yet another controversial topic. It further complicates the delicate situation.

[Medusah]

This is one of the reasons why I said this won't be easy. Even if you strip away the controversial freezing and determine that FALCON-512 is in fact the best, it would require a block size increase which is yet another controversial topic. It further complicates the delicate situation.

The alternative to using FALCON-512 would be to waiting indefinitely until an entire new signature algorithm is penned, which might produce smaller signatures.  Seems like a dead end, where we have to change mining economics by increasing the block size, or we fall short on security.

[Satofan44]

This is one of the reasons why I said this won't be easy. Even if you strip away the controversial freezing and determine that FALCON-512 is in fact the best, it would require a block size increase which is yet another controversial topic. It further complicates the delicate situation.

The alternative to using FALCON-512 would be to waiting indefinitely until an entire new signature algorithm is penned, which might produce smaller signatures.

We just might have to wait a little longer, but you are right that waiting does not guarantee that we will get an algorithm that produces much smaller signatures than FALCON-512 while still ticking off the remaining boxes.

Seems like a dead end, where we have to change mining economics by increasing the block size, or we fall short on security.

You mean to say that adapting these much larger signatures will cause a collapse in security unless we increase the block size, right? At first glance it seemed to me that you are trying to say that changing the block size changes the mining economics, which I don't agree with.

[stwenhao]

Seems like a dead end, where we have to change mining economics by increasing the block size, or we fall short on security.

1. Block size increase is not necessary. Also, quantum things can be put in yet another space. Witness data is never processed by legacy nodes, so maybe quantum signatures should never be checked by non-quantum nodes.
2. It is possible to use Proof of Work, to do transactions between quantum-safe chain, and the current system. But to get there, at least a quantum test network should be deployed somewhere, to make it exchangeable between current testnet, and quantum-safe testnet.
3. Different algorithms can be tested in different subnetworks (or they can be present in the same one, to compete with each other, but I'm not sure if that competition will be fair). Then, it can be tested in practice, what exactly do we need: smaller signatures, faster verification time, or something else will turn out to be more important than that. Because for now, there is no clear winner, so by deploying N algorithms in some testnets, it should be at least possible to measure, what is the most important thing. For example, now we don't know clearly, if verification speed is more important than signature size.

The alternative to using FALCON-512 would be to waiting indefinitely

There is no need to wait. For each algorithm in the table, there should exist at least one place, where it can be battle tested. And if better algorithms will appear, before quantum canaries will alert us, then we can switch into them, if it won't be too late. But the current candidates should be alive in some test networks now, so some statistics from real test network could be collected.

[mindrust]

This proposal translates like a bank statement.

-

Hey you have an inactive account at bank bitcoin. If you don't move your funds in xxx days, your account will be deleted and recovery won't be possible.

Cheers,
Jameson Lopp

-

Me no likey.

What's the solution then? Can't find. Maybe quantum fud wasn't all fud at all. Time to panic?

@ABCbits: Thanks for the context, I vaguely remember that part of the blog post. But I think this isn't that important. What I think is, to say it bluntly, that Lopp and those agreeing with him are simply greedy and want to contract the supply even more, for Bitcoin to moon even faster. We don't know if (most) lost coins are really lost, and thus we don't know if there was a donation. So if the coins return to circulation we also can't say that this was a theft.

You got it. They've spent too much time on X and similar platforms and their brain gets corrupted by shitcoin propaganda. Occasionally you see people these days also doubting the security model of Bitcoin precisely because of this, even though there is yet not a single sign that it will be a problem. Anyhow, another unfortunate (even if minor) side effect of this kind of locking is that it would put an end to those happy "I've found Bitcoin in a 10 year old wallet" stories.   I love those.

When the signs are visible to the public, it will already be too late.

And J. Lopp is talking about it it means the threat is real. Shit.

[Medusah]

You mean to say that adapting these much larger signatures will cause a collapse in security unless we increase the block size, right?

No, I mean that we could not upgrade at all, and leave quantum computing be a threat. I don't see this happening, but it's also another option.

At first glance it seemed to me that you are trying to say that changing the block size changes the mining economics, which I don't agree with.

I hadn't thought of introducing a new field as stwenhao said, or changing the witness field we currently have. Maybe it's possible to increase the absolute block size without interfering with mining economics.

What's the solution then? Can't find. Maybe quantum fud wasn't all fud at all. Time to panic?

It might be a FUD that it will be a threat anytime soon. The problem is that, after many years, it might be too late until the whole network upgrades and endorses the protocol changes. It takes a hell of a lot of time to get consensus in bitcoin. We need to upgrade in the next years, but keep migration optional, if quantum computers do not prove to be threatening.

[Pmalek]

This proposal translates like a bank statement.

-

Hey you have an inactive account at bank bitcoin. If you don't move your funds in xxx days, your account will be deleted and recovery won't be possible.

Cheers,
Jameson Lopp

It sounds bad but the alternative isn't so good either. Imagine coming back after 20 years of inactivity only to find your old P2PK outputs stolen by a computational threat that could have been avoided. The biggest fault is still with the users for not doing something about it already. But we also have to assume that there are many old-timers who are gone, just like satoshi (assumedly), so there is nothing that they can do. 

It takes a hell of a lot of time to get consensus in bitcoin. We need to upgrade in the next years, but keep migration optional, if quantum computers do not prove to be threatening.

And run the network with two algorithms simultaneously? One being the classical quantum-vulnerable one and the second the optional post-quantum one. 

[stwenhao]

And run the network with two algorithms simultaneously?

Not the first time. We have ECDSA and Schnorr signatures. Two algorithms simultaneously. Not to mention OP_SHA1, OP_SHA256, and OP_RIPEMD160, which can be used in the same Script. You can say it is far from ideal, but every 160-bit address already use a combination of two algorithms: SHA-256 and RIPEMD-160. So, if new signatures will be a combination of ECDSA and quantum, then it will be nothing new.

In general, I think every OP_CHECKSIG call should be handled in the same way as today, and then, any quantum-safe things should be committed into that (and not be processed by today's nodes, but only by upgraded ones). Then, blocking old way of spending can be done by just requiring more conditions: you will need ECDSA signature today, and ECDSA+quantum signature in the future. Because many people think about only upgrading from ECDSA to quantum, but I think downgrade should be prepared as well, if some new algorithm will be broken classically, or if any other weakness will be detected (and then, if ECDSA won't be broken, then it may still keep coins safe, and allow moving them to yet another algorithm).

[d5000]

Looking at the SQIsign I algorithm, which has "palatable" signature sizes but an astronomically high verification cost, I got the following shower thought: Could it be possible to introduce a post-quantum option based on optional verification?

Basically how today OP_RETURN tokens like Counterparty or Runes work: miners and full nodes would not need to verify the transactions. Instead it would be the users when they transfer and/or accept these coins; they would verify that there's a coherent chain of signatures until a point where an "old style Bitcoin" was burnt and exchanged to a "post-quantum Bitcoin" (a bit similar to how Counterparty was distributed originally).

Once hardware speeds have accelerated to the point that verification is no longer a problem, the verification could be turned mandatory again (i.e. a proof of verification added to the blocks), at the same time those "tokens" would then be recognized as "real Bitcoins".