When the Thief Has the Right Key

Part One: Who Gets Paid When Both Signatures Are Valid?

By Mark Askey, Founder | CTO, 0REI Immutable Evidence Systems

Bitcoin's quantum migration problem starts with cryptography and ends with a decision about ownership, dormant coins, and whose evidence the network will accept.

A quantum attacker doesn't forge your signature. It makes a real one.

An owner holds a Bitcoin private key. A quantum attacker recovers that same key from its exposed public key. Now both can sign, and both signatures verify.

Who gets paid?

The debate about stronger algorithms buries that question. Replacing an algorithm doesn't settle the ownership claims created when the old one fails. The question that matters is simple:

What can the legitimate claimant prove that the attacker cannot?

The short answer: sometimes something, sometimes nothing. Where cryptography runs out, the network has to make a rule, and this piece shows exactly where that line falls.

The key stays unique. Knowledge of it doesn't.

For Bitcoin's elliptic curve signatures, the core relationship is:

Here $d$ is the private scalar, $G$ is the curve's generator, and $Q$ is the public key. Under the assumptions securing Bitcoin today, recovering $d$ from $Q$ is classically infeasible.

A sufficiently capable quantum computer running Shor's algorithm can solve that elliptic curve discrete logarithm. (This is a different problem from factoring an RSA modulus. Shor breaks both, but the math differs.)

For a fixed generator of prime order, the scalar is still unique modulo that order. What quantum recovery destroys is exclusivity:

Both parties now hold the same spending credential. The verifier cannot tell how either one got it.

Public key exposure decides who is at risk, and when

Bitcoin outputs don't all expose their public keys the same way.

A P2PK output puts the public key directly in the spending script:

<Q> OP_CHECKSIG

An attacker can go after that key without waiting for the owner to move.

P2PKH and P2WPKH commit to a hash of the serialized public key instead:

There, the key normally appears only when the coin is spent, though address reuse exposes every other coin under the same key. Taproot outputs also expose an elliptic curve output key, built differently from P2PK.

That splits the threat in two:

• Long exposure: the public key is visible well before spending, so the attacker has time.
• Short exposure: the key appears only during spending, so the attacker must win the race before confirmation.

Hashing draws a different line. For idealized unstructured search, Grover's algorithm gives a quadratic speedup:

For a generic 160-bit preimage target:

Those are query counts, not attack forecasts. They ignore hardware, error correction and run time. And a 160-bit address hash says nothing about whether the owner picked a weak private key.

Private transaction submission reduces mempool exposure. It still shows the transaction to its recipients, who may be hostile or compromised, and Bitcoin's average block interval is not a guaranteed confirmation deadline.

Reducing exposure helps. It does not eliminate the attack.

A zero-knowledge proof can't supply missing history

Suppose a recovery mechanism accepts this proof of knowledge:

The owner can produce it. So can the attacker.

Zero knowledge hides the witness during verification. It says nothing about when or how the claimant got that witness.

For a public key that has never been exposed, a proof like this could do real work:

It could support migration without revealing $Q$, provided the whole proof and authorization construction survives quantum attack and consensus recognizes it.

For a key that's already exposed, the attacker knows that hash preimage too. Hiding $Q$ inside a new proof can't erase its earlier appearance on the chain.

A proof built only on the compromised credential cannot tell the original holder from the thief.

Where a second secret changes the answer

Some owners hold private material beyond the individual spending key.

A hardened wallet derivation step creates a real distinction: recovering a child spending scalar doesn't reveal the private material above that boundary. A proof of suitable parent material could therefore show something the attacker can't show from the exposed key alone.

A recovery commitment registered securely before compromise could supply another authorization path.

Neither one establishes legal ownership on its own. Each adds cryptographic evidence under a defined rule.

And P2PK describes a spending script, not a key generation history. An early output doesn't prove its owner kept a useful parent secret, and it doesn't rule out every possible extra secret or prior commitment either.

Coins with no qualifying extra evidence are the hard case. Their owner may have no cryptographic advantage left.

The oldest coins are the pure case

