PACTs: Protecting Your Bitcoin From a Quantum Sunset

An attacker with a powerful enough quantum computer could steal hundreds of billions of dollars of Bitcoin.

To prevent that, the Bitcoin community may someday choose to upgrade the protocol to sunset the ability to spend from addresses with exposed public keys.

Such an upgrade would be controversial, in part because Bitcoin values the rights of dormant holders—including Satoshi Nakamoto himself, who is estimated to hold around $75 billion of Bitcoin in vulnerable addresses—to remain inactive onchain.

If an upgrade sunsets support for those addresses, these dormant holders will be forced to publicly move their coins or let them be frozen. But if quantum computers are coming and we don’t sunset those addresses, those holders will be forced to move those coins or let them be stolen. Either path seems to force long-time holders to give up some of their privacy by publicly moving their funds.

This post proposes a way out of that dilemma, by letting Bitcoin holders protect themselves from any eventual sunset costlessly and silently, without having to publicly move their coins.

The key is that holders can use Bitcoin itself to secretly timestamp their knowledge of their private keys. A future protocol upgrade could then accept zero-knowledge proofs of these Provable Address-Control Timestamps (PACTs) as an alternative path for spending from a sunsetted address.

This protocol could protect the privacy and security of existing Bitcoin holders better than the alternatives. And adopting a standard for these proofs now would help give holders as much time as possible to secure their coins against an emergency sunset, while allowing us to leave the more difficult decisions—including whether a sunset is necessary or desirable—until later.

Background

Recent advances raise the question of whether cryptographically relevant quantum computers (CRQCs) could come sooner than most people had hoped.

There are many difficult questions about quantum preparedness going forward, but the elephant in the room is what to do about the hundreds of billions of dollars of Bitcoin stored in addresses with exposed public keys, and thus vulnerable to theft by CRQCs.

The Bitcoin community has been divided on what to do about this risk. Neha Narula recently wrote a helpful summary of the debate.

Doing Nothing

The default path is to do nothing. This will prove to be the right one if cryptographically relevant quantum computers never arrive, which is a legitimate reason to hold off on the most extreme measures. The rest of this post addresses the other possible worlds—in which we someday hit a point where CRQCs are clearly inevitable, and need to decide whether to undergo an emergency fork.

If CRQCs do arrive before the protocol upgrades, then up to hundreds of billions of dollars of Bitcoin might end up in the hands of attackers. Even if the Bitcoin community were willing to stomach the theft and its effect on the market, the quantities involved would be geopolitically significant, and—particularly if the attacker was a criminal or a hostile nation-state—it could lead to a cataclysmic regulatory blowback on Bitcoin.

Sunset

Another option is a soft fork that eventually sunsets the ability to spend from addresses with exposed public keys, as proposed in the draft of BIP-361.

This path is controversial because it violates an important principle—that people should be able to leave their Bitcoin in cold storage for decades without fear of losing access. But in the scenario where CRQCs are imminent, there is no path where holders who are entirely offline can be assured of keeping their Bitcoin, because their funds are at risk of theft.

However, a sunset poses some significant inconvenience on holders:

First, it would force offline holders to move their coins, which is an expensive and public onchain action. They would have to pay fees, reveal that they are still active, and potentially leak other information about themselves, such as timing patterns, links between their wallets, and even their IP address. For an early holder like Satoshi, this would be a massive revelation—they would have to tell the world that they are alive and still in possession of their keys.
Second, there may only be a limited amount of time for an upgrade. Bitcoin does not yet support post-quantum addresses, and may not adopt them until the quantum threat is clearer. If progress on quantum computers is fast enough, we may end up in a situation where the gap between post-quantum addresses being supported and being mandated is uncomfortably brief.

Rescue Protocols

For the above reasons, it is likely that many holders will fail to upgrade before the sunset date. Will there be a way for them to prove to the protocol that they are the rightful owners of their addresses?

For some addresses, the answer is already yes. For example, if a private key was derived from a parent key (as in the BIP-32 standard), the holder may be able to provide a zero-knowledge proof that they knew that parent key, which is something a quantum attacker could not have. This kind of “rescue protocol” is discussed in BIP-361, and a prototype prover has even been implemented. There may even be ways to delay the implementation of the specific rescue rules until a subsequent fork.

The Satoshi Problem

Those are promising escape hatches, but they can’t save the earliest Bitcoin addresses.

