How Bitcoin Could Reuse Signatures Across Compatible UTXOs

This is Part 3 in the technical article series about Bitcoin covenants by Cointelegraph Research. To read the previous article click here. 

SIGHASH_ANYPREVOUT, as proposed in BIP 118, builds on the earlier SIGHASH_NOINPUT concept mentioned in the 2015 Lightning Network paper by Joseph Poon and Thaddeus Dryja, and later formally proposed by Joseph Poon on the bitcoin-dev mailing list in February 2016.

SIGHASH_ANYPREVOUT is not a new opcode but a proposed new value for the SIGHASH flag, designed to be deployed as a soft-fork upgrade to Bitcoin. The SIGHASH flag is appended to a signature and determines which parts of a transaction are signed and will be checked by the CHECKSIG opcode. The selected flag is chosen by the signer, not enforced by the scriptPubKey. Due to the technical details related to upgradability in a softfork, the SIGHASH_ANYPREVOUT proposal only extends to spends from taproot addresses.

A variety of standard SIGHASH modes already exist, as illustrated in Figure 1. If the flag is set to SIGHASH_ALL, the signature must cover all inputs, all outputs, and the specific outpoint being spent, thus cryptographically binding the authorization to that exact UTXO. An outpoint is the combination of a transaction ID and an output index that together uniquely identify which UTXO a transaction is consuming. With SIGHASH_NONE, only the inputs need to be signed, leaving the outputs unconstrained. The SIGHASH_SINGLE variant signs all inputs, but only the output at the same index as the input being signed. The ANYONECANPAY modifier introduces further flexibility by allowing a single input to be signed independently of the others. Crucially, none of these existing modes allows a signature to omit commitment to the outpoint. That restriction is what SIGHASH_ANYPREVOUT removes.

BIP-118 defines two ANYPREVOUT variants that differ in how much of the previous output they omit from the digest, summarised in Figure 2. Under SIGHASH_ANYPREVOUT, the outpoint is excluded from the digest, but the signature still commits to the amount and scriptPubKey of the previous output, as well as the input’s nSequence. Under SIGHASH_ANYPREVOUTANYSCRIPT, the amount and scriptPubKey are also excluded, meaning the signature is not bound to the locking script of the spent output at all. All other commitments follow the standard Taproot signature message construction and depend on the selected base flag, such as SIGHASH_ALL or SIGHASH_SINGLE.

Because the outpoint is omitted from the digest, the same signature can authorize spending any compatible UTXO that satisfies the remaining committed fields. For example, a transaction pre-signed with ANYPREVOUT | ALL to produce a 0.5 BTC output can be reused if the same address later receives another UTXO of 0.5 BTC, even if the private key used to create the original signature is no longer available. If the new UTXO holds more than 0.5 BTC, however, the excess will be lost to miners unless the original signature included a change output. This rebinding property is what makes ANYPREVOUT useful for layer-2 protocols, where the same pre-signed transaction must apply to multiple possible on-chain UTXOs without requiring new signatures for each one.

For covenant-like applications, the ANYPREVOUT variants preserve commitment to the scriptPubKey of the previous output, and are typically the most relevant. They allow signatures to be reused across compatible UTXOs while ensuring funds remain bound to the same locking script. ANYPREVOUTANYSCRIPT removes this binding entirely and is therefore less suited to covenant-style applications.

Similar to OP_CTV, SIGHASH_ANYPREVOUT improves on the logic already achievable with pre-signed transactions but does not by itself enable recursive covenants or transaction introspection. Instead, it relaxes the binding between a signature and a specific UTXO, allowing a signature to be reused across multiple compatible UTXOs.

Some research has also noted that removing the outpoint commitment makes recovered-key constructions possible — that is, a public key can be derived from a fixed signature and message pair such that the corresponding private key is provably unknown to anyone, making the UTXO’s key path provably unspendable and forcing any spend through the script path. It would avoid the need for temporary keys, which are otherwise required to make the key path unspendable in constructions that rely on script-path-only enforcement. This observation appears in Bitcoin Covenants: Three Ways to Control the Future by Jacob Swambo et al. (2020), although it remains a theoretical construction rather than a design proposed in BIP-118.

The primary risk associated with SIGHASH_ANYPREVOUT signatures is signature replay. Because these signatures do not commit to a specific outpoint, the same signature can be used to spend a different UTXO than the one originally intended, provided the new UTXO satisfies the remaining committed fields. This risk becomes more pronounced in specific configurations: when ANYPREVOUT | SINGLE is used and output amounts can be rearranged; when a separate UTXO exists with the same scriptPubKey and amount, in the case of ANYPREVOUT; when the same public key appears in a compatible script, in the case of ANYPREVOUTANYSCRIPT; or when a miner can influence transaction ordering and inclusion to exploit these conditions. However, these scenarios require either deliberate misuse or a failure of the user or developer to account for replay conditions during protocol design.

In our next article we will commence our discussion of Opcodes that serve as supporting tools. These extend the expressiveness of Bitcoin script or data handling but do not implement covenant functionality unless combined with other opcodes. In this next category, we will discuss OP_CHECKSIGFROMSTACK and OP_CAT.