What if Bitcoin could reuse signatures across compatible UTXOs?

Cointelegraph Research has published Part 3 of a technical article about Bitcoin covenants. Click here to read the article before this one. here. 

SIGHASH_ANYPREVOUT proposBIP 118 builds upon the SIGHASH_NOINPUT idea that was first mentioned in BIP 117. 2015 Lightning Network paper by Joseph Poon and Thaddeus DryjaJoseph Poon, who later proposed the formal proposal bitcoin-dev mailing Check out the February 2016 list.

SIGHASH_ANYPREVOUT, which is not an opcode at all but rather a value proposed for the SIGHASH Flag in a Soft-Fork Upgrade to Bitcoin, does not represent a new code. The SIGHASH is appended to a signatory and defines which portions of a transaction will be verified by the CHECKSIG opcode. The flag selected is determined by the user, not by the system. scriptPubKey. The SIGHASH_ANYPREVOUT proposition only applies to spending from addresses that are taproot. This is due to technical issues related to upgrading a softfork.

There are a variety of SIGHASH standard modes, which can be seen in the Figure 1. When the flag is SIGHASH_ALL set, then the signature has to cover the inputs and outputs as well as the outpoint that’s being used, cryptographically binding authorizations to the UTXO. A transaction’s outpoint can be identified by a unique combination of a transaction index and a transaction ID. SIGHASH_NONE only requires the inputs to be signed. The outputs are left unconstrained. SIGHASH_SINGLE signs not only all inputs but also the output at exactly the same index. This ANYONECANPAY modifies the signature to allow a single input sign independently from all others. Importantly, in none of the modes available today can a signature be signed without committing to an outpoint. SIGHASH_ANYPREVOUT is designed to remove this restriction.

BIP 118 has two ANYPREVOUT versions that are different in terms of how much previous output is omitted from the digest. This can be seen in figure 2. SIGHASH_ANYPREVOUT omits the outpoint from the digest. However, it still commits both to the scriptPubKey, and the value of the previous output. 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. Other commitments are constructed using the Taproot standard signature message and depend on which base flag is selected, such as SIGHASH_ALL.

Due to the omission of the outpoint from the digest the same signature may authorize the spending of any compatible UTXO which satisfies all remaining fields. ALL, the signature can still be used, even if it is not possible to access the private key that created the initial signature.| 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. The excess UTXO will not be available to the miners if the new UTXO is greater than 0.5 BTC. This applies unless the signature originally included a “change output”. The rebinding feature is what gives ANYPREVOUT its uniqueness. useful for layer-2 protocolsThe pre-signed transactions must cover multiple UTXOs that may occur on-chain without requiring additional signatures.

In covenant applications, ANYPREVOUT preserves commitment to the scriptPubKey in the previous output and is typically most useful. These allow for signatures to remain the same across compatible UTXOs and funds to stay bound to a single locking script. This binding is removed completely by ANYPREVOUTANYSCRIPT, making it less suitable for covenant applications.

SIGHASH_ANYPREVOUT, similar to OP_CTV improves upon the logic that is already possible with presigned transactions. However, it does not enable recursive agreements or transaction introspection. The signature is not bound to a specific UTXO. Instead, the signature can be reused for 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. This would eliminate the requirement for temporary keys that are required in order to enforce script-path only constructions. This is an observation that appears in Bitcoin Covenants: Three Ways to Control the Future by Jacob Swambo et al. (2020)It is a theory, not a construction proposed by BIP-118.

SIGHASH_ANYPREVOUT Signatures pose a primary security risk. signature replay. These signatures are not committed to a single outpoint. Therefore, they can be used for a completely different UTXO, as long the new UTXO meets the other fields that have been commited. 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.| 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. These scenarios can only occur if there is a deliberate abuse or the developer or user fails to take into consideration replay conditions when designing protocol.

Next article, we’ll begin our discussion on Opcodes as support tools. The opcodes are designed to extend Bitcoin’s scripting or data handling, but not covenant functionality. Next, we’ll discuss OP_CHECKSIGFROMSTACK The following are some examples of how to get started: OP_CAT.