The lock is a service, not a key

Frozen P2PK and the recovery veil: who picks the lock

Updated 23 October 2026

That is a proof, not a pick. It is not a spend.

What P2PK still is, in 2026

Pay to pubkey was the first output shape Bitcoin ever used. Satoshi mined into it. Hal Finney received into it. A P2PK script holds a single public key on chain and waits for a signature from the matching private key at spend time. There is no address derivation, no hash, no witness. The key sits in the script, in cleartext, in the UTXO set, forever.

That clarity is the problem. A sufficiently capable quantum adversary can read the public key and, given enough stable qubits, derive the private key from it. The runway tracker on catbitcoin.com has been ticking past eleven billion dollars of exposed script for months. Tier 1, the early coinbase P2PK and reused P2PKH, is the load bearing case for any quantum argument. It is also the part of the supply that has been dormant the longest, with addresses that have not signed in well over a decade.

The good news, if you can call it that, is that immobility helps. A box that nobody has spent in seventeen years is a box that nobody has signed against either. There is no signature history, no public nonce reuse, no side channel. A quantum attack on a P2PK output only needs to recover one key, then it needs a destination and a fee. The destination and the fee are easy. The key is the part that needs qubits.

The recovery veil, named properly

Recovery veil is the term some 2026 working notes use for a third path between two extremes. The first extreme is do nothing: coins stay locked, eventually a quantum adversary with a sufficiently large logical qubit count recovers the key, and the box spends. The second extreme is a hard fork that reallocates frozen coins to provers of work or to burn addresses, on the argument that the original keyholder has, by silence, abandoned the box. The veil sits between them.

A veil is a paper, signed by a recovery provider, that says this address has been registered, the holder has demonstrated control of auxiliary material beyond the public key, and the provider will only release a covering signature if the holder produces the right witness. In custody language it is closer to a notary than to a custodian. The provider never touches the private key. The provider never sees the spend. The provider only vouches, in a way that the network can later check, that the human behind the address is who they say they are.

This is a different model from BIP 360's cover scheme. The BIP 360 cover proposes a script level commitment that locks the box against quantum recovery for a defined window, paid for up front, with a post quantum signature as the new spending condition. The veil does not change the box. The box still pays to Satoshi's old public key, with the same script, in the same UTXO. The veil is a side document that a future federation, a future court, or a future fork could choose to honour, and a future adversary could choose to ignore.

That asymmetry is the point. A veil costs nothing on chain. It costs the holder a registration fee, an identity proof, and an ongoing subscription. It costs the provider a signing key that, in the worst case, will be used once. It costs the network nothing, because nothing moves until somebody produces a real signature against the real script.

Why a veil, not a key

There is a quiet category error in 2026 coverage of quantum recovery. Coverage keeps framing the question as how do we open the box. The Bitcoin question is sharper. The box does not need to be opened by anybody. The box needs to be defended against a particular kind of opening, namely an opening by an adversary who found the key by computation rather than by custody.

A veil does not defend by moving coins. A veil defends by adding a counterparty. If a quantum adversary recovers the key and tries to spend a covered P2PK output, the spend will be visible in the mempool. The recovery provider can be configured to watch the mempool and, if needed, front run the adversary with a competing transaction that pays to a recovery address. The provider does not need Satoshi's key for this. The provider needs only their own hot key, a high fee, and a connection to a node.

That front run only works if the provider sees the attack in time. With current block intervals and current fee markets, a ten minute window is not a guarantee. With a ten block window, provided by a timelocked companion output that the holder pre signs, the provider has more room. The companion output is itself a P2PK output, but it is a fresh one, paid to a 2026 key the adversary has no map for. The veil, in other words, is not one thing. It is a bundle: registration, a watching service, a hot key, a timelocked companion, and a paper that says all of this exists.

None of which is a key to the original box. All of which is a key to a different box that watches the original box.

The pick problem nobody is solving

If the recovery veil is the soft path and the BIP 360 cover is the medium path, the hard path is still a fork. A fork that reallocates frozen P2PK coins is a fork that breaks a property Bitcoin has held since 2009, which is that the script governs the spend and nothing else governs the script. A veil preserves the script. A cover preserves the script. A fork does not.

The political economy of the fork is harder than the cryptography. There is no consensus algorithm that can tell the difference between a keyholder who has lost their key and a keyholder who is waiting. There is no way to prove disuse without an arbitrary timeout. There is no way to compensate a keyholder who returns after a fork without an opt in list, and any opt in list is a list of exposed keys, which is the worst possible side effect.

What is solvable in 2026 is the narrow case. A holder with a still working P2PK key, a working recovery provider, and a willingness to pre sign a timelocked companion output can move the box into a posture where the adversary's window is measured in blocks rather than in hours. The pick is the provider's hot key, used once, on the day the quantum adversary makes their move. The provider does not pick the original box. The provider picks a different box, in the same block, with a higher fee, to a different script.

That is not a key in the cryptographic sense. It is a service in the operational sense. The veil, properly named, is a service contract. The contract is what moves when the key does not.

What this changes, and what it does not

It does not change the runway number. The runway is still a function of exposed script and a notional qubit budget. A veil does not hide a P2PK key from a quantum adversary; the key still sits in cleartext. A veil only changes what happens when the adversary acts.

It does not change the BIP 360 debate. The cover scheme is on chain, opt in, and costs a fee. The veil is off chain, opt in, and costs a subscription. They are complements, not substitutes. A holder who can afford a cover can afford a veil. A holder who can afford a veil can usually afford a cover, if the cover script is set up in time.

It does not change the threat model for P2PKH. P2PKH hides the public key behind a hash until the first spend. P2PK does not. The veil is a P2PK specific tool because the P2PK case is the one where the public key is already on chain at rest.

What it changes is the conversation. For two years the conversation has been about the box and the key. The veil is the first 2026 proposal that treats the box, the key, and the watcher as three separate things. It is the first proposal that admits the network cannot tell the difference between a keyholder and an adversary without help, and proposes to add the help as a service rather than as a fork.

That is a real news angle in October 2026. It is also a small news angle, because the provider market is thin, the legal status of recovery contracts across jurisdictions is not settled, and the on chain footprint of the veil is exactly zero. The veil is, in the end, a paper that says somebody is watching. The box does not care who is watching. The box only cares which signature lands first.