Bitcoin Transaction Signature Types (SIGHASH)

Introduction

Bitcoin is digital money that uses a distributed public ledger to record its transactions. To own bitcoin is to be able to spend it. Wallets provide the means and convenience to manage bitcoin assets by constructing, signing, and sending transactions to bitcoin addresses. During signing of Bitcoin transactions, SIGHASH flags are used to indicate which part of the transaction data is included and signed by the user's private key. In this article, we will look at SIGHASH flags in detail.

Signatures are used to signify the authenticity and integrity of messages and are a function of private key and the message (digest). In Bitcoin, signatures provide cryptographic proof that the sender is in control of the private keys required to authorize spending certain UTXOs. Importantly, the sender never has to reveal their private key(s), the signature can be verified using just the public key.

When talking about signatures, there are two important actions. One is crafting the signature, the other one is verifying it. The former make use of an algorithm to create a signature using a private key (the signing key) from a message (the transaction data). The later action uses an algorithm that allows anyone to verify the signature, given the message and a public key. For Bitcoin, the public key is usually part of the UTXO script that is publicly accessible on the ledger. When a user signs transaction data using their private key, anyone can use the corresponding public key to verify that it was indeed signed by the user with the private key and that it has not been modified.

Signatures are an essential part of the Bitcoin protocol. Most transactions in Bitcoin uses the Elliptic Curve Digital Signature Algorithm (ECDSA). ECDSA signatures are cryptographically secure digital signatures based on elliptic-curve cryptography (ECC). It is used by the script functions OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG, and OP_CHECKMULTISIGVERIFY.

Another signature algorithm used in Bitcoin is the Schnorr signature soft forked in since Taproot. They offer better privacy to multisig transactions and reduces the amount of signature data for such transactions.

In Bitcoin transactions, signatures are located in the scriptSig field of the input for non-segwit transactions and in witness field for segwit transactions. They consist of encoded parts r and s values and a flag called SIGHASH flag, which specifies which part of the transaction the signature signs.

ECDSA SIGNATURES: SIGNING AND VERIFICATION

The ECDSA algorithm takes a message msg and a private key privKey which is the user's private key and produces a signature as output which contains a pair of integers (r,s). The r and s values are both 256 bit (32-byte) integers.

The ECDSA algorithm is as follows:

𝑆𝑖𝑔=𝐹𝑠𝑖𝑔(𝐹ℎ𝑎𝑠ℎ(𝑚sg),privKey)

where:

privKey is the signing private key
msg is the transaction (or parts of it)
Fhash is the hashing function
Fsig is the signing algorithm
Sig is the resulting signature consisting of r and s.

Once the values r and s are calculated, they are encoded into a byte-stream using the Distinguished Encoding Rules (DER) encoding scheme. SIGHASH flags are then appended to the encoded data. They are usually between 71-73 bytes long. Unlike ECDSA signatures, Schnorr signatures are not DER-encoded and are between 64 to 65 bytes long.

In verifying a signature, the ECDSA algorithm takes the signed message msg and the signature {r, s} produced from the signing algorithm and the public key pubKey, corresponding to the signer’s private key, and returns true or false.

SIGNATURE HASH (SIGHASH) FLAGS

The SIGHASH flag is a single byte that is attached at the end of the signature. SIGHASH flags are used to signify which parts of the transaction data are being signed (see table below). Every signature in a Bitcoin transaction requires a SIGHASH flag for signing and verification purposes, and the flag can be different for each input. Schnorr signatures may omit the SIGHASH flag, defaulting to SIGHASH_DEFAULT.

Each transaction input may contain one or more signatures in its unlocking script. As a result, a transaction that contains multiple signatures may include signatures with different SIGHASH flags that commit to different parts of the transaction.

Flag	Modifier	Inputs Signed	Outputs Signed
SIGHASH_ALL	-	All	All
SIGHASH_ALL	ANYONECANPAY	One	All
SIGHASH_NONE	-	All	None
SIGHASH_NONE	ANYONECANPAY	One	None
SIGHASH_SINGLE	-	All	One at same index as input
SIGHASH_SINGLE	ANYONECANPAY	One	One at same index as input

SIGHASH Flags summary table

Currently, there are three standard types of SIGHASH flags SIGHASH_ALL, SIGHASH_NONE, and SIGHASH_SINGLE, and a modifier flag ANYONECANPAY.

1. SIGHASH_ALL (0x01) signifies that the signature covers all the transaction inputs and outputs.
2. SIGHASH_NONE (0X02) signifies that the signature covers all inputs and none of the outputs, while the
3. SIGHASH_SINGLE (0x03) signifies that the signature applies to all inputs but only a single output with the same index number as the signed input.

The modifier flag ANYONECANPAY can be combined with any of the above flags, as illustrated in the above table, to limit the signature to apply to a single input. Below are the combinations of ANYONECANPAY flags.

SIGHASH_ALL|SIGHASH_ANYONECANPAY flag (0x81) signifies that the signature applies to one input and all the outputs. The user can construct the transaction and allow others to amend it by adding inputs to the transaction.

The SIGHASH_NONE|ANYONECANPAY flag signifies that the signer commits to one input and none of the outputs. The common use case for this flag is dust collection. Dust represents tiny UTXO in the wallets and users cannot be able to construct valid transactions with such amounts as the transaction fees are often bigger than their value. Using this signature type, dust can be donated and collected as the user commits to only one input and anyone can claim the output.

The last flag combination is SIGHASH_SINGLE|ANYONECANPAY which signifies that the signature is for a single input and the corresponding output with the same index number. That is, if the input is at index 0, then the signature also covers the index 0 output. This enables multiple inputs from different signers to combine their transactions into a single transaction that pays each user their corresponding output.

Schnorr signatures have an extra SIGHASH_DEFAULT flag available to them, which is implicitly applied if no other SIGHASH flag is present. Signatures with this implicit flag are 64 bytes long. SIGHASH_DEFAULT functions the same as SIGHASH_ALL, committing to all inputs and outputs. However, if a Schnorr signature is 65 bytes long, it can not have a SIGHASH_DEFAULT flag to protect against malleability.

Each SIGHASH and any flags are checked by the script interpreter against these enums in Bitcoin Core.

Conclusion

As we have seen above, signatures are generated from a private key and a message and can commit to some or all inputs and outputs of a transaction, which allows for flexibility in transactions (see table above). Although most consumer wallets make use of SIGHASH_ALL which signs all inputs and outputs, it is useful to know that transactions are not limited to this type of signature.

Thank you for reading.

Reference:

• Bitcoin Developer Guide: Transactions
• Practical Cryptography for Developers by Svetlin Nakov: Digital Signatures
• Wikipedia: ECDSA
• Cryptobook: Elliptic Curve Signatures