
Quantum runway
Hash only pays to key, even after the deadline lands
Updated 21 October 2026
That is a hash lock. It is not a signature. The November 2026 deadline for retiring classical signature algorithms does not touch it, and watching a P2SH or P2WSH address is a window, not an opening. Never paste a seed into a watch-only field.
The two halves of a Bitcoin box
Every spendable output is a small script the network has agreed to honour. The script asks the spender to satisfy a condition, and the spender hands over a witness that does the satisfying. People talk about keys and boxes as if they were the same thing, but a script usually has two distinct halves, and the quantum threat only reaches one of them.
The first half is the signature. It is a piece of mathematics produced with a private key, checked against a public key, and considered valid by the network as long as the algorithm on the curve in question is not broken. NIST's post-quantum migration deadline lands in November 2026, and from that point, classical signature schemes are formally retired. That half of the box is the half people are afraid of, and rightly so, because a sufficiently large fault-tolerant quantum computer running Shor's algorithm against an exposed public key would derive the private key and forge a signature.
The second half is the hash. A hash is a one-way function. You can run it forwards, and the network can check the answer, but you cannot run it backwards except by guessing, and the guessing cost scales with the digest length. SHA-256 has a 128-bit post-quantum security level against Grover's algorithm, which is enough to keep preimages out of reach for any machine you can plausibly build in the next decade.
When you pay to a hash, you are paying to a script that does not know what private key will sign for it. The script only knows the digest. To spend, the witness has to reveal the preimage. There is no public key to extract, no curve to attack, no signature to forge. The box is closed by a different door.

