SIGHASH_ANYPREVOUT: Flexible UTXO signing for Taproot

BIP-118 proposes a new SIGHASH value, SIGHASH_ANYPREVOUT, for Taproot inputs that lets a signature omit the outpoint from the signed data. The proposal aims to make pre-signed transactions reusable across different but compatible UTXOs and is designed for soft-fork deployment restricted to Taproot addresses.

SIGHASH flags tell Bitcoin which parts of a transaction a signature binds to. Today, common modes typically bind a signature to the exact outpoint (the prior transaction ID and output index) being spent. BIP-118 defines two ANYPREVOUT variants. SIGHASH_ANYPREVOUT removes only the outpoint from the digest while still committing to the spent output’s amount and locking script. SIGHASH_ANYPREVOUTANYSCRIPT also omits the amount and scriptPubKey, removing the binding to the spent output’s locking script.

The signer chooses the SIGHASH flag appended to the signature; the scriptPubKey does not enforce it. Because the outpoint is not committed under ANYPREVOUT, a single pre-signed transaction can be used to spend any UTXO that matches the remaining committed fields. For example, a transaction pre-signed with ANYPREVOUT combined with ALL to create a 0.5 BTC output can be applied to a later UTXO that also holds 0.5 BTC to the same script. If the replacement UTXO holds more value than the pre-signed outputs account for, the excess value can be lost to miners unless the pre-signed transaction included a change output.

The omission of the outpoint creates signature replay risks. A signature intended for one UTXO can be presented to spend a different UTXO that satisfies the other signed fields. Replay is more likely in certain setups: when ANYPREVOUT is used with SINGLE and outputs can be reordered, when multiple UTXOs share identical amounts and scripts, when the same public key appears in compatible scripts under ANYPREVOUTANYSCRIPT, or when miners can influence transaction ordering and inclusion.

The SIGHASH_ANYPREVOUT idea builds on earlier concepts. A no-input notion appeared in the 2015 Lightning Network paper by Joseph Poon and Thaddeus Dryja, and Poon proposed a formal no-input design on developer lists in 2016. BIP-118 is a proposal for a new signature flag rather than a new opcode.

The proposal does not add script opcodes that inspect transaction internals or enforce future spending structure. Unlike OP_CHECKTEMPLATEVERIFY, which fixes a specific template for future spends, ANYPREVOUT relaxes the link between a signature and a specific UTXO. It makes pre-signed transactions more flexible but does not by itself enable recursive covenants or extra script introspection.

Researchers have noted a theoretical recovered-key construction enabled by omitting the outpoint. In that design, a public key could be derived from a fixed signature and message so the corresponding private key is unknown, rendering the key-path spend unspendable and forcing spends through the script path. That construction has been discussed in academic work but is not part of BIP-118 itself.

Activation of SIGHASH_ANYPREVOUT would require a soft fork and changes in wallets and node software. The proposal is under discussion on Bitcoin developer channels. Implementation choices, client updates and wallet practices would determine how widely the flag is used and how the described replay and safety conditions are managed.