Bitcoin Covenants Series Part 3: Understanding SIGHASH_ANYPREVOUT
Imagine if a single Bitcoin signature possessed the capability to authorize spending operations across multiple distinct UTXOs? BIP 118's ANYPREVOUT accomplishes precisely this functionality, fundamentally transforming the potential applications of pre-signed transactions in self-custody solutions and layer-2 architectural design. Discover the mechanics behind this innovation.
This represents Part 3 within the technical article series examining Bitcoin covenants by Cointelegraph Research. For access to the preceding article click here.
The SIGHASH_ANYPREVOUT proposal, as outlined in BIP 118, extends from the foundational SIGHASH_NOINPUT concept that was referenced in the 2015 Lightning Network whitepaper authored by Joseph Poon and Thaddeus Dryja, subsequently receiving formal proposal treatment from Joseph Poon via the bitcoin-dev mailing list during February 2016.
Rather than introducing a new opcode, SIGHASH_ANYPREVOUT proposes a novel value for the SIGHASH flag, intended for deployment through a soft-fork upgrade mechanism to Bitcoin. Appended to each signature, the SIGHASH flag dictates which components of a transaction undergo signing and subsequent verification by the CHECKSIG opcode. This flag represents a choice made by the signing party, rather than a requirement imposed by the scriptPubKey. Given the technical considerations surrounding upgradability within a softfork framework, the SIGHASH_ANYPREVOUT proposal exclusively applies to spending operations from taproot addresses.
Multiple standard SIGHASH modes currently exist within the protocol, as demonstrated in Figure 1. When configured to SIGHASH_ALL, the signature encompasses all inputs, all outputs, plus the precise outpoint undergoing expenditure, thereby cryptographically anchoring the authorization to that particular UTXO. An outpoint represents the pairing of a transaction ID with an output index that collectively establish unique identification of which UTXO a transaction consumes. Under SIGHASH_NONE, exclusively the inputs require signing, rendering the outputs unconstrained. The SIGHASH_SINGLE variation signs the complete set of inputs, though only the output located at the identical index as the input receiving the signature. The ANYONECANPAY modifier delivers additional flexibility through permitting independent signing of a single input separate from others. Significantly, none among these existing modes permits a signature to exclude commitment to the outpoint. Removing that restriction constitutes the fundamental change SIGHASH_ANYPREVOUT introduces.
BIP-118 establishes two ANYPREVOUT variants distinguished by the extent of previous output data they omit from the digest, as summarized in Figure 2. With SIGHASH_ANYPREVOUT, the outpoint receives exclusion from the digest, yet the signature maintains commitment to both the amount and scriptPubKey of the previous output, alongside the input's nSequence field. With SIGHASH_ANYPREVOUTANYSCRIPT, both the amount and scriptPubKey also receive exclusion, resulting in the signature possessing no binding whatsoever to the locking script of the spent output. Every other commitment adheres to the standard Taproot signature message construction methodology and varies according to the chosen base flag, including SIGHASH_ALL or SIGHASH_SINGLE.
Due to the outpoint's omission from the digest, an identical signature possesses the capability to authorize spending operations for any compatible UTXO satisfying the remaining committed fields. As an illustration, a transaction bearing a pre-signature with ANYPREVOUT | ALL designed to generate a 0.5 BTC output becomes reusable should the identical address subsequently receive another UTXO containing 0.5 BTC, regardless of whether the private key employed for creating the initial signature remains accessible. Should the new UTXO contain an amount exceeding 0.5 BTC, the surplus amount faces loss to miners unless the initial signature incorporated a change output. This rebinding characteristic represents what renders ANYPREVOUT valuable for layer-2 protocols, wherein identical pre-signed transactions must apply across multiple potential on-chain UTXOs without necessitating fresh signatures for each individual instance.
Regarding covenant-like applications, the ANYPREVOUT variants maintain commitment to the scriptPubKey of the previous output, representing typically the most relevant configuration. These variants enable signature reuse across compatible UTXOs while guaranteeing funds remain constrained to the identical locking script. ANYPREVOUTANYSCRIPT eliminates this binding completely and consequently proves less appropriate for covenant-style applications.
Comparable to OP_CTV, SIGHASH_ANYPREVOUT enhances the logic already achievable through pre-signed transactions yet does not independently enable recursive covenants or transaction introspection capabilities. Rather, it loosens the binding relationship between a signature and a particular UTXO, enabling signature reuse across multiple compatible UTXOs.
Certain research has additionally observed that eliminating the outpoint commitment enables recovered-key constructions to become feasible — specifically, a public key can undergo derivation from a fixed signature and message pair such that the corresponding private key remains provably unknown to any party, rendering the UTXO's key path provably unspendable and mandating any spending activity through the script path. This approach would circumvent the requirement for temporary keys, which otherwise become necessary for rendering the key path unspendable in constructions relying upon script-path-only enforcement. This observation appears within Bitcoin Covenants: Three Ways to Control the Future by Jacob Swambo et al. (2020), though it persists as a theoretical construction rather than a design formally proposed within BIP-118.
The principal risk accompanying SIGHASH_ANYPREVOUT signatures involves signature replay vulnerabilities. Since these signatures lack commitment to a specific outpoint, the identical signature can undergo utilization to spend a different UTXO from the originally intended one, assuming the new UTXO satisfies the remaining committed fields. This risk intensifies under specific configurations: when ANYPREVOUT | SINGLE undergoes utilization and output amounts permit rearrangement; when a separate UTXO exists bearing the identical scriptPubKey and amount, in the case of ANYPREVOUT; when the identical public key appears within a compatible script, in the case of ANYPREVOUTANYSCRIPT; or when a miner possesses the capability to influence transaction ordering and inclusion to exploit these conditions. Nevertheless, these scenarios necessitate either intentional misuse or a failure on the part of the user or developer to properly account for replay conditions throughout protocol design.
Within our subsequent article we will initiate our discussion of Opcodes functioning as supporting tools. These expand the expressiveness of Bitcoin script or data handling capabilities yet do not implement covenant functionality unless combined with additional opcodes. In this forthcoming category, we will examine OP_CHECKSIGFROMSTACK and OP_CAT.