SIGHASH_ANYPREVOUT

BIP 118 defines two new signature-hash values. SIGHASH_ANYPREVOUT omits the outpoint from the digest but still commits to the amount and the script of the output being spent. SIGHASH_ANYPREVOUTANYSCRIPT omits the outpoint, the amount, the script and the tapleaf hash, so the signature commits to even less. The two differ in how much of the spent output the signature binds to, and the choice matters for what a rebinding can do.

The proposal is specified as a modification to the signature opcodes introduced by BIP 342. A public key of a particular form is treated as a BIP 118 key, and a signature made with it is validated against a digest computed with the outpoint removed. The specification also sets a distinct key version for these signatures, so that a signature valid for an ordinary tapscript key is not also valid for a BIP 118 key, and the reverse.

The proposal builds on the script-tree structure defined by Taproot, and it is often discussed alongside the covenant proposals, because both address limits in what a Bitcoin script can express about how an output is spent.

Removing the commitment to a specific output has a consequence the proposal states plainly: a signature can be replayed. An ordinary signature commits to the input it spends, so it can only be used once. A SIGHASH_ANYPREVOUT signature can be valid for any output with a compatible script and, for the ANYPREVOUT form, the same amount, which means the same signature could authorise more than one spend.

That property is not an oversight; it is the mechanism. The channel construction the flag was designed for depends on a signature being rebindable to whichever output ends up holding the channel's funds. The design's answer to the replay risk is to keep the flag opt-in and narrow: only a script that deliberately includes a BIP 118 key can be spent this way, and the proposal does not apply to key-path spends, so an address that does not opt in is unaffected.

The narrower form, SIGHASH_ANYPREVOUT, commits to the amount and the script, which limits replay to outputs that share both. The broader form, SIGHASH_ANYPREVOUTANYSCRIPT, commits to neither, and its replay surface is correspondingly larger. The distinction is the reason the proposal offers two values rather than one, and it is the part of the design a reader evaluating the proposal should weigh most carefully.

What is specified is BIP 118 itself: the key type, the two signature-hash values, the digest construction and the validation rules. The specification is complete enough to implement, and reference implementations and test vectors have been produced in the proposal process.

What is implemented is limited to that proposal work. The flag is not active on the Bitcoin network, it is not part of Bitcoin Core's consensus rules, and no node enforces it. A transaction using it would be rejected today. The eltoo construction that motivated the flag likewise cannot be deployed on the main chain without the consensus change.

What is not deployed is therefore everything that depends on the flag: eltoo channels, LN-Symmetry-style updates, and any other construction that needs a signature to rebind to a different output. The proposal's status is Draft, and the page presents it as such rather than implying a timeline. A reader should treat every capability described here as proposed, not available.