SKN | SIGHASH_ANYPREVOUT Could Expand Bitcoin Layer-2 Innovation Without Changing Core Security

Key Points:

• SIGHASH_ANYPREVOUT (BIP-118) proposes a new Bitcoin signature mode that allows compatible UTXOs to reuse the same signature.

• The proposal aims to improve Lightning Network channels, vaults and layer-2 protocols by reducing the need for repeated signature generation.

• Unlike covenant proposals, ANYPREVOUT does not enable recursive covenants or transaction introspection on its own.

• While the proposal offers greater flexibility, developers must carefully manage signature replay risks during protocol design.

A New Approach to Bitcoin Signatures

SIGHASH_ANYPREVOUT, outlined in Bitcoin Improvement Proposal 118 (BIP-118), proposes a new signature mode that would make Bitcoin transactions significantly more flexible without introducing a new scripting opcode.

Instead of permanently binding a signature to one specific unspent transaction output (UTXO), ANYPREVOUT allows the same signature to authorize spending any compatible UTXO that satisfies predefined conditions.

The proposal evolved from the earlier SIGHASH_NOINPUT concept introduced in the original Lightning Network research and is designed as a soft fork that applies to Taproot outputs.

Reducing Friction for Layer-2 Networks

Under Bitcoin’s existing signature system, every signature is tied to a specific transaction output.

ANYPREVOUT removes this strict linkage by excluding the transaction outpoint from the signature digest while still committing to important transaction details such as output amounts, locking scripts and sequence values.

This flexibility allows previously signed transactions to be reused if another compatible UTXO later exists.

For Lightning Network payment channels, vault designs and other off-chain protocols, this reduces operational complexity because participants no longer need to generate entirely new signatures whenever funding transactions change.

Two Versions Offer Different Levels of Flexibility

BIP-118 proposes two variants of the signature mode.

SIGHASH_ANYPREVOUT removes only the outpoint commitment while preserving commitments to the previous output’s amount and locking script.

SIGHASH_ANYPREVOUTANYSCRIPT extends this flexibility further by also removing commitments to the previous output’s script and amount, allowing signatures to be reused across an even broader range of compatible outputs.

Because ANYPREVOUT continues binding signatures to the same locking script, it is generally viewed as the more appropriate option for covenant-like applications.

Supporting Bitcoin Without Expanding Script Complexity

Unlike covenant proposals such as OP_CHECKTEMPLATEVERIFY (OP_CTV), ANYPREVOUT does not introduce recursive spending rules or provide transaction introspection capabilities.

Instead, it simply relaxes how signatures reference UTXOs, allowing greater flexibility while preserving Bitcoin’s existing transaction validation framework.

Researchers have also explored theoretical applications involving recovered-key constructions, where public keys could intentionally become permanently unspendable through the key path, forcing transactions to use only predefined script paths.

While academically interesting, these ideas remain separate from the core objectives of BIP-118.

Replay Protection Remains Essential

The primary security consideration associated with ANYPREVOUT is signature replay.

Because signatures are no longer tied to one unique UTXO, the same signature could potentially authorize spending another compatible output if developers fail to account for replay conditions.

Replay risks become more significant when identical output amounts, locking scripts or compatible transaction structures exist.

However, these scenarios generally result from protocol design choices rather than flaws within the proposal itself.

Careful implementation and replay protection mechanisms remain essential for any system built using ANYPREVOUT.

Outlook

SIGHASH_ANYPREVOUT represents one of Bitcoin’s most significant proposed upgrades for improving layer-2 scalability and transaction flexibility. By allowing reusable signatures across compatible UTXOs, the proposal could simplify Lightning Network channel management, vault security and other advanced Bitcoin applications while preserving the network’s underlying security model. If adopted, BIP-118 would expand Bitcoin’s smart contract capabilities without fundamentally altering its consensus principles.