SIGHASH_ANYPREVOUT (BIP-118)

What Is SIGHASH_ANYPREVOUT?

SIGHASH_ANYPREVOUT (often abbreviated APO) is a proposed Bitcoin soft fork defined in BIP-118 that introduces two new signature hashing modes for tapscript transactions. Authored by Christian Decker and Anthony Towns, the proposal changes what data a digital signature commits to when spending Bitcoin, specifically removing the commitment to the exact UTXO being spent.

In standard Bitcoin transactions, a signature covers the outpoint (the txid and output index) of the UTXO being spent. This binds the signature to one specific coin. APO removes this constraint so that a pre-signed transaction can spend from any UTXO that matches the required script conditions. The signature becomes reusable across compatible outputs, which is the key property that unlocks new Layer 2 protocol designs.

BIP-118 has been in draft status since its original proposal (initially as SIGHASH_NOINPUT) and has been available for testing on signet via Bitcoin Inquisition since late 2022. It has not yet been activated on mainnet.

How It Works

To understand APO, it helps to know how standard Bitcoin signatures bind to inputs. When a transaction is signed using SIGHASH_ALL (the default), the signing algorithm hashes a "preimage" that includes every input's outpoint (txid:vout). This field, called sha_prevouts, ensures that changing even one input invalidates the signature.

APO modifies this process by omitting sha_prevouts and sha_amounts (for the ANYPREVOUTANYSCRIPT variant) from the signature hash. As long as a UTXO has the same script and value, the signature digest is identical, and the signature remains valid.

The Two Variants

BIP-118 defines two sighash flags, each offering a different level of flexibility:

SIGHASH_ANYPREVOUT (0x41) still commits to the scriptPubKey and amount of the output being spent. This means the signature is valid for any UTXO with the same script and same value. Replay across UTXOs with different amounts or scripts is prevented.

SIGHASH_ANYPREVOUTANYSCRIPT (0xc1) is more permissive: it commits to neither the script nor the amount. The signature is valid for any UTXO that includes the same BIP-118 public key in one of its potential spending paths. This is the variant most useful for eltoo, where the state update transaction must be able to spend from any prior state regardless of the specific script path.

Both flags can be combined with the standard output commitment modes (ALL, NONE, SINGLE), producing valid hash types 0x41, 0x42, 0x43, 0xc1, 0xc2, and 0xc3.

Taproot Requirement and Key Prefix

APO is only available for Taproot script path spends (as defined in BIP-342). It introduces a new public key type identified by a 0x01 prefix byte. When a tapscript contains a 33-byte public key starting with 0x01, the signature validation rules from BIP-118 apply instead of the standard BIP-340 Schnorr rules.

This design ensures that a signature created for a BIP-118 key cannot be reused against a standard BIP-342 key (and vice versa), even if both are derived from the same private key. The key version separation provides a security boundary between the two signing modes.

# Standard BIP-342 tapscript key (32 bytes, x-only)
OP_PUSHBYTES_32 <pubkey>
OP_CHECKSIG

# BIP-118 tapscript key (33 bytes, 0x01 prefix)
OP_PUSHBYTES_33 0x01<pubkey>
OP_CHECKSIG

What the Signature Digest Looks Like

The core technical change is in how the signature preimage is constructed. A standard BIP-341 signature hash includes sha_prevouts (the hash of all input outpoints) and sha_amounts (the hash of all input amounts). APO selectively removes these fields:

# Standard BIP-341 sighash preimage (simplified)
epoch | hash_type | nVersion | nLocktime
| sha_prevouts     # <-- binds to specific UTXOs
| sha_amounts      # <-- binds to specific values
| sha_scriptpubkeys
| sha_sequences
| sha_outputs
| spend_type | input_index

# SIGHASH_ANYPREVOUT preimage
epoch | hash_type | nVersion | nLocktime
|                  # sha_prevouts OMITTED
| sha_amounts      # still present
| sha_scriptpubkeys
| sha_sequences
| sha_outputs
| spend_type | input_index

# SIGHASH_ANYPREVOUTANYSCRIPT preimage
epoch | hash_type | nVersion | nLocktime
|                  # sha_prevouts OMITTED
|                  # sha_amounts OMITTED
|                  # sha_scriptpubkeys OMITTED
| sha_sequences
| sha_outputs
| spend_type | input_index

Use Cases

Eltoo / LN-Symmetry

