← index

A quantum resistance script only using op_ctv/op_txhash and no new signatures

An archive of delvingbitcoin.org · view original topic →

simul · #1 ·

Anchor-gated, UTXO-moving, template-bound spend

using OP_TXHASH + OP_CTV with an escape hatch

(prunable-friendly; quantum-resilient to signature forgery)

Assumptions

Threat model

An attacker may:

An attacker may not:

High-level idea

This construction creates a multi-phase envelope that separates:

Even if signatures are forgeable, funds can only move into a protected Anchor envelope, and from there only along template-bound paths.

At no point does Phase 0 commit to final recipients.

Data definitions

Transactions and scripts

Phase 0: Funding coin (initial UTXO)

Purpose: Ensure that, even in a future where signatures are forgeable, all value must enter the Anchor envelope and cannot be redirected elsewhere.

Phase 0 locking policy

The Phase 0 UTXO enforces the following:

  1. Anchor pinning Any spend MUST create exactly one value-bearing output whose scriptPubKey equals P_anchor.

  2. No value leakage No other value-bearing outputs are permitted. Transaction fees are paid by reducing the Anchor output amount.

  3. Fee bound The Phase 0 script MUST enforce a bound on fee extraction, e.g.:


AnchorValue ≥ InputValue − MaxFee

This prevents an attacker from draining value via excessive fees while preserving fee flexibility.

These conditions are enforced using OP_TXHASH, selecting and verifying:

No commitment is made to final recipients or future templates.

Phase 1: AnchorPublishTx

Properties:

The Anchor envelope is now instantiated on-chain. An attacker may have triggered this spend, but cannot redirect value.

Anchor UTXO locking script

A Taproot script tree with two spending paths.

Path 1: Reveal spend (normal)

Conditions:

  1. Relative depth gate The Anchor UTXO must have aged by at least k blocks (CSV).

  2. Reveal check SHA256(x) == C.

  3. Template enforcement The spending transaction MUST match template T via OP_CTV.

Path 2: Escape hatch

Conditions:

  1. Template enforcement The spending transaction MUST match template E via OP_CTV.

  2. No secret revealed The value x is not disclosed on this path.

The escape path may be immediately available or time-delayed, depending on the chosen policy.

Phase 2: SpendAnchorTx

Security properties

Where OP_TXHASH fits

OP_TXHASH is used only in Phase 0 to enforce a partial covenant:

This is the minimal constraint required to survive a future where signatures are forgeable.

Because the destination is pinned only to the Anchor envelope, Replace-By-Fee (RBF) is safe to allow in Phase 0.

Summary

Phase 0 pins the envelope, not the destination. Phase 1 instantiates the envelope. Phase 2 chooses and enforces the destination.

The attacker is reduced from a thief to a griefer.

See: demonstration pseudocode for quantum-resistant spends · GitHub for demo code.

Brandon Black · #2 ·

I see a couple of problems with this construction:

  1. the T and E must be known at creation time of Phase0 outputs which means that phase0 must contain outputs that can be consolidated to exactly match the T and E CTV output totals.
  2. this would only be quantum safe if secp256k1 were disabled (NUMS points are spendable by a quantum adversary)
  3. because of (1) the user cannot direct funds to a new quantum-safe address on withdrawal

I think a modified version of this using CCV instead of TXHASH could resolve issuse (1) and (3). CCV can enforce value flow and embed and extract the CTV reveal spend at spend time rather than creation time, and it can also be used to enforce the escape spend with value flexibility.

With CCV, this would look like a standard vault construct with the exception of the embedded hash and preimage for the reveal-spend.

simul · #3 · · in reply to #2

What nums point? Proposal does not rely on NUMS. The escape hatch is back to the original construction. Attacker can only grief. Not spend.

Brandon Black · #4 · · in reply to #3

Perhaps I misunderstood. Are you intending this script to operate in P2TR or P2TSH? If the TXHASH or CTV locks are in P2TR, there must be a NUMS point for the internal key which is then tweaked to become the P2TR key, and which the quantum adversary can attack. If this is intended to depend on P2TSH then I retract that comment.

simul · #5 · · in reply to #4

In general, because of the secret-reveal sequence, it doesn’t matter if the attacker breaks the signature. P2TR or P2TSH are both acceptable. Without the revealed secret, the covenants won’t allow a spend to anything but the required shape. Indeed, the signature isn’t needed at all. A “spend any” would work too, however, that would make griefing free for anyone… allowing MEV attacks. So we use the signature still, forcing an attacker to work to grief.

Shape 1 (happy path): Anchor TX is added to a block, requiring secret-reveal to move, locking in a destination, and the spender reveals the secret (destination is locked in).

Shape 2: (attacker breaks nums): Spender sees that nums was broken and a bad anchor-tx was mined. Secret is never revealed. The only other valid spending path that doesn’t require a secret is “back to original”. Fees are lost (grief!). Miners profit, attacker gets nothing.

simul · #6 · · in reply to #5

As noted: a new SegWit version is also needed: “key spend allowed only if no script tree” or “script tree only”

simul · #7 ·

As noted by @reardencode , this construction requires a new Segwit witness version that eliminates key-path spending entirely and enforces script-only evaluation. The goal is to make signature forgery irrelevant by removing the NUMS/key fallback path. This can be introduced as a soft fork by defining a new witness version whose semantics are enforced only by upgraded nodes.

a modified version of this using CCV instead of TXHASH could resolve fee issues. CCV can enforce value flow and embed and extract the CTV reveal spend at spend time rather than creation time, and it can also be used to enforce the escape spend with value flexibility.