What's the Plan For a Post-Quantum Soft-Fork?

Hello. My name is Aaron van Wirdum. I'm a Bitcoin journalist of over ten years and author of The Genesis Book. I'm not a cryptographer, let alone a quantum researcher. I know next to nothing about it. I know a little bit more about how Bitcoin can handle it, or not. Fortunately, I have a very well-informed panel with me, and I'm going to try to guide you all through their thinking.

​

I'll let the panelists introduce themselves. Let's start here with Ian.

​

I started off with cryptocurrency and learned about Shor's algorithm in 2002, but I did not publish the research that I had. I should have, because it was bad, and maybe people would have learned from some of the mistakes they're making today. Shor's algorithm is something that I've followed up with every few years, and I just tried to keep up on quantum. In 2024, I read more papers, freaked out, and switched full time to quantum safety.

​

I'm Christian Papathanasiou. My background is cybersecurity, 20-odd years. About two years ago, I was thinking about how to hedge the quantum risk. What can I do to secure Bitcoin? What are the biggest threat scenarios that would absolutely kill Bitcoin? One of those that stood out was quantum. So I started going down that rabbit hole and learning as much as I can. Ultimately, I created a sidechain, which I call QTC, which implements post-quantum cryptography in order to secure Bitcoin.

​

I'm Mike Casey. I am formerly with MARA, where I headed up the Anduro group. We spent the last year working on quantum initiatives, including incubating BIP 360, and I am a coauthor on Hourglass.

​

Hi, I'm Jonathan Bier. I published a book called The Blocksize War, which is about a battle in Bitcoin from 2015 to 2017. Like Aaron, I really had no idea about quantum computers. I read some papers, but I don't really understand what they are or when they might happen. But I am interested in upgrading Bitcoin, so I can talk about that side of it.

​

Okay, let's start with that last point, because there is a lot of disagreement, it would appear. I don't know if there is going to be a lot of that on this panel. We'll see. But how imminent is this threat really? I've seen estimates ranging from this could become a real problem within a year or two, to this is at this point pure science fiction and nowhere near worth talking about. Where do you stand on this?

​

First off, the people who make the quantum computers are saying that they're going to have sufficiently sized computers available in 2027 and 2028, depending on the manufacturer.

​

Just to be clear, this would be sufficiently sized to break elliptic curves at 256 bits?

​

Yes. 2027 is what they've said on their roadmaps. I don't necessarily believe the companies, but I think that's a good point at which we should say this is where the risk begins. If they haven't built it yet, then there's no risk. When they say that they can build it, and they're destined to have it built on their roadmap, that's when we should at least begin the clock for a very low risk percentage. Then each month after that, the risk goes up.

​

There were over 45 companies making these machines in 2024. Of those 45 companies, three had roadmaps targeting 2027, and then two of them moved to 2028. In 2028, you're looking at about ten companies that are targeting the same sized quantum computers. However, there are now 4,000 companies making parts of these machines, or these machines. My concern is that they might just start gobbling each other up, do a bunch of mergers, bring some innovations in-house that they didn't have, and be able to release quantum computers sooner rather than later. If the mergers start this year, the idea that people are just going to sit around and not make anything for three or ten years is a bit awkward.

​

One quick follow-up question and then we'll move on. It sounds like your assessment is mostly based on their assessment. Isn't it possible that they're just exaggerating to get investments or for whatever reason they might have?

​

IonQ often exaggerates. They claimed that they were going to have income from Shor's algorithm in 2027, which would be elliptic curves at 256 bits. I don't believe them, even though they released a paper last month saying all sorts of innovations. The thing that I think is more plausible are the companies that continue to deliver systems and are targeting 2028. That is, I think, the more likely date. So if I were to bet on one three-month period, I would bet on delays, and those delays would put them somewhere between August and November of 2028. I think they could possibly succeed before then, but I think the risk is very high when a lot of companies are saying we're going to deliver by then.

​

I'm not a physicist. As Ian rightly said, we have to go by what we hear in the market. I've been to multiple conferences where these vendors are present. Some of those conferences are government conferences where they're presenting to closed audiences, and when they are directly questioned on these topics, like how soon, the stakeholders are very worried. It's not only Bitcoin that's affected by this, but all our communications as well, and things that secure our financial system.

