Signature hash

No signature covers the transaction as it appears on the wire. Each input gets its own digest, built by a procedure that has been rewritten twice: the original from 2009, BIP143 for segwit inputs, and BIP341 for Taproot. What the digest leaves out is what an attacker is free to change.

How it works

Building a signature hash means constructing a modified copy of the transaction and hashing that, not hashing the transaction you are about to broadcast.

The original procedure runs like this. Take the transaction, empty the unlocking script of every input, insert the script being spent into the single input you are signing, then keep, blank, or discard the outputs according to the flag. Append the flag as a four byte number, run SHA-256 over the whole thing twice, and sign the 32 bytes that come out.

That design carried a cost nobody noticed until transactions grew. Because each input rebuilds and rehashes the entire transaction, the work rises with the square of the input count. BIP143 puts figures on it: verifying an ordinary 1 MB block takes something like 2 seconds, while a single crafted 1 MB transaction carrying 5,569 signature operations can take 25 seconds. One transaction stalling every node on the network for that long is a denial of service waiting to be industrialized.

BIP143 rewrote the procedure for segwit version 0 inputs and fixed two problems at once. Three sub-hashes covering the outpoints, the sequence numbers, and the outputs are computed once and reused for every input, which makes the cost linear. More important for anyone holding coins, the digest now commits to the value of the input being signed. Before that a signing device had to be told what an input was worth with no way to check, so a malicious program could understate the inputs and trick a hardware wallet into approving an enormous fee.

BIP341 rewrote it a third time for Taproot. The Taproot digest is a tagged hash, prefixed with a domain string so it can never be mistaken for a digest from some other protocol, and it commits to the amounts and the locking scripts of every input being spent rather than only the signed one. It also introduces a default flag value of zero, which covers everything the standard rule covers but is never written into the signature.

Where you see it

You meet the signature hash indirectly, as the reason your hardware wallet behaves the way it does.

Signing a legacy input requires the device to be handed the full previous transaction, because that is the only way it can establish the input's value for itself. Sparrow and Electrum stream those transactions to a Trezor or Ledger before signing, and on a wallet full of old coins that step is why a spend takes noticeably longer than you expect. A segwit input needs only the amount, which the PSBT already carries.

It surfaces directly as the last byte of a legacy or segwit signature on a block explorer. A signature ending in 01 was made under the everything-covered rule. Any other value is worth understanding before you rely on the transaction.

Signature hash vs SIGHASH_ALL

The signature hash is the digest; SIGHASH_ALL is one of the rules for building it. Every signature has a signature hash, including Taproot signatures that carry no flag byte at all. What varies is which parts of the transaction went into the digest, and the flag is just the label for that choice. Saying a transaction "uses SIGHASH_ALL" describes a policy; saying it has a signature hash describes something every bitcoin signature in history has had.