Bitcoin Covenants Part 3: SIGHASH_ANYPREVOUT Explained for Builders

Bitcoin covenants continue to be explored through incremental, deployable changes to the protocol—rather than sweeping new functionality. In Cointelegraph Research’s technical series, the focus shifts to SIGHASH_ANYPREVOUT, a proposed soft-fork upgrade that changes how Bitcoin signatures bind to the transaction they authorize.

As described in BIP 118, SIGHASH_ANYPREVOUT would not introduce a new opcode. Instead, it proposes a new value for the SIGHASH flag so that signatures can omit commitment to the exact outpoint being spent. The key idea: keep important parts of the previous output committed, while relaxing one binding that normally prevents safe signature reuse across compatible UTXOs.

Key takeaways

• SIGHASH_ANYPREVOUT is a proposed SIGHASH-flag value, not a new opcode, intended for soft-fork deployment.


• The proposal excludes the spent outpoint from the signature digest, enabling signature reuse across different but compatible UTXOs.


• SIGHASH_ANYPREVOUT preserves commitments to the previous output’s amount, scriptPubKey, and the input’s nSequence; SIGHASH_ANYPREVOUTANYSCRIPT relaxes the scriptPubKey commitment too.


• Because the signature no longer commits to a specific outpoint, replay risk increases, depending on how the scheme is configured and implemented.


• The “soft-fork upgradability” constraints limit applicability to taproot spends under the proposal’s design.

Why outpoint binding matters in Bitcoin signatures

In Bitcoin, the SIGHASH flag is appended to a signature and determines what parts of a transaction are included in the data that the CHECKSIG opcode verifies. The signer chooses the SIGHASH value; it is not enforced by scriptPubKey. The upshot is that different SIGHASH modes control how tightly a signature is cryptographically bound to the transaction structure.

Cointelegraph Research notes that Bitcoin already has several standard SIGHASH behaviors. For example, with SIGHASH_ALL, the signature must cover all inputs, all outputs, and the specific outpoint (the transaction ID plus output index) being spent—meaning the authorization is locked to that exact UTXO. Variants like SIGHASH_NONE and SIGHASH_SINGLE loosen what outputs are committed to, while ANYONECANPAY allows a single input to be signed independently of other inputs. However, the common thread is that none of these established modes allows the signature to omit commitment to the outpoint itself.

That omission—removing outpoint commitment from the digest—is the central change SIGHASH_ANYPREVOUT introduces.

What BIP 118 proposes: two ANYPREVOUT variants

According to BIP 118, SIGHASH_ANYPREVOUT defines two variants that differ in how much of the previous output remains in the signing digest.

SIGHASH_ANYPREVOUT excludes the outpoint from the digest. But the signature still commits to several other fields: the previous output’s amount and scriptPubKey, along with the input’s nSequence. In other words, the signature is not tied to “which exact UTXO index is spent,” yet it remains tied to the characteristics of the previous output relevant to spending conditions.

SIGHASH_ANYPREVOUTANYSCRIPT goes further by also excluding the previous output’s amount and scriptPubKey. As Cointelegraph Research highlights, this means the signature is not bound to the locking script of the spent output at all. The rest of the signature message construction follows the normal Taproot signature digest rules, depending on the selected base flag (such as SIGHASH_ALL or SIGHASH_SINGLE).

How signature reuse could work—and why it matters for layer-2

The practical effect of leaving the outpoint out of the digest is that the same signature can authorize spending any compatible UTXO that matches the remaining committed fields. Cointelegraph Research provides a concrete example: a transaction pre-signed under ANYPREVOUT | ALL to create a 0.5 BTC output could be reused later if the address receives a different 0.5 BTC UTXO. In that scenario, reuse does not depend on retaining the original signing key.

But reuse is not free of economic consequences. If the new UTXO holds more than the original amount, the extra value may be lost to miners unless the original design included a change output. That means protocol designers still need to account for the possibility that the “next available” compatible UTXO might differ in total value—despite the signature being reusable.

Cointelegraph Research connects this rebinding property to a broader use case: layer-2 protocols. In these systems, it’s common to preconstruct or preauthorize transactions that must later become valid under multiple possible on-chain realities. By allowing the same pre-signed transaction to apply to multiple compatible UTXOs, ANYPREVOUT-style flexibility can reduce the number of times new signatures—and new coordination—are required.

Where covenants fit—and what remains technically missing

For covenant-like applications, the research notes a crucial distinction. SIGHASH_ANYPREVOUT preserves commitment to the previous output’s scriptPubKey, making it more relevant than SIGHASH_ANYPREVOUTANYSCRIPT, which removes that binding entirely. If the goal is to enforce that funds remain governed by a specific locking script across compatible UTXOs, maintaining that commitment is typically important.

The series also clarifies a limitation. While SIGHASH_ANYPREVOUT improves on what pre-signed transactions can already do, it does not by itself enable more advanced covenant mechanisms such as recursive covenants or transaction introspection. Instead, it changes the binding between a signature and a specific UTXO, allowing reuse across compatible candidates—one building block rather than a complete covenant system.

Cointelegraph Research additionally references academic work suggesting another theoretical angle: removing outpoint commitment might enable “recovered-key” constructions where a public key can be derived from a fixed signature and message pair such that the corresponding private key is provably unknown. In principle, that could force spending through a script path rather than a key path, potentially avoiding temporary keys used in some script-path-only designs. However, the piece stresses that this observation appears in research literature rather than representing a BIP-118 design proposal.

The main downside: signature replay risk

The most important concern with SIGHASH_ANYPREVOUT signatures is signature replay. Cointelegraph Research explains that because the signature does not commit to a specific outpoint, the same signature can be used to spend a different UTXO than the one originally intended—so long as the new UTXO satisfies the other committed fields.

The severity depends on configuration and surrounding assumptions. The research highlights situations where replay becomes more pronounced, such as:

• Using ANYPREVOUT | SINGLE when output amounts can be rearranged.


• Having a separate UTXO with the same scriptPubKey and amount in the case of ANYPREVOUT.


• Having compatible script structures that include the same public key in the case of ANYPREVOUTANYSCRIPT.


• Miner influence over transaction ordering and inclusion that could potentially be exploited under certain conditions.

At the same time, Cointelegraph Research emphasizes that these are not unavoidable flaws. They generally require deliberate misuse or failure to account for replay conditions during protocol design and implementation.

Looking ahead, Cointelegraph Research says the next article will move from signature mechanics to “supporting tools”—opcodes that expand what Bitcoin script can express or how data can be handled, but don’t provide covenant behavior on their own. For readers tracking SIGHASH_ANYPREVOUT’s relevance, the open watchpoints are straightforward: how developers plan to mitigate replay risk, which taproot spend patterns emerge in practice, and whether future covenant constructions can leverage the relaxed outpoint binding without introducing new operational fragility.

https://www.cryptobreaking.com/bitcoin-covenants-part-3-sighash_anyprevout/?utm_source=blogger%20&utm_medium=social_auto&utm_campaign=Bitcoin%20Covenants%20Part%203:%20SIGHASH_ANYPREVOUT%20Explained%20for%20Builders%20