​

The audience asks very pointed questions, and their answer is always that they are publicly listed companies, and whatever they put to the market needs to be validated by science. They cannot make false statements as publicly listed companies. Now, you have to take them up on that and hold them against that.

​

We are seeing a lot of consolidation. IonQ seems to be the more bullish one, the one making the most noise in the market. You also have PsiQuantum, which is also extremely bullish in providing almost similar timelines.

​

What people have to appreciate is not so much the timelines. Forget about the timelines for a second. You're ultimately talking about the computational power equivalent of an atomic bomb. This is kind of the Manhattan Project of computing. You have lots of little Manhattan Projects right now that are creating little atomic bombs of computation. They are dual purpose and dual use. They can be used for incredibly beneficial things for society, finding drugs, protein folding, and all sorts of beautiful things. But they can also be used for military purposes and, of course, attacking encryption.

​

We don't know what the timelines are. What we do know is that when there is lots of smoke, there is fire, and we as an industry need to prepare against that.

​

So far, Ian, you're saying two years is plausible. Christian, no estimate?

​

No estimate.

​

I don't think I can give an estimate, but the way I look at it, the National Institute of Standards and Technology has said, and this has been for a couple of years now, that post-quantum cryptography has to be ready for government-interacting systems by 2029. By 2035, you have to sunset any non-post-quantum system. This is per standards. That's their timeline.

​

When I think about quantum research, you have to think the NSA is likely ahead of any private actors at this point. The government may have knowledge of the state that quantum computers are at that isn't available to the general public. That may very well be the case. They may not. I don't know.

​

Is there a concrete reason to think that the NSA is further ahead than the Googles of this world?

​

Funding.

​

There are different efforts that have built quantum computers and have not released specifications on all of them. One project was going to create a quantum computer in Brisbane, Australia. They were courted by the NSA and agreed to create a building inside Chicago. The Chicago construction needed the land sale, building permits, permits for liquid helium, contractors, and approvals, and they got everything done in four weeks and began construction. Then suddenly they had three shifts working in Chicago, which is completely unheard of.

​

The thing is, the NSA appears to be wielding influence on behalf of this effort. They have been doing mass production for two years. These are horizontally scaling two-qubit devices. They plug them into solid steel fridges, cool them down to two Kelvin with liquid helium, and then measure the cold part. They measure the photons with 99.1% accuracy, according to their 2023 specification.

​

It's their algorithms that scared me in 2024, because they didn't need seven million, ten million, or fifty million qubits. They can reuse the qubits and cycle them through these systems that are able to generate photonic pairs, perform calculations on a switch, and then measure the results reliably. That was in their 2024 papers.

​

The question here is just a matter of scale. They're anticipating a one million qubit system by 2028. They could possibly break elliptic curve 256 with around 100,000 qubits without having to do enormous reuse to make that happen. The reason I think they're ahead of the curve, and kind of the darling of the NSA at this point, is that they've been leading all of these things, and they were the first to win most of these awards. Most companies have not been able to get DARPA funding. It's very rare to get DARPA funding. IonQ recently got DARPA funding, whereas this project got it years ago.

​

The only thing they had to do differently was have these photonic switches perform faster. That was their main bottleneck. But they've been mass producing those for months also. So they have everything that they need except the building. We're just waiting on the building.

​

It's important to note that what he was talking about is just one of five different flavors of quantum computing being pursued right now by different factions that have different trade-offs. If any one of them hits in a substantial, scalable way, we could see an exponential increase in the ability to chain these qubits together. On top of that, there have been breakthroughs, or perceived breakthroughs, in error correction. Suffice it to say, it really is anybody's guess. There is a chance it could never happen at all, but the math says it will, and there are more and more engineering dollars going into it every day.

​

Do you feel comfortable putting any sort of timeline on this?

​

For me, it's unclear. My timeframe would be as early as a few years from now, but we could hit unknown roadblocks that could make it not a thing for 15 or 20 years. It's a very, very long window.

​

I have absolutely no idea on the timeline, but I do think it's a very interesting problem. It is worth thinking about how to upgrade Bitcoin to at least give people the optionality of spending Bitcoin in a quantum-safe way. Then the people who are worried about the timeline and are concerned can prepare, and another set of people who aren't that concerned can carry on using Bitcoin in the same quantum-vulnerable way.