There are millions of bitcoins that have exposed public keys and predate BIP-32 (and which therefore could not be rescued using the above path). Most notoriously, wallets believed to belong to Satoshi Nakamoto hold around 1.1 million BTC, worth over $75 billion today.

This post describes an escape hatch for sunsetting that can potentially provide the best achievable protection for those offline holders—a self-protective measure they could take today, with no changes to Bitcoin and no onchain action, in a way that could maintain their ability to spend after a sunset while still achieving the safety sunsetting would provide from a quantum attacker.

PACTs

Suppose we’re in the year 2040, and Satoshi has decided to fund his retirement by finally selling some of his Bitcoin. Cryptographically relevant quantum computers arrived in 2030, and deriving Satoshi’s private keys is now a standard homework assignment for MIT freshmen. Luckily for Satoshi, the protocol sunsetted the ability to spend from ECDSA keys in an emergency soft fork in 2029.

Satoshi wants to prove, in a post-quantum and algorithmically verifiable way, that he knew his private key before CRQCs could derive it. What can he do?

If he has to generate that proof from scratch today, he is out of luck. Since everyone now knows his private keys, and since he didn’t derive them using BIP-32 or any other deterministic scheme, the keys don’t give him any asymmetric private information he can use for a cryptographic proof.

However, if he can cryptographically prove that he knew those keys before CRQCs could have derived them, then the protocol could let him take the coins. If he had the foresight back in 2026, he could have used a cryptographic timestamping service to timestamp a signature, establishing that he knew the private key before CRQCs existed.

Conveniently, he had already invented a trustless way to timestamp proofs of knowledge back in 2008. The Bitcoin whitepaper described the Bitcoin network as a “distributed timestamp server.” Developers have long recognized that while it was primarily designed for timestamping transactions, it could easily be used to timestamp any hash—and that since hashes can be aggregated efficiently, it is cheap to run a service that provides such timestamps for free. OpenTimestamps is an open-source protocol that allows anyone to timestamp arbitrary hashes on the Bitcoin blockchain, by including them in a Merkle tree within an OP_RETURN output.

If Satoshi had timestamped a salted commitment to a standardized address-control proof before CRQCs using OpenTimestamps, then he could provide a post-quantum-secure STARK proof of that timestamp to the Bitcoin protocol.

A Provable Address-Control Timestamp, or PACT, is just such a timestamped commitment.

Step 1: Commit

The below description is an illustrative example of how the PACT protocol could be designed, rather than a formal proposal. It will require significant input from experts and the community, and feedback is encouraged.

To create a PACT, the holder generates a 256-bit secret salt and uses BIP-322 full message signing to prove control of the scriptPubKey for the vulnerable unspent transaction output (UTXO).

The BIP-322 message should commit to the PACT purpose, Bitcoin network, vulnerable scriptPubKey, and salt:

1

As discussed in earlier drafts of BIP-361, consensus deployment of these phases is subtle. If Phase B permanently declared all legacy-key spends invalid forever, a later rescue path that made some of them valid again would be a hard fork, which has never been done in modern Bitcoin history and is generally considered unacceptable by the Bitcoin community. For this reason, BIP-361 currently proposes including the rescue path as part of Phase B. One possible alternative would be to design Phase B as a temporary freeze with an explicit expiry (after which UTXOs would be spendable again), so a later Phase C soft fork could either extend the freeze permanently or introduce new rescue rules

. ↩

PACT/v1: Bitcoin quantum-sunset proof of address control
network=bitcoin-mainnet
scriptPubKey=<the vulnerable output scriptPubKey>
salt=<32 random bytes>

Let:

salt = random(32 bytes)
msg = Encode("PACT/v1", "bitcoin-mainnet", scriptPubKey, salt)
control_proof = BIP322_FULL_SIGN(scriptPubKey, msg)
commitment = SHA256("PACT/v1 commitment" || salt || SHA256(control_proof))

The holder then timestamps commitment using OpenTimestamps. They store the salt, the BIP-322 control proof, and the OTS proof file in a secure location.

This requires no Bitcoin transaction by the holder and is off-chain. The timestamp reveals nothing about the control proof, salt, public key, address, or which coins the holder owns, though privacy-conscious holders should still protect network metadata when interacting with timestamping services.

Step 2: Rescue

