Skip to content
buybitcoinsmart

Glossary / Transactions & fees

SIGHASH_ALL

Definition
SIGHASH_ALL is the flag that makes a signature commit to every input and every output of a transaction, so nothing about the payment can be changed after signing.

This is the flag your wallet uses, and it is the reason approving a transaction on a hardware wallet screen means something. Its value is 1, and you can see it as the final byte of almost every signature on a block explorer. Taproot renamed the default to SIGHASH_DEFAULT and stopped writing the byte at all, saving one byte per signature.

How it works

Under SIGHASH_ALL the digest covers the transaction version, every outpoint being spent, every sequence number, every output amount, every output script, and the locktime.

Change a single satoshi of a single output and every signature on the transaction dies. Add an input, delete an output, reorder them, nudge the locktime: same result. That is what people mean when they say a signed bitcoin transaction is final in content before it is even broadcast. The only decision left to anybody is whether to send it.

One thing is deliberately excluded: the unlocking scripts of the other inputs. If the digest covered those, then in a two signer transaction each signature would have to be made after the other one, which is circular and impossible. Leaving them out is what lets independent parties sign the same transaction in any order they like.

The encoding varies by input type. On a legacy or segwit version 0 input, the byte 01 is appended to the DER encoded signature, which is where the familiar 71 or 72 byte total comes from. On a Taproot key path spend, BIP341 defines a value of zero as SIGHASH_DEFAULT, meaning identical coverage with no byte written at all, so the signature is exactly 64 bytes. Writing 01 explicitly on a Taproot input is still valid and produces the same digest, it just costs an extra byte for nothing.

Where you see it

SIGHASH_ALL is used almost everywhere: Bitcoin Core, Electrum, Sparrow, every hardware wallet, and every exchange withdrawal engine sign this way by default, and none of them offers a setting to change it.

The practical consequence is the one you feel when a payment is stuck. Since the fee is whatever is left over between the inputs and the outputs, and the outputs are all signed, you cannot shave a few thousand satoshis off an output to raise the fee. The transaction has to be rebuilt and signed again from the beginning, which only the wallet holding the keys can do. That is why replace-by-fee is a sending wallet feature rather than something an exchange or a block explorer can perform on your behalf, and why child-pays-for-parent exists as the escape hatch when the sender is unreachable.

It is also what turns a hardware wallet screen into a contract rather than a suggestion. The device shows the destination, the amount, and the fee, and because the signature it then produces covers all three, no software downstream can alter any of them without throwing that signature away. Approve what the screen says and nothing else can happen.

SIGHASH_ALL vs SIGHASH_NONE

SIGHASH_ALL commits to the full output list; SIGHASH_NONE commits to none of it. The gap between them is the gap between a payment and a bare authorization to move a coin somewhere unspecified. The two flags sit one value apart, so a signing library that accepts the flag as an integer parameter is one typo away from turning a customer withdrawal into a coin anyone watching the mempool can redirect. Production signing code should hard-code the value rather than take it as input.

Not to be confused with

Frequently asked questions

Do I ever need to choose a sighash flag?

No. Consumer wallets sign with SIGHASH_ALL and do not expose the choice, which is the right default. The other flags exist for protocol builders assembling transactions collaboratively, not for ordinary payments.

If everything is signed, how can a fee be bumped?

It cannot be edited. Replace-by-fee builds a completely new transaction spending the same coins with a higher fee and signs it again, which is why only the wallet holding the private keys can bump a fee.

Read next

Related terms

More in Transactions & fees