​

I actually think a key part of the plan should be Taproot. Taproot was an upgrade to Bitcoin in 2021, and it's pretty neat because you can use a tapscript path where you can have multiple ways to spend Bitcoin, and you can hide different ways behind a hash. A hash is pretty much quantum safe.

​

But Taproot itself is quantum vulnerable because the public key in the key path spend is a Schnorr public key posted directly to the blockchain as an address. Without a soft fork of any kind, Taproot is completely quantum vulnerable.

​

Yes. So you'd need two kinds of soft forks.

​

Let's get more into that in one minute. I have one quick follow-up question on this topic. To what extent would we actually see it coming? Is it one of those fears where now it's here and all vulnerable coins are gone? Or is it more reasonable to assume we're going to see papers and progress, and we're going to have a better idea how long it's actually going to take before it's too late?

​

On the network, it's indistinguishable. All you would see as a common person observing the blockchain would be a sudden movement of coins, nothing else. You wouldn't know who did that. Was it the genuine owner of that wallet, or was it a quantum-enabled attacker?

​

Coming back to the NSA point, the NSA has released a standard called CNSA 2.0. In that standard, they mention that traditional communications shall not use public key cryptography after, I believe, 2030. They also stipulate that of the lattice-based post-quantum algorithms, only ML-KEM version five is approved for top secret communication.

​

Okay, let's move to Bitcoin and upgrading Bitcoin. Jonathan already touched on it, but what are currently the most viable, or in your opinion best, plans to prepare for Q-Day?

​

Maybe first, in what way is Bitcoin actually vulnerable? That's a good intro.

​

The quantum problem with Bitcoin has a couple of different exposed output types. The first is the Satoshi-era P2PK coins. Notice there's no H on that, because it is not hashed. The original 1.7 million bitcoins that were mined and are left over from the old days of the Satoshi era have the public key exposed on chain, and as such they are vulnerable to quantum attack directly. They store 50 BTC per output.

​

Then you have P2PKH and the witness variant of it for reused coins. If you have a reused address, and by that I mean an address that was spent from, not sent to multiple times, but spent from and then was sent to again afterward, or sent to itself as change, those addresses are vulnerable. In order to spend from it, you have to reveal the public key and the signature. Therefore, they can be reversed by a quantum computer as well.

​

All that represents roughly seven million coins total, so about a third of the full supply. The 1.7 million for P2PK is one class. Then the smaller one would be Taproot, because Taproot natively puts the public key on chain, or at least the x-only variant of the public key. The same thing applies. That's due to the key path spend of Taproot, which makes all the tap tweak functionality possible.

​

Those are the vulnerable types. There's also bare multisig, but nobody uses that. With Taproot, unless you disable the key path spend, it is insecure. By nature it would always have that exposure.

​

What our team proposed is BIP 360, which is pay-to-Merkle-root. Basically, it removes the taproot from Taproot. It no longer has tap tweaking or the key path spend. Instead, you're just left with the MAST tree. You still get all of the masked activity of being able to have multiple key paths or spend paths through the tree, so you can do most of the Taproot functionality. You just can't play the fancy key-tweaking games that are enabled by elliptic curve.

​

What this does is gives us a solid foundation to implement new opcodes, or an override of CHECKSIG, which allows us to introduce post-quantum cryptography directly into Bitcoin for use.

​

Would we lose anything by doing this? For example, with Taproot, one of the nice things is that any cooperative spend can look the same. Would that be lost?

​

You don't have the happy path of the key path spend, but you do have a MAST tree. It doesn't look like a traditional one if you use the happy path. You're forced to use the tree, but only the path on the tree that you actually use is revealed. You're unaware of any other paths.

​

So we would lose that property?

​

Yes, you would lose the happy path key path spend property where it looks like just a normal non-Taproot transaction. But the great thing about that tree is that you can have one branch that is quantum safe and one branch that is quantum vulnerable.

​

Correct. You can continue to use Schnorr with the new address types and maintain all the very preferable characteristics of Schnorr signing until such time as there is a quantum event, at which time you would switch over to the quantum-protected ones, which are much heavier.

​

Exactly. So you're preparing for the quantum risk while still getting all the benefits.

