SIGHASH

SIGHASH (signature hash type) is a one-byte flag attached to the end of every Bitcoin signature that declares exactly which parts of a transaction that signature is committing to. By varying the flag, a signer can pin down the whole transaction or deliberately leave parts open for others to modify — the mechanism that makes collaborative and conditional transactions possible. It is a small field with outsized consequences: the flag decides what a signature actually promises.

The base flags

Three base types control how outputs are signed. SIGHASH_ALL (0x01), the overwhelming default, commits to all inputs and all outputs — the signature is void if anything material changes. SIGHASH_NONE (0x02) signs the inputs but no outputs, so the funds' destination is left mutable — effectively a blank cheque to whoever completes the transaction. SIGHASH_SINGLE (0x03) commits only to the single output at the same index as the signing input, letting other outputs be added or altered while protecting "your" output.

The ANYONECANPAY modifier

The flag SIGHASH_ANYONECANPAY (0x80) is OR-ed onto a base type. It restricts the signature to commit to only its own input, allowing anyone to add further inputs afterward without invalidating it. Combined with SIGHASH_ALL it enables crowdfunding-style constructions — "I will contribute this coin to exactly these outputs, and others may pile in" — while combinations with SINGLE or NONE support atomic swaps and other multi-party assemblies where participants sign their own piece and hand the transaction on.

Taproot changes and sharp edges

In legacy and SegWit v0 scripts the sighash byte rides along with the DER-encoded signature checked by OP_CHECKSIG. Under Taproot and Tapscript the digest is computed differently: Schnorr signatures use a new default mode (SIGHASH_DEFAULT) that behaves like SIGHASH_ALL, and the Taproot digest commits to the amounts and scriptPubKeys of all inputs being spent. That last change closed a long-standing hardware-wallet attack surface in which a signer could be lied to about input amounts and tricked into burning an enormous fee. The sharp edges are real: legacy SIGHASH_SINGLE with a signing input index beyond the last output degenerates into signing a trivial constant — a quirk that has caused genuine fund losses — and SIGHASH_NONE hands fee-and-destination control to counterparties. Most wallets only ever emit SIGHASH_ALL, but the other modes are the quiet plumbing behind PSBT collaboration, payment batching, and many Lightning and discreet-log-contract constructions. Understand what a flag leaves unsigned before you sign with it — the parts a signature does not cover are the parts someone else can rewrite.

Where you will actually meet these flags

In practice, three encounters cover most operators. First, PSBT workflows: multi-party signing flows carry a sighash type per input, and mismatched expectations between signers are a classic source of "why won't this finalize" confusion. Second, Lightning internals: commitment and justice transactions lean on specific sighash choices to let pre-signed transactions remain valid while other parts of the state evolve. Third, fee-bumping constructions: ANYONECANPAY variants allow inputs to be added to boost fees without re-signing everything, a pattern several protocols use deliberately. When auditing any script-based system, a reviewer's first questions are always the same: which flags are permitted, what does each leave unsigned, and who could exploit the unsigned degrees of freedom? If the design cannot answer crisply, the flags are a bug surface rather than a feature. The same lens works in reverse for learners: reading a well-designed protocol's sighash choices is one of the fastest ways to understand what each participant is actually promising, because the flag is the promise made precise. A signature is never just "I approve" — it is "I approve exactly these bytes, under exactly these assumptions," and the one-byte flag is where those assumptions are written down.