Little bit of signature hashes
The Covenants Series
Signature Hashes
The CHECKSIG
opcodes in bitcoin’s Script
are the bread and butter of bitcoin transactions. One of the most popular ways to lock bitcoin into a UTXO is with a script which can only be unlocked by the holder of a private key. The CHECKSIG
-based scripts require the private key holders to create a signature with the private key to prove ownership. What do the holders sign for the signature? Well, the spending transaction itself! This is a double-whammy of proof-of-ownership of the key as well as proof that the owner wants to move the bitcoin in the UTXO. A transaction is a set of inputs and a set of outputs and usually all of them are hash’d and then signed. However, it is possible for an input to only “cover” a subset of the inputs or outputs. This is done through the SIGHASH
flag, included in the signature hash (so covered itself), which describes which inputs and outputs are being signed off by the signer.
ALL
– Signature applies to all inputs and outputs. The general case.NONE
– Signature applies to all inputs, none of the outputs. A “blank check”.SINGLE
– Signature applies to all inputs but only the one output with the same index number as the input. Dunno of a use case.ALL|ANYONECANPAY
– Signature applies to one input and all outputs. A “crowd fund” transaction.NONE|ANYONECANPAY
– Signature applies to one input, none of the outputs. A “dust” donation.SINGLE|ANYONECANPAY
– Signature applies to one input and the one output with the same index number as the input. Dunno of a use case.
Sig hashing is a cool concept, but it doesn’t seem like a ton of uses cases have taken off yet. Even coinjoin transactions, which I figured would use one of these, just use ALL
. I guess these more granular flags would give away who owns the resulting UTXOs.
Curiously though, sig hashes might actually allow for a form of covenants. Covenants is a loose term in bitcoin-land used to describe things which can limit how bitcoin is moved, not just how it is locked. So spending a UTXO goes from “hey, I own this private key” to “hey, I own this private key AND I am spending the bitcoin as specified”. An example covenant could be something like “outputs must be 100,000 sats”. Bitcoin needs a softfork of some sort to enable covenants and the level of complexity there is highly debated. But, one of the simpler proposals BIP118 which would add a new sighash flag ANYPREVOUT
would also enable some covenants through sighashes! The basic idea is that instead of an input setting a sighash flag, the output sets the flag in order to control parts of the spending transaction. The output doesn’t really care about the signature, it cares about the hash of the spending transaction outputs. A strange backdoor.