​

Correct. The big difference between Taproot and this is that with Taproot, if you implemented all that today, you would still have to take another additional step in the future of disabling the key path spend. For some people, that would be another soft fork. It might be confiscatory for some people if they were relying on the key path spend, because maybe now you can't get the coins out.

​

Let's get to that topic in a bit. First, with what you're describing, BIP 360, is anyone on the panel against it? Are there any problems with rolling this out tomorrow?

​

It's a fantastic proposal, 100%. It's an immediate solution that we can implement. There are two parts to migrating and implementing quantum security into the Bitcoin protocol. BIP 360 does not itself create quantum-safe address outputs. That would potentially be in the form of a second BIP that would define how quantum-safe outputs can be created, or quantum-safe signatures on the Bitcoin protocol, potentially using a witness version three.

​

That could use hash-based signatures, like SPHINCS or something like that. There is a very cool proposal by Jonas Nick from Blockstream right now about hash-based signatures. The concern around hash-based signatures is that they have a state variable. If you reuse a hash-based signature, you effectively compromise your entire wallet. Sometimes that could work well on a hardware wallet, but sometimes it doesn't work well on, let's say, a laptop that gets formatted. You may end up reusing one of your signatures and then compromise your coins.

​

Of course, lattice-based signatures are not as thoroughly tested, so that's a concern. There is a big preference for hash-based signatures. The problem with hash-based signatures is that they're so big. Lattice-based ML-DSA right now verifies as fast as ECDSA. So we're likely going to see a second BIP come out that talks about how to add quantum-safe spending on Bitcoin.

​

Just to be clear, the difference here is there are coins in addresses, and that's what BIP 360 solves, basically.

​

BIP 360 provides an upgrade path to a future soft fork that would introduce a quantum-safe signature type. Or you could combine them and introduce a safe signature type.

​

And that is needed for when you actually spend the coins.

​

There is much debate as to what type that will be, but yes.

​

My concern is that it's basically three BIPs, and it takes a long time to get BIPs passed. So I'm concerned that it may just be too late. There are other alternatives that are available now. They're expensive and slow. For example, quantum-safe Bitcoin requires about $150 worth of GPU time to create a Bitcoin script that has certain properties. Every single path inside that script needs to have a compatible output, which means it has to match the cryptography requirements. It's expensive to create those outputs. They are not completely tested yet. No one has actually spent one.

​

There are other types of vulnerable Bitcoin addresses and output types. One of them is pay-to-script-hash. If there is a public key in the script, that public key may eventually have a balance that can already be solved by a quantum computer when it arrives. If the payment happens later, then they're able to drain the payment as soon as it arrives.

​

Another one that is quantum vulnerable is Lightning. There have not really been any BIPs or proposals around Lightning. Our team has talked about methods of making Lightning quantum safe. It needs to be a BIP. There need to be more BIPs involved, and we need to pass them faster, implement the code, and make these things live sooner rather than later.

​

The last output type is every time there is a fork and you spend the fork, like if you just got an airdrop of Bitcoin Cash and spend it, that reveals your public key on Bitcoin. We need to have a method of providing the ability to spend or claim coins on forks that does not reveal your public key on Bitcoin.

​

That would probably involve one of the other proposals involving a STARK based on the seed, which is a long-term proposal. There are other proposals where you commit to an output and then reveal the commitment later on. It's like saying I'm going to have a receipt that looks like this, but I'm not going to give my credit card until it's time to actually pay for the goods. They approve the receipt in advance, and then you show your credit card, and then it's charged. There is no vulnerable time for them to redirect the transaction halfway in between, which is what we call a short attack.

​

Eventually, all Bitcoin using elliptic curves becomes vulnerable. This is rumored to happen years after the first break, but from my studies I think it is closer to the three to nine month mark after the first break. Three months if it's photonics or superconductors. I don't think superconductors will do it, but around nine months for trapped ions and neutral atoms. The other quantum computers have not been produced at scale, so I'm ignoring things like nitrogen vacancy diamonds and things like that.

​

Those all have well-known scaling and networking methods. As soon as you can provide either scaling, just making more on the same machine, or networking, connecting four of them together, you've turned an eight-hour long attack into a 15- or 10-minute short attack.

​