What a P2SH or P2WSH spend actually proves
Pay-to-script-hash and pay-to-witness-script-hash were the original answer to the problem of long addresses. You commit to a hash of a script, the script goes into the box as a sealed envelope, and the network only learns what the script says when somebody actually spends. Until then, the output looks identical to any other hash commitment, and quantum analysis of the commitment reveals nothing useful.
At spend time, the witness has to do two things. It has to hand the spender's signature, which is the half that quantum threatens, and it has to hand the preimage of the hash plus anything the script demands. The preimage is usually a key itself, but it is a script key, the key that satisfies a nested condition, not the key that signs for the box as a whole. If the nested condition is a signature, then yes, that nested signature is exposed the moment the script is published. If the nested condition is a hash lock, a multisig threshold, a timelock, or a combination, the exposure profile is different and the spending witness has to clear the right one.
What does not change at the November 2026 deadline is the structure of the witness check. A SHA-256 preimage still verifies. A RIPEMD-160 preimage still verifies. A timelock still enforces. The deadline retires the algorithms in the signature half, and the deadline does not retire the algorithms in the hash half, because the hash half is not a signature and never was.
The corollary is that watching a P2SH or P2WSH address from a watch-only wallet is a window, not an opening. You can see the box. You cannot open it. The box opens only when the spender publishes a valid witness, and a valid witness still has to satisfy the script, regardless of what NIST has retired.
Where the exposure actually sits
The classical exposure sits in the reveal moment. When a P2WPKH or a nested SegWit output is spent, the spender publishes the full public key in the witness, and from that moment, a sufficiently powerful quantum adversary has a target. The race is between the network confirming the spend and the adversary deriving the private key from the just-revealed public key. In practice the network wins by ten minutes and a few blocks, but a quantum computer that can derive a secp256k1 key in less than that is the threat the runway counter is counting down.
Hash-locked outputs do not reveal a public key at spend. They reveal a preimage. A preimage is not a key. It is a string of bytes that hashes to a digest the script already knows, and the script only ever had the digest. There is no curve to attack against a preimage, because the preimage is the thing the network checks, and the network checks it by hashing. The only way to forge a hash-locked spend is to find a preimage, and finding a preimage against a 256-bit hash is a Grover problem, not a Shor problem, and Grover does not get you a key.
This is why a box that only knows a hash is a box a quantum computer cannot shortcut. It is not a stronger box than a signature-locked box, and it is not a box that defends against every threat, but it is a box where the threat model has changed. The signature half goes soft after the November 2026 deadline, in the formal sense that the algorithms are retired, and the hash half stays hard, in the engineering sense that the digest length still resists Grover.
What this means in practice is that any output script whose only check is a hash check, or whose only check is a hash check plus a timelock, does not need a post-quantum migration to keep doing its job. The job is proving knowledge of a preimage at spend time, and that proof is the same in 2026 as it was in 2010.
What the November 2026 deadline actually retires
The NIST post-quantum migration deadline is a deadline for the algorithms classical systems use to sign and to key-exchange, not a deadline for the algorithms classical systems use to hash. The three signature finalists published in 2024, ML-DSA, SLH-DSA, and the lattice-based KEMs, are the replacements. They are not hashes, they are not preimage schemes, and they do not substitute for the SHA-256 in your script.
When the deadline lands, FIPS 186-5 stops being a live standard for the algorithms it once defined, and the world's certificate authorities and software vendors are expected to have rotated their signature keys. Bitcoin's consensus rules do not change on that date. The signature opcodes still accept the curves they have always accepted. BIP-360 proposes a new opcode, and BIP-360 has not activated, and BIP-360 does not, on its own, retire the existing signature paths.
What changes is the formal trust posture. Classical signatures, after the deadline, are not the algorithms a careful signer is supposed to be using for new key material. They are still valid on the chain, because the chain does not consult NIST, and they are still produced by every hardware wallet that has not been upgraded, because the upgrade is opt-in. The risk is that an adversary is now building a machine against the algorithms you are still using, with a deadline you have now missed.
For hash-locked boxes, none of that matters. A P2SH spend is a witness reveal, and a witness reveal is a script satisfaction, and a script satisfaction is whatever the script demands. If the script demands a SHA-256 preimage, the witness has to hand a SHA-256 preimage, and SHA-256 is not a signature algorithm and is not retired by the deadline.
Practical advice for someone holding a hash-locked box
First, audit the script before you trust the box. A P2SH address is a commitment to a hash of a script, and the script can demand anything, including a single-key signature check. If the script demands a signature, then the box is exposed the moment the script is revealed at spend, and the hash lock is a wrapper, not a defence. If the script demands a hash preimage, the box is closed by a different door.
Second, recognise that watching the address is not the same as opening it. A watch-only wallet imports the address, derives the script hash, and monitors the chain for any output that pays to it. The wallet can see when the box has been spent, and the wallet can see the witness, but the wallet cannot produce a witness, and the wallet cannot satisfy the script. Paste an address, never a seed. Never paste a seed into a watch-only field, because the field is a read-only field and pasting a seed into a read-only field is pasting a seed into something that does not need it.
Third, plan for the reveal moment. If the script demands a signature, rotate to a post-quantum path before the spend. If the script demands a hash, no rotation is required for the deadline, but the preimage still has to be held somewhere the spender can produce it, and the preimage has the same custody rules as any other key. A preimage is a key. Treat it like one.
Fourth, mind the timelock. A script that demands a hash preimage after a certain block height is still a timelocked script, and timelocks and key custody interact, and the interaction does not change at the November 2026 deadline. The box opens at the height the script says, with the witness the script demands, and no deadline in the calendar overrides the script.
Why the box analogy keeps paying rent
The box analogy earns its keep here because it separates the two halves cleanly. A signature is a key, and a quantum computer is a locksmith who can pick the lock. A hash is a different kind of lock, one that opens when the right string is spoken, and the only way to find the right string is to listen to the universe whispering every possible string until one matches. Grover's algorithm is a faster whisperer. It does not get you a key.
This is also why watch-only is a window, not an opening. Looking through the window shows you the box. It does not show you the lock mechanism, because the lock mechanism is sealed inside the hash commitment. The mechanism is published at spend, and the publication is the moment the box opens, and the box opens regardless of what the quantum calendar says.
The cleanest way to think about a hash-locked output is as a small puzzle box with a single number on the front. The number is the digest. The witness is the integer that hashes to it. The witness is checked by hashing it, and hashing is a one-way function, and one-way functions are not what Shor's algorithm breaks. The deadline retires the algorithms a different kind of box relies on, and the deadline does not retire the algorithm this kind of box relies on.
So when somebody tells you the November 2026 deadline ends the runway for hash-locked boxes, ask them which half of the box they think the deadline retires. The signature half, yes. The hash half, no. The runway counter ticks down against the signature half, and the runway counter has nothing to count against the hash half, because the hash half is not a runway. It is a digest.
Quick answers
- Does the November 2026 PQC deadline affect P2SH addresses?
- No. The deadline retires classical signature algorithms, and a P2SH address is a hash of a script, not a signature. The script is only revealed at spend.
- Can a quantum computer open a hash-locked output?
- Only by finding a preimage, which is a Grover problem, not a Shor problem. Against SHA-256 the cost is roughly 2^128 quantum operations, which is not a practical attack.
- Does watching a P2SH address expose the script?
- No. The script is sealed inside the hash commitment until spend. Watch-only wallets can see the box, not the script inside it.
- Should I rotate a hash-locked box before the deadline?
- Only if the underlying script demands a signature. If the script demands a hash preimage, no rotation is required for the PQC migration.