The primary motivation for APO is enabling eltoo (LN-Symmetry), a proposed Lightning channel update mechanism that fundamentally simplifies how channels handle state updates. Current Lightning channels use the Poon-Dryja construction, where publishing an outdated commitment transaction results in a penalty: the counterparty can claim all channel funds via a justice transaction.

Eltoo replaces this penalty model with a "latest state wins" approach. Any later state transaction can spend any earlier state transaction, updating the on-chain state to the most recent version. This is only possible with APO because each update transaction must be able to spend from any prior state output, not a specific one known at signing time.

The benefits for Lightning are substantial:

• No toxic waste: nodes do not need to store every prior revocation key. Only the latest state matters.
• Simpler watchtowers: a watchtower only needs the latest update transaction, not a full history of revocation data. This makes watchtowers lightweight and almost free to operate.
• Cleaner force closes: unilateral closes resolve to the correct state without penalties, reducing the risk of accidental fund loss from publishing stale states.
• Better multiparty channels: eltoo scales more naturally to channel factories with more than two participants, since the penalty model becomes impractical with many parties.

For a deeper look at how eltoo changes Lightning mechanics, see the watchtower deep dive and the channel factories research.

Statechains

Statechains allow off-chain transfer of UTXO ownership without on-chain transactions. A statechain entity co-signs transactions with the current owner, and ownership transfers happen by updating the co-signing arrangement. APO improves statechains by enabling eltoo-style state updates, removing the need for the statechain entity to delete prior signing keys (a trust assumption that is difficult to verify).

With APO, statechain state transitions can use the same "latest state wins" logic as eltoo channels. Any new owner can publish an update transaction that supersedes prior states, regardless of which specific UTXO the statechain currently occupies. This is directly relevant to protocols like Spark, which uses a statechain-inspired architecture for off-chain Bitcoin transfers. For a technical deep dive, see the statechains scaling research.

Vaults and Covenants

APO can also be used to implement certain covenant-like behaviors. By pre-signing transactions with ANYPREVOUT, users can enforce spending conditions across UTXO replacements. While dedicated covenant proposals like CTV (BIP-119) and OP_VAULT offer more direct mechanisms, APO can emulate some covenant patterns. For more on the broader covenants landscape, see the covenants explainer.

Why It Matters

APO represents a targeted change to Bitcoin's signature validation that unlocks significant improvements for Layer 2 protocols. The current penalty-based Lightning model works but imposes real costs: nodes must store revocation data indefinitely, watchtowers must hold per-channel state, and accidental broadcasts of old states can result in total fund loss.

By enabling eltoo, APO would simplify Lightning's security model and reduce operational burden for node operators, watchtower providers, and wallet developers. It would also improve the viability of statechain-based protocols for off-chain Bitcoin scaling, benefiting systems that rely on UTXO ownership transfer without on-chain settlement.

The proposal has been extensively reviewed, tested on signet, and enjoys broad developer support. Its primary blocker is the general caution around Bitcoin consensus changes rather than any unresolved technical objection. For a comparison of APO with other proposed upgrades, see the CTV analysis.

Risks and Considerations

Signature Replay

Because APO signatures are not bound to a specific UTXO, they can be "replayed" against any compatible output. If a user creates a UTXO with the same script and amount as one they previously spent using APO, the old signature could be used to spend the new UTXO. This is an intentional property for protocols like eltoo, but it means APO should only be used in carefully designed protocol contexts, not for general-purpose payments.

The 0x01 key prefix requirement mitigates accidental exposure: standard wallets generating Taproot addresses will not produce BIP-118 keys unless they specifically opt in to the new key type.

Draft Status

BIP-118 remains a draft proposal with no confirmed activation timeline. Bitcoin consensus changes require extensive community review and broad agreement, and the process for activating new soft forks remains a subject of ongoing discussion. Protocols that depend on APO (such as the full eltoo design) cannot be deployed on mainnet until the soft fork activates.

Complexity in Protocol Design

While APO simplifies certain Layer 2 constructions, the signature reusability it introduces demands careful protocol engineering. Developers must account for the possibility that any compatible UTXO can be spent by an existing signature, which introduces subtle edge cases around fund safety and state management. The tradeoffs differ depending on whether ANYPREVOUT or ANYPREVOUTANYSCRIPT is used, and choosing the wrong variant can widen the replay surface unnecessarily.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.