On this panel, the general consensus seems to be better safe than sorry. There is no real harm in getting Bitcoin quantum resistant through BIP 360, for example. Jonathan, do you concur with that? Do you foresee this as a smooth upgrade, or do you foresee another blocksize war type of future with this stuff?

​

I don't know. The one argument against doing BIP 360 now is, of course, there is no way that anyone could use BIP 360 today in a quantum-safe way. So the argument is you don't activate BIP 360 yet. You wait until you've decided on some quantum-safe signature.

​

BIP 360 would make the masked attributes of Taproot resistant to long-exposure attacks. That's the one thing it does do. It does not protect against short exposure, where I broadcast the transaction. But unlike Taproot, which has the public key posted to the blockchain, what it would do currently is allow you to use Merkle tree functionality without exposing your private key for a long time.

​

So you could use the Merkle tree functionality and have the same security as pay-to-public-key-hash.

​

Correct. That's the one advantage we give you without having a post-quantum scheme, which does protect you for a little bit longer from a quantum-vulnerable world.

​

Yes. In terms of upgrades, it is a very controversial topic, but I don't think it should be that controversial just to add a quantum-safe way to spend Bitcoin. If you think the quantum stuff is all just FUD and science fiction, similar risks to a time machine going back in time and stealing Bitcoin, you don't need to worry about it. You can just carry on using Bitcoin in a quantum-vulnerable way. Somebody else using Bitcoin in a quantum-safe way shouldn't be your problem. At least from that perspective, hopefully it won't cause a war.

​

The other big issue is the quantum freeze. I would say we should not worry about that, or argue about that, at least until we have a quantum-safe way to spend Bitcoin. What is the point of arguing about a freeze if, at the moment, everyone who uses Bitcoin and spends it is quantum vulnerable to a certain extent? Only once there is a quantum-safe way to spend Bitcoin, and people are using it, and there are millions of coins that are quantum protected, only at that point is it even worth considering or talking about a freeze, in my view. Before then, we should just ignore that issue and not let it cause an argument or a split.

​

That's the next topic I want to get into. What do we do with all these coins that are currently vulnerable if there is a quantum computer? Should we freeze them, or should we just allow them to be taken by a quantum computer, whoever builds the first one? Are there other ways of thinking about it or dealing with that?

​

Along with Ian and Jameson Lopp and a few others, we coauthored BIP 361. BIP 361 talks about how we migrate coins to quantum safety, and it proposes three phases. The first phase is, let's prevent the problem from getting worse. Let's prevent people from sending to old vulnerable addresses, and they should start sending to quantum outputs.

​

That in itself would be a soft fork, correct? It would make it invalid on the protocol to even send bitcoins to a quantum-vulnerable address.

​

Correct. A previous address, like P2PK, could send to a quantum address, but it could not send to a P2PK address.

​

So first BIP 360, that's sort of the roadmap, and then the next step is BIP 361: only send to these kinds of addresses.

​

Yes. Phase two is five years after activation. We disable the ability to send from elliptic curves. Then from elliptic curves you can only send between quantum outputs.

​

At that point you're really freezing coins for people who didn't move their coins, like maybe Satoshi.

​

Except there is a zk-STARK on your seed. When the BIP went out, everybody on Twitter went crazy and said BIP 361 is proposing to freeze Satoshi's coins. That was never the intention of any of the authors, because BIP 361 itself talks about a zero-knowledge proof ability to prove ownership of a seed phrase.

​

But Satoshi doesn't have that.

​

Exactly. Seed phrases, BIP 39, only applied after a certain point and don't apply to Satoshi's coins. For those, what we were discussing is maybe there is a commit-reveal scheme that can happen. We're trying to come up with all the ways that even if somebody was not able to migrate in time, they would still have solutions available to them, regardless of the output type, to be able to migrate even after the deadline. That was the intention of the authors. It was never to freeze anybody's coins so long as they take the steps at whichever point they want.

​

However, if a person's coins have already moved, there is no way, technically speaking, for people to know if those coins moved using a quantum computer or by the genuine owner of those coins. But if your coins have never moved whatsoever on the chain, then there will be methods to recover them.

​

There is lots of discussion right now on the Bitcoin mailing list. Somebody has actually successfully created a zero-knowledge proof for seed phrases, and that is a very positive development that has come much sooner than we thought. Now it just remains the second part of the equation: how do we migrate Satoshi's coins, or how do we give tools to people who have P2PK outputs to migrate them when they so wish?

​

I don't think that's possible for the P2PK set because they're randomly generated. It's only possible if they take mitigating action before the first quantum break.

​

Exactly. That's the only way. Otherwise, once they're frozen, they're frozen forever.

​

There is another approach. My concern is that the freeze will probably include Q-Day somewhere in between this slow period, this period between BIP 360 and the freeze. If Q-Day happens during that time, then they can just drain all of those coins. If they have the ability to do a fast attack as well, then they gain even more of the coins.

​

The first seed phrases began around 2014. It was 2013 when P2PK was deprecated, saying we shouldn't use this anymore, and it took some time before the wallets shifted. There is a lot of catastrophe for old wallets possible if they are unwilling to migrate before Q-Day. If they migrate after Q-Day, it's probably just a quantum computer doing it instead.

​

This is what I consider good trolling. I did not really think BIP 361 was going to be a technical proposal. The reason I thought it was a bad technical proposal is that all the timelines are way too long. There is too much time for a quantum computer to go in there and yank the coins. Then they have quantum-safe coins, or they sell them, or whatever.

​

The second reason why I think it was good trolling is that, at the time it was written a year ago, everyone was still talking about quantum computers doing mining, which thankfully no one is talking about today, because it would take about 5% of the output of the sun to do last year's difficulty curve on a quantum computer at six watts per qubit.

​

The other reason I think it was good trolling is that it moved the discussion forward. We're now actually talking about it. I don't think it's as good of a proposal as Hourglass.

​

Is it okay if I talk about Hourglass?

​

Yes, go for it. We have a couple of minutes left.

​

The two schools of thought on what to do with the P2PK coins that are susceptible, generally speaking, have been the liquidation view, which is not your keys, not your coins: if somebody has the coins, they have the right to send those coins. Then there is the confiscation view, which is primarily a coin-preservation view, saying we must conserve this and freeze Satoshi's coins in order to preserve the sanctity of the Bitcoin value proposition. These two are night and day different.

​

There is another proposal that 100 BTC and I put forward called Hourglass. The current version of Hourglass is that rather than letting it run loose, or freezing it as confiscation, it is a restriction. You restrict it down to a single BTC output per block. We ran the math on one BTC, one output per block. In the latest version, it's one output and one BTC from that output, and the rest is sent back to the original address.

​

That way, it's only one BTC output per block. If you do nothing, then somebody, if they had all the keys, let's say they had an advanced photonic quantum computer and they could crack all of the keys, could clear it out by mining it in under three hours worth of blocks. It would take them that long to claim 1.7 million Bitcoin.

​

With Hourglass in place like that, the same action would take over 32 years. But it is still non-confiscatory, because if Satoshi or any one of the early miners found their keys, in the absence of a quantum attacker constantly bidding up the value for these, which is now a new limited scarce supply, they would be able to reclaim their Bitcoin in a reasonable manner. For one of these 50 BTC P2PK outputs, given that frame, you could clear out nearly three of them in a day. So to somebody who found this old wallet, they would be able to access their Bitcoin in a relatively reasonable manner.

​

Of course, you wouldn't introduce this thing immediately. You would try to do it with as much warning as possible to give anybody who does want to move their coins prior to a restriction the ability to do so.

​

But this would also be a soft fork in itself?

​

Yes, of course.

​

Any final thoughts? We have 30 seconds left.

​

It's a great proposal. Right now, it is technically possible to do quantum security on Bitcoin. There are even ways to do it on an L2 level. Blockstream has done it. We've done it as well. What people need to take away is that quantum security on Bitcoin has already been solved. It's just a matter of getting consensus on implementing it.

​

Please stop reusing addresses.

​

With Hourglass, I think we just need to do the migration sooner rather than later. We need to provide all the tools and let people select what tools they want to use. I don't want to pick any outcome for any coins. What I want to do is give everyone the tools to make a decision for themselves, make it as safe as possible, and make it function as well as possible.

​

Okay, well, that's our time. Thanks to the panelists. Give them a hand. I think the next panel is also going to be about quantum, but from a different angle. Thanks, guys.