P2PK outputs are where this piece's question has no cryptographic answer. BIP 361's authors say so directly: it is not currently believed possible to build a rescue protocol for P2PK outputs, "as no knowledge asymmetry is known." As far as anyone can show, the owner knows nothing the attacker doesn't.

For those coins the answer cannot come from a proof. It has to come from a rule. Part Three works through the rules on the table and what each one actually decides.

What a migration deadline could look like

Draft BIP 361 proposes one schedule, conditional on activation and supporting mechanisms:

That's a proposal, not an adopted deadline or a hardware forecast. And a spending cutoff doesn't automatically mean a hard fork: tightening previously valid spending conditions can be done as a soft fork, depending on the design.

"The rules get stricter" and "the network needs a hard fork" are different claims.

You can't make every owner show up

Some owners will be offline. Some won't know. Some have died. Some lost a device but kept a backup. Those cases aren't interchangeable:

• Lost device, backup kept: recovery may still be possible.
• Every necessary secret lost: no proof can recreate them.
• Dormant owner with usable secrets: inactivity alone proves no abandonment.
• Stolen spending key: possession doesn't separate thief from holder.
• Qualifying recovery secret kept: may support a stronger claim under defined rules.

Exchanges, custodians, miners, developers and node operators all shape adoption. No single group can guarantee universal compliance or dictate every node's rules. The realistic goal is broad migration on usable infrastructure with clearly specified recovery conditions. No deadline can guarantee universal participation.

The governance decision doesn't go away

One side puts existing spending rights first, including those of dormant owners. The other puts first stopping attackers from taking exposed coins and destabilizing the network. Both are real positions. Neither becomes a theorem because its advocates describe the consequences loudly.

A few facts belong in that debate:

• Quantum theft transfers existing bitcoin. It doesn't mint new bitcoin.
• The economic damage could be severe, but a specific price collapse is a prediction that needs its own evidence.
• Freezing an old spending path, allowing conditional recovery, restricting spending, and burning coins outright all have different consequences. "Burn everything or allow unrestricted theft" throws out every middle option before examining it.
• No equation proves unmigrated coins must disappear after five or seven years. A sunset is a governance choice.

Bitcoin makes this problem unusually visible because the disputed evidence controls money. The same distinction applies anywhere signatures establish identity, authority, or custody history.

A note on "AI asking the quantum computer the right questions"

A quantum computer doesn't take questions. It runs circuits compiled from an algorithm. AI can help on the classical side, by finding better algorithms, shrinking circuits, and spotting side-channel leakage, and that can change what an attack costs. But a prompt is not an executable attack circuit, and it is not the hardware to run one.

Claims that frontier labs are sitting on secret cryptographic breakthroughs need evidence. Secrecy alone proves nothing.

Resource estimates do move. A 2026 research paper describes an attack construction using fewer than 1,200 logical qubits and 90 million Toffoli gates, and estimates execution in minutes on fewer than half a million physical qubits under specified superconducting hardware assumptions. That's a conditional estimate, not a demonstration that the hardware exists. It does undercut blanket claims that millions of physical qubits are a fixed minimum, or that fast attacks must stay decades behind slow ones.

The engineering assumptions belong next to the headline.

---

Once a spending key is shared with an attacker, recovery needs either extra verifiable evidence or an explicit decision about the rules.

Part Two covers what that evidence has to authorize, how a recovery system stops repeat claims, and where accumulators, covenants and challenge windows actually help.

When the thief has the right key, "the signature verified" is where the investigation starts.

Mark Askey is Founder | CTO of 0REI Immutable Evidence Systems, which builds evidence-sealing systems where proving custody history after the fact is the whole job.

References for Part One

• Quantum resource estimates for elliptic curve cryptocurrency attacks
• BIP 32: Hierarchical Deterministic Wallets
• BIP 361: Post Quantum Migration and Legacy Signature Sunset
• Hourglass spending rules, version 2 (draft)

Part Two: What a Recovery Protocol Must Actually Prove

By Mark Askey, Founder | CTO, 0REI Immutable Evidence Systems

The engineering behind quantum recovery: hardened derivation, Merkle accumulators, covenant enforcement, transaction binding, single redemption, and what it costs to check it all.

In Part One, the owner and the attacker ended up holding the same private key. Both could sign. A proof built on that key alone couldn't tell them apart.

Now the engineering question: what does a recovery system have to verify before it releases the funds?

Putting the claim in a Merkle tree doesn't answer it. A six-month delay doesn't answer it. Moving verification into consensus doesn't answer it. Each mechanism has one job, and a credible design connects those jobs without letting membership stand in for authorization, or a valid proof authorize the wrong transaction.

Four requirements follow: authorize the exact transaction, redeem each coin once, conserve value, and make every challenge objectively checkable. First, the witness.

Start with a witness the attacker can't produce

For an exposed public key:

An attacker who recovers $d$ passes the same possession proof as the owner. A hardened derivation recovery mechanism asks for more:

Here $s$ is retained private derivation material, and $p$ is an exact path that includes the required hardened boundary.

The security argument rests on the derivation rules, on what ancestor information has already leaked, and on the proof system. A chaincode alone isn't enough, because BIP 32 extended public keys include chaincodes.

A recovery commitment registered earlier is another basis for authorization. Recovery mechanisms don't all need the same kind of secret. They all share one requirement:

The attacker's compromised spending credential must never be enough to satisfy the recovery condition.

Feasible math still has a price

Proving hardened derivation and elliptic curve operations inside a quantum-resistant proof system costs computation, memory, proof size and verification time. Project Eleven reports these prototype numbers on specified Apple M5 hardware:

The authors call the prototype unaudited and say it needs explicit protocol support. The numbers make the deployment question concrete. They aren't universal lower bounds, and they don't prove deployment is impossible.

A consensus proposal still needs bounded validation cost under adversarial traffic, correct weight accounting, and real migration capacity. One proof's benchmark doesn't tell you what a migration wave costs the network.

A research implementation and a safe consensus deployment are different milestones.

Define exactly what's being recovered

A quarantine system could commit to each eligible coin with a leaf like:

The encoding must be unambiguous, with defined boundaries for variable-length fields, and leaf hashing must be domain-separated from internal node hashing.

For an illustrative binary Merkle tree:

$S_i$ is the sibling hash at level $i$. The verifier checks that the final reconstructed root matches the committed quarantine root.

A twenty-level branch carries:

That's the sibling hashes alone; encoding, leaf data and other witnesses add more. A large zero-knowledge proof may dominate total size, but the Merkle branch by itself is not thousands of bytes.

An inclusion proof establishes membership. It does not establish authorization, and it does not establish that the coin is still unspent.

Native verification doesn't fix weak authorization

A proposal might move accumulator verification out of Script into a native consensus operation. That changes execution cost, transaction structure and state management. It doesn't change the ownership evidence.

If the native verifier accepts a proof the attacker can generate, the attacker passes. Moving the check to a lower layer doesn't strengthen the relation being proved.

The accumulator's own assumptions matter too. A hash-based tree and a structure built from elliptic curve commitments don't have the same security against the quantum threat in question.

What CAT and CTV can and can't enforce

Once membership and authorization are separated, the scripting tools are easier to judge:

BIP 347 discusses covenant and vault constructions built from CAT plus existing Script operations, so "CAT can't constrain outputs" is too strong. Those constructions still need their own threat analysis: a covenant technique that relies on elliptic curve signature properties isn't quantum-resistant just because CAT is involved.

CTV checks the template hash on top of the stack. The BIP's reference code reads that value in place and contains no step that removes it. The template commits to exact outputs, amounts included, and other transaction structure. For arbitrary recovery balances that raises questions about template construction, allowed destinations and fees. Separate templates or securely constrained computations can address particular designs.

If the claimant supplies an unrestricted template, the claimant chooses the restriction. That defeats the point.

Requirement one: authorize the exact transaction

A recovery proof has to authorize a precisely defined transfer. An illustrative message commitment:

The proof must be bound to $m$. The transaction fields must cover destinations and amounts, with explicit rules for fees, extra inputs and allowed modifications. Binding only a destination script leaves everything else open.

A copied proof must never authorize an altered transfer.

Requirement two: redeem each coin once

A static membership proof stays valid after redemption, so the protocol needs independent spent tracking:

Every accepted recovery path must consume the same original coin's redemption authority. For publicly identified coins, a consensus spent set keyed by original outpoint expresses that directly.

A nullifier can support other constructions, but this formula isn't automatically enough:

Suppose the protocol accepts one recovery witness based on a master secret and another based on an intermediate private key. If both recover the same coin with different witness values:

the system records two different nullifiers for one coin. That's a witness-consistency problem, not a hash collision. The design must guarantee one redemption identifier, or equivalent spent state, across every accepted recovery method. An authenticated dictionary with state updates is another route. The property is the same:

Spending once must invalidate every later claim to the same value.

Requirement three: conserve value

The accounting must satisfy:

where $F$ is the transaction fee.

Consensus must authenticate every recovered amount and block double-counting across recovery paths. If quarantined coins leave the ordinary UTXO set, the replacement state must carry their amounts and redemption status exactly. Fee sponsorship and extra ordinary inputs need explicit rules, or an authorization that locks the destination can still let the transaction's economics shift underneath it.

Requirement four: every challenge must be objectively checkable

A relative timelock buys response time. It doesn't decide whether a claim is fraudulent.

"Evidence of an earlier broadcast" isn't enough. Nodes share no single authoritative mempool history, and an attacker holding the key can broadcast too. A challenge mechanism needs a defined lifecycle:

A challenge has to point to a real violation or a stronger authority. A conflicting claim alone doesn't say who's entitled. And if the initial proof already establishes enough authorization, the challenge period may not be needed at all.

A delay is not a defense. Evidence is.

When a vault actually changes the outcome

A vault with an independently controlled quantum-resistant recovery key creates a real asymmetry. An attacker might compromise a hot elliptic curve key and start a withdrawal; a separate recovery branch lets the owner step in with a secret the attacker doesn't have.

That works only if the recovery authority was set up securely in advance, the enforcement survives the threat, and someone is watching and responds before the window closes. A hash-based signature could serve as that authority in a properly specified system, but naming Lamport or WOTS+ isn't an implementation: verification, one-time-use constraints, transaction binding and enforcement all still need analysis. And a vault can't be bolted onto an old output after the fact without authorization or new consensus rules.

The protection comes from the independent authority, not the wait. Waiting alone doesn't protect an absent owner when the attacker satisfies every accepted condition.

A quantum-resistant label doesn't verify anything

This does not implement a new signature algorithm:

<PQ_Pubkey> OP_CHECKSIG

Existing consensus rules decide what gets checked. Unknown Tapscript public key types are an upgrade hook; today they don't verify ML-DSA or Falcon.

BIP 360 proposes P2MR, which removes Taproot's key-spend path. It doesn't introduce quantum-resistant signatures by itself. On size: P2MR generally saves 32 bytes against an equivalent Taproot script-path control block, with an encoding-boundary exception, but its witness is always larger than a Taproot key-path spend. P2MR addresses long exposure under stated conditions; fast attacks during spending need more, though not necessarily one mandatory opcode design.

Signature size is its own tradeoff:

Legacy ECDSA encodings differ from BIP 340 Schnorr. Bigger signatures affect weight, validation and migration capacity, but size alone doesn't prove a specific throughput collapse.

Why custody evidence has to be sealed before the dispute

Every working recovery path in this piece rests on evidence that existed before the compromise: a hardened parent secret, a registered recovery commitment, an independent vault key. Nothing created after the attacker holds the key can separate the two claimants. Custody evidence has to be sealed before the dispute, not reconstructed after it. That is the problem evidence-sealing systems exist to solve.

Where engineering ends and policy begins

A complete design needs exact encodings, supported proof systems, authorization rules, state transitions, resource limits, failure behavior and activation conditions. The relations here illustrate the requirements; they are not a deployable consensus spec.

And even a correct recovery mechanism can't guarantee that every owner kept qualifying evidence. That gap is where Part One's governance question comes back: the network has to decide what happens to coins whose old credentials are compromised and whose claimants can't show stronger authority.

Cryptography can support custody history through earlier authenticated commitments and records. It cannot rebuild missing history from a compromised scalar.

• A signature ties a message to a key.
• A Merkle proof establishes membership.
• A timestamp shows existence, under its trust assumptions.
• A zero-knowledge proof establishes a specified relation while hiding its witness.

The system's job is to connect those facts without claiming more than they prove.

When the thief has the right key, recovery has to rest on evidence the thief doesn't have, or on an explicit decision about which claims the network will accept.

The verifier's job is to enforce that decision exactly.

Mark Askey is Founder | CTO of 0REI Immutable Evidence Systems, which builds evidence-sealing systems where proving custody history after the fact is the whole job.

Related: Mark Askey, "Quadratic Residues and the Failure of Zero Knowledge Positivity Proofs over BN254," Zenodo, doi:10.5281/zenodo.23842727.

References for Part Two

• BIP 32: Hierarchical Deterministic Wallets
• BIP 119: CHECKTEMPLATEVERIFY
• BIP 112: CHECKSEQUENCEVERIFY
• BIP 347: OP_CAT in Tapscript
• BIP 342: Validation of Taproot Scripts
• BIP 360: Pay-to-Merkle-Root (P2MR)
• Project Eleven: Recovery proof implementation and benchmarks
• NIST FIPS 204: ML-DSA

Part Three: The Coins With No Proof

By Mark Askey, Founder | CTO, 0REI Immutable Evidence Systems

What Bitcoin's draft proposals do with the coins no recovery protocol can reach, and what a rule decides when evidence can't.

Parts One and Two asked what a legitimate owner can prove that an attacker cannot. For many modern wallets there may be an answer: a hardened parent secret, a commitment registered in advance, an independent recovery key.

For the oldest coins on the network no answer is known. This part is about what happens then.

No asymmetry, no proof

A P2PK output carries its public key in the open. An attacker with a capable quantum computer can start work on it today and never has to wait for the owner to spend.

Every recovery protocol works the same way: find something the owner knows and the attacker doesn't. BIP 361 states the requirement in plain terms. Rescue protocols "rely on asymmetry of knowledge between a quantum attacker and the authentic coin-holder." Then it says what that means for P2PK. It is not currently believed possible to build a rescue protocol for those outputs, "as no knowledge asymmetry is known."

The scale, by the Hourglass draft's own count, is roughly 34,000 P2PK addresses averaging 50 coins each:

When the owner and the attacker know exactly the same thing, there is nothing left to prove.

Three rules, and no fourth

BIP 361 sorts proposals for quantum vulnerable coins into three types. The rule names below follow the BIP. What happens to the coins and what actually decides are my reading of each rule:

The BIP is blunt about the first two. Open taking ends up "benefiting those who reach quantum capability earliest." Throttled taking "leads to RBF battles and ultimately miners subsidizing their revenue from quantum recovered coins," meaning fee bidding wars where the recovered coins end up paying the miners.

Not one of the three identifies the owner. None of them can. Each one answers a different question and lets that answer stand in for ownership.

What "do nothing" looks like in numbers

The Hourglass draft estimates that with no constraint, more than 6,000 P2PK transactions could fit in a single block, releasing more than 300,000 coins per block. At that rate, it says, every P2PK coin could be spent "in just a few hours."

That is an estimate of block capacity. It is not a forecast that any attacker could recover keys that fast. It does show that the network's own throughput sets no meaningful limit.

Hourglass: a rate limit in place of a verdict

Hourglass is a draft soft fork with two versions.

Version 1, dated April 29, 2025, allows one P2PK spend per block and no new P2PK outputs. At the average balance that caps the flow at:

The authors report that feedback from economic actors said this was not enough of a restriction. Version 2, dated February 10, 2026, adds a cap on value:

One bitcoin per block is about 144 per day. The draft sets that against the 450 coins per day issued by the current block subsidy. And the total drains slowly:

The draft's own figure is "more than 32 years."

What the rule does not do

Three things follow directly from the specification.

It does not tell the owner from the thief. Whoever holds the key can take the slot. The rule never asks how they got it.

The remainder stays exposed. Everything above one bitcoin goes back to the original script, under the same public key the attacker already has. The same output can be contested again in any later block.

The slot is shared. There is one slot per block for all 34,000 addresses. An owner moving a 50 coin output needs at least 50 of them. The draft expects that with no quantum competition, keyholders could move their coins "in a matter of weeks or months." With competition, the owner is bidding against the attacker for their own coin, one bitcoin at a time.

The fee decides

Version 1 describes the mechanism. Competing parties "will have to bid against each other" for the single slot, and what they will pay is capped by "the revenue of the transaction less the cost of calculating the private key."

Put two capable attackers in that auction and their bids climb toward the cap. If the cost of recovering a key is small next to the coin, most of the value flows to miners. Put an owner in it and the owner has to outbid someone whose only cost is computation.

Version 2 suggests this could become "a de facto block reward subsidy dwarfing new coin issuance." The draft's own numbers set the timing. At most one bitcoin is released per block, so a rational bid cannot exceed one bitcoin. The draft's 450 coins per day works out to a subsidy of 3.125 per block, which has to halve twice before it drops below one:

So fees from this source could pass the subsidy only after two more halvings. That is arithmetic on the draft's figures. It does not change how the mechanism works.

Under a throttle, the coin goes to the highest bidder. Ownership is not an input.

A rule that makes the attack visible

BIP 361 raises a separate danger: "We may not know the attack is underway." An attacker could recover keys quietly and move funds weeks or months later.

Version 1 of Hourglass argues that a rate limit changes that incentive. It gives a "tremendous monetary first mover advantage" to whoever shows their hand first, because they can harvest with relatively little fear of instantly crashing the market. The draft adds that the frequency of these transactions, and then their fees, "may give us great insight into the cost performance of the current state of the art in quantum processing."

That is the authors' game theory argument. It has not been demonstrated. It is still worth noticing what it claims: a rule that cannot identify the owner might at least reveal the attacker.

What freezing decides instead

BIP 361's Phase B restricts legacy spends by putting them behind a rescue protocol. No rescue protocol is known for P2PK. The BIP does not spell out the P2PK case. Read together, those two points mean that under BIP 361 alone, a P2PK coin that did not migrate before Phase B could not be spent. The BIP lists the general case as a benefit: "Abandoned keys that never migrate remain unspendable."

Its justification is a line from Satoshi, "Lost coins only make everyone else's coins worth slightly more," and a corollary the authors add: "Quantum recovered coins only make everyone else's coins worth less. Think of it as a theft from everyone."

Version 2 of the Hourglass draft names the objection. Freezing or burning "may be viewed as confiscatory without keyholder consent" and "may set a dangerous precedent for changing the monetary policy going forward."

A freeze has the same blind spot as a throttle, pointed the other way. It cannot tell an owner who has died from an owner who is simply quiet. Part One made the point: inactivity alone proves no abandonment.

The two proposals are not strictly rivals. BIP 361 says it is compatible with an Hourglass style rule for P2PK, provided that rule has activated by the time Phase B does, and its authors say they support it for exactly the reason this part began with.

Where these stand

All of this is draft text. Hourglass has no BIP number assigned, and version 2's backward compatibility section reads "TBD." BIP 361 is a draft that lists the post quantum signature BIP it requires as "TBD." Nothing described here is activated, scheduled, or agreed.

The lesson past Bitcoin

The owners of those early coins did nothing wrong. They used the system as it existed. Nobody told them that one day they would need to show something more than the key, so nothing more was ever recorded. Now it can't be.

Every system being built today still has that choice. Where evidence of custody was sealed before the dispute, a verifier can check it and name the rightful party. Where it wasn't, someone writes a rule: a race, an auction, or a deadline. The rule may be wise. It still cannot know who the owner is.

A rule can limit the damage. Only evidence can name the owner.

Mark Askey is Founder | CTO of 0REI Immutable Evidence Systems, which builds evidence-sealing systems where proving custody history after the fact is the whole job.

References for Part Three

• BIP 361: Post Quantum Migration and Legacy Signature Sunset
• Hourglass spending rules, version 2 (draft)
• Hourglass spending rules, version 1 (draft)
• BIP 360: Pay-to-Merkle-Root (P2MR)