That is Half 3 within the technical article sequence about Bitcoin covenants by Cointelegraph Analysis. To learn the earlier article click on right here.
SIGHASH_ANYPREVOUT, as proposed in BIP 118, builds on the sooner SIGHASH_NOINPUT idea talked about within the 2015 Lightning Community paper by Joseph Poon and Thaddeus Dryja, and later formally proposed by Joseph Poon on the bitcoin-dev mailing checklist in February 2016.
SIGHASH_ANYPREVOUT is just not a brand new opcode however a proposed new worth for the SIGHASH flag, designed to be deployed as a soft-fork improve to Bitcoin. The SIGHASH flag is appended to a signature and determines which components of a transaction are signed and shall be checked by the CHECKSIG opcode. The chosen flag is chosen by the signer, not enforced by the scriptPubKey. As a result of technical particulars associated to upgradability in a softfork, the SIGHASH_ANYPREVOUT proposal solely extends to spends from taproot addresses.
A wide range of commonplace SIGHASH modes exist already, as illustrated in Determine 1. If the flag is ready to SIGHASH_ALL, the signature should cowl all inputs, all outputs, and the particular outpoint being spent, thus cryptographically binding the authorization to that precise UTXO. An outpoint is the mix of a transaction ID and an output index that collectively uniquely establish which UTXO a transaction is consuming. With SIGHASH_NONE, solely the inputs have to be signed, leaving the outputs unconstrained. The SIGHASH_SINGLE variant indicators all inputs, however solely the output on the similar index because the enter being signed. The ANYONECANPAY modifier introduces additional flexibility by permitting a single enter to be signed independently of the others. Crucially, none of those current modes permits a signature to omit dedication to the outpoint. That restriction is what SIGHASH_ANYPREVOUT removes.
BIP-118 defines two ANYPREVOUT variants that differ in how a lot of the earlier output they omit from the digest, summarised in Determine 2. Beneath SIGHASH_ANYPREVOUT, the outpoint is excluded from the digest, however the signature nonetheless commits to the quantity and scriptPubKey of the earlier output, in addition to the enter’s nSequence. Beneath SIGHASH_ANYPREVOUTANYSCRIPT, the quantity and scriptPubKey are additionally excluded, that means the signature is just not sure to the locking script of the spent output in any respect. All different commitments comply with the usual Taproot signature message development and depend upon the chosen base flag, corresponding to SIGHASH_ALL or SIGHASH_SINGLE.
As a result of the outpoint is omitted from the digest, the identical signature can authorize spending any appropriate UTXO that satisfies the remaining dedicated fields. For instance, a transaction pre-signed with ANYPREVOUT | ALL to provide a 0.5 BTC output may be reused if the identical tackle later receives one other UTXO of 0.5 BTC, even when the personal key used to create the unique signature is now not accessible. If the brand new UTXO holds greater than 0.5 BTC, nonetheless, the surplus shall be misplaced to miners except the unique signature included a change output. This rebinding property is what makes ANYPREVOUT helpful for layer-2 protocols, the place the identical pre-signed transaction should apply to a number of doable on-chain UTXOs with out requiring new signatures for each.
For covenant-like functions, the ANYPREVOUT variants protect dedication to the scriptPubKey of the earlier output, and are usually probably the most related. They permit signatures to be reused throughout appropriate UTXOs whereas making certain funds stay sure to the identical locking script. ANYPREVOUTANYSCRIPT removes this binding solely and is due to this fact much less suited to covenant-style functions.
Much like OP_CTV, SIGHASH_ANYPREVOUT improves on the logic already achievable with pre-signed transactions however doesn’t by itself allow recursive covenants or transaction introspection. As an alternative, it relaxes the binding between a signature and a particular UTXO, permitting a signature to be reused throughout a number of appropriate UTXOs.
Some analysis has additionally famous that eradicating the outpoint dedication makes recovered-key constructions doable — that’s, a public key may be derived from a hard and fast signature and message pair such that the corresponding personal secret is provably unknown to anybody, making the UTXO’s key path provably unspendable and forcing any spend by means of the script path. It will keep away from the necessity for momentary keys, that are in any other case required to make the important thing path unspendable in constructions that depend on script-path-only enforcement. This statement seems in Bitcoin Covenants: Three Methods to Management the Future by Jacob Swambo et al. (2020), though it stays a theoretical development quite than a design proposed in BIP-118.
The first threat related to SIGHASH_ANYPREVOUT signatures is signature replay. As a result of these signatures don’t decide to a particular outpoint, the identical signature can be utilized to spend a distinct UTXO than the one initially meant, offered the brand new UTXO satisfies the remaining dedicated fields. This threat turns into extra pronounced in particular configurations: when ANYPREVOUT | SINGLE is used and output quantities may be rearranged; when a separate UTXO exists with the identical scriptPubKey and quantity, within the case of ANYPREVOUT; when the identical public key seems in a appropriate script, within the case of ANYPREVOUTANYSCRIPT; or when a miner can affect transaction ordering and inclusion to take advantage of these circumstances. Nevertheless, these eventualities require both deliberate misuse or a failure of the person or developer to account for replay circumstances throughout protocol design.
In our subsequent article we are going to start our dialogue of Opcodes that function supporting instruments. These lengthen the expressiveness of Bitcoin script or information dealing with however don’t implement covenant performance except mixed with different opcodes. On this subsequent class, we are going to talk about OP_CHECKSIGFROMSTACK and OP_CAT.