If Bitcoin later sunsets spending from UTXOs with exposed public keys, that fork could also define a rescue protocol for PACTs.

To spend a sunsetted UTXO, the claimant would provide a post-quantum-secure proof (such as a STARK) that:

they know a secret salt and a BIP-322 full message proof (control_proof);
SHA256("PACT/v1 commitment" || salt || SHA256(control_proof)) equals a commitment timestamped before the PACT cutoff, where that cutoff is set before CRQCs are believed to be able to derive private keys from exposed public keys;
control_proof is a valid BIP-322 full message proof for the scriptPubKey controlling the frozen UTXO over the PACT message containing that salt;
the rescue proof is bound to the specific rescue transaction, so it cannot be copied and reused to redirect the coins.

The salt and BIP-322 control proof themselves would not be revealed. The timestamp proves that the holder had the ability to produce that control proof before the cutoff. The transaction binding proves that the holder is authorizing this particular rescue spend.

At a high level, the eventual consensus proof would need to show a complete anchor chain: the hidden salt and BIP-322 control proof hash to the public PACT commitment; the OpenTimestamps attestation carries that commitment through its hash operations into a calendar Merkle root; that root appears in an OP_RETURN output of a Bitcoin transaction; the transaction is included in a block by a transaction Merkle proof; and that block is recognized by the rescue rules as part of the active Bitcoin chain before the PACT cutoff. A practical design would have to specify how the proof, which is verified in the context of a transaction, is anchored to the history of the chain (likely via a recent block hash).

This does not require Bitcoin to decide today whether a sunset is necessary. It only gives holders a silent, no-onchain-cost way to preserve evidence that may become useful if such a sunset is ever adopted.

Benefits

No fork required today. Holders don’t have to wait for Bitcoin to adopt quantum-secure addresses or to decide what to do about insecure UTXOs. As soon as we agree on a standardized format for PACTs, holders can begin timestamping them.
Note that while the commitment protocol for PACTs is relatively simple and makes use of well-established primitives like OpenTimestamps, the protocol for eventually verifying them will not be. Verifying a STARK to allow spending from sunsetted UTXOs will require substantial new plumbing in the Bitcoin protocol.
Silent. Nobody other than the holder knows that the holder made the commitment. Even when the holder spends the coin, they may not have to reveal when they timestamped it—the protocol could require only a zero-knowledge proof that it was early enough.
No onchain cost to commit. OpenTimestamps is free to use and can batch many commitments into a single Bitcoin transaction.
Low risk. While the protocol requires the holder to produce a BIP-322 control proof with their key—which poses some risk—neither the proof nor the salt is broadcast or shared with OpenTimestamps; only an opaque commitment is revealed. The holder does, however, need to protect the salt, proof, and OTS file as a recovery artifact.

Risks and Downsides

The holder has no guarantee that this rescue hatch will ever be implemented. It is possible that Bitcoin will never sunset quantum-unsafe keys (either because CRQCs never arrive, or because Bitcoin decides to bite the bullet on them). Even if it does, it may not implement this specific rescue path. A holder should not solely rely on PACTs for protection until the rescue protocol is adopted into the protoco. But given the low cost of making the commitment, it might still be worth it for a long-term holder to create a PACT as soon as a standard is agreed-upon.
Not universal. While this protocol should work for many single-key wallets and can be generalized using a BIP-322-style proof format, multisig, complex scripts, custodial wallets, and hardware-wallet support would need careful standardization. Additionally, PACTs assume that the ability to produce a valid BIP-322 proof on a very specific message corresponds to the ability to control the coin. That is the same practical assumption behind message-signing proofs, but as discussed in BIP-322, the power to sign messages from an address is not necessarily identical to the power to sign transactions from that address.

Conclusion

Cryptographically relevant quantum computing may not threaten Bitcoin for a long time, or it might never happen. Users might never need to do anything.

But Bitcoin is about preparing for the long term, hedging for tail risks, and self-reliance. If there is a way to plant a seed now that will give us an advantage over cryptographic attackers in a possible future, then long-term holders should take it. And protocol developers should think about the privacy interests of large, long-term, dormant holders—including, possibly, the very largest, longest-term, and most dormant holder—when deciding how to implement a possible quantum sunset.

Acknowledgments: Eli Ben-Sasson, Avihu Levy, Abdelhamid Bakhta, Jameson Lopp, Neha Narula, Nic Carter, Arjun Balaji.