Bitcoin Covenants Part 3: SIGHASH_ANYPREVOUT Explained for Builders
Bitcoincovenants continue to be explored through incremental, deployable changes to the protocol—rather than sweeping new functionality. InCointelegraphResearch’s technical series, the focus shifts. . .
Bitcoincovenants continue to be explored through incremental, deployable changes to the protocol—rather than sweeping new functionality. InCointelegraphResearch’s technical series, the focus shifts toSIGHASH_ANYPREVOUT, a proposed soft-fork upgrade that changes howBitcoinsignatures bind to the transaction they authorize. As described inBIP 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 takeawaysSIGHASH_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 commitmentsto the previous output’s amount,scriptPubKey, and the input’snSequence;SIGHASH_ANYPREVOUTANYSCRIPTrelaxes thescriptPubKeycommitment 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 spendsunder the proposal’s design. Why outpoint binding matters in Bitcoin signaturesIn Bitcoin, the SIGHASH flag is appended to a signature and determines what parts of a transaction are included in the data that theCHECKSIGopcode verifies. The signer chooses the SIGHASH value; it is not enforced byscriptPubKey. The upshot is that different SIGHASH modes control how tightly a signature is cryptographically bound to the transaction structure. CointelegraphResearch notes that Bitcoin already has several standard SIGHASH behaviors. For example, withSIGHASH_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 likeSIGHASH_NONEandSIGHASH_SINGLEloosen what outputs are committed to, whileANYONECANPAYallows 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 variantsAccording to BIP 118, SIGHASH_ANYPREVOUT defines two variants that differ in how much of the previous output remains in the signing digest. SIGHASH_ANYPREVOUTexcludes the outpoint from the digest. But the signature still commits to several other fields: the previous output’samountandscriptPubKey, along with the input’snSequence. 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_ANYPREVOUTANYSCRIPTgoes further by also excluding the previous output’s amount andscriptPubKey. 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 asSIGHASH_ALLorSIGHASH_SINGLE). How signature reuse could work—and why it matters for layer-2The practical effect of leaving the outpoint out of the digest is that the same signature can authorize spendinganycompatible UTXO that matches the remaining committed fields. Cointelegraph Research provides a concrete example: a transaction pre-signed underANYPREVOUT | ALLto create a0. 5BTCoutput could be reused later if the address receives a different0. 5BTCUTXO. 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 missingFor covenant-like applications, the research notes a crucial distinction. SIGHASH_ANYPREVOUTpreserves commitment to the previous output’sscriptPubKey, making it more relevant thanSIGHASH_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 asrecursivecovenants 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 riskThe most important concern with SIGHASH_ANYPREVOUT signatures issignature 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:UsingANYPREVOUT | SINGLEwhen output amounts can be rearranged. Having a separate UTXO with the samescriptPubKeyand amount in the case ofANYPREVOUT. Having compatible script structures that include the same public key in the case ofANYPREVOUTANYSCRIPT. 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. Risk & affiliate notice:Crypto assets are volatile and capital is at risk. This article may contain affiliate links. Read full disclosure