MASTERING-BITCOIN · Unit 9 · Video 1 · Interactive Practice

Sign Here, But Only For This Part: Bitcoin SIGHASH Flags

IKey Reference

Flag Hex Inputs Committed Outputs Committed
SIGHASH_ALL 0x01 All inputs All outputs
SIGHASH_NONE 0x02 All inputs None (open)
SIGHASH_SINGLE 0x03 All inputs Only output at same index
ALL | ANYONECANPAY 0x81 This input only All outputs
NONE | ANYONECANPAY 0x82 This input only None (open)
SINGLE | ANYONECANPAY 0x83 This input only Only matching index

Commitment hash construction:

commitment_hash=SHA256(selected_tx_fields ∥ SIGHASH_byte)\text{commitment\_hash} = \text{SHA256}(\text{selected\_tx\_fields} \,\|\, \text{SIGHASH\_byte})

The SIGHASH byte is inside the hash, so it cannot be swapped without invalidating the signature.

IIVisualization 1: The SIGHASH Flag Explorer

Conceptual question: Which parts of a Bitcoin transaction does each SIGHASH flag actually commit to? Choose a flag below and watch how the "locked" (signed) and "open" (modifiable) regions of the transaction change.

⚙ interactive visualization — coming to this page format soon

Reflect: Notice how ANYONECANPAY strips the input commitment down to only Input B, leaving the other inputs open. And SINGLE only locks the output at the same index as the signer. Combining flags lets you express very precise authorizations — "I authorize my input, but I don't care about the outputs" or "I authorize all inputs and only my matching output."

IIIVisualization 2: Crowdfunding with ALL | ANYONECANPAY

Conceptual question: How does ANYONECANPAY enable a crowdfunding pattern where many donors can independently sign their contributions, while the destination address stays locked?

Use the slider to add donors one at a time and watch the funding total grow.

⚙ interactive visualization — coming to this page format soon

Notice: Because each donor used ANYONECANPAY, they only authorized their own input. Because they also used ALL for the output side, the destination address is pinned. The transaction grows safely as donors join — until the input total covers the goal and someone broadcasts it.

IVVisualization 3: Why the SIGHASH Byte is Self-Authenticating

Conceptual question: What happens if a malicious relayer tries to swap your SIGHASH flag from ALL to NONE? Toggle the "tamper" switch to see why the signature breaks.

⚙ interactive visualization — coming to this page format soon

Reflect: This is why the SIGHASH flag is self-authenticating. The flag chooses which fields go into the hash, but the flag byte itself is also hashed. Any attacker who flips the flag to weaken your authorization will produce a different commitment hash, and the signature will fail to verify.

VQuiz Questions

Question 1

A wallet signs a transaction with the default flag, SIGHASH_ALL (0x01). Which parts of the transaction does the signature commit to?

✅ Correct! SIGHASH_ALL is the most restrictive flag — it locks every input and every output.

❌ Not quite. SIGHASH_ALL is the default flag. It pins down everything — every input and every output.

Show solution

Solution:

SIGHASH_ALL is the default and most restrictive flag. It commits to every input and every output in the transaction.

Flag Inputs Outputs
ALL (0x01) all all
NONE (0x02) all none
SINGLE (0x03) all matching index
| ANYONECANPAY this input only (depends on base)

The first option (only this input; all outputs) describes ALL | ANYONECANPAY (0x81), not plain ALL.

Question 2

True or False: A miner or relayer can flip your SIGHASH byte from 0x01 (ALL) to 0x02 (NONE) to weaken your authorization, and your signature will still verify.

✅ Correct! The SIGHASH byte is hashed along with the transaction fields, so flipping it changes the hash and breaks the signature.

❌ Not quite. Remember: the SIGHASH byte is appended before SHA-256 runs, so it is part of what was signed. Tampering with it invalidates the signature.

Show solution

Solution:

The SIGHASH byte is inside the hash:

commitment_hash=SHA-256(selected_tx_fields ∥ SIGHASH_byte)\text{commitment\_hash} = \text{SHA-256}(\text{selected\_tx\_fields} \,\|\, \text{SIGHASH\_byte})

So the signer signs a hash that already includes the flag. If anyone flips the flag byte, the input to SHA-256 changes, the commitment hash changes, and the signature fails verification.

This is why we say SIGHASH is self-authenticating — the flag protects itself.

Question 3

A crowdfunding organizer publishes a transaction template with one fixed output (10 BTC to a campaign address) and zero inputs. Donors append their own inputs as they contribute.

Which SIGHASH flag should each donor use so that:

  1. New donors can keep adding inputs without invalidating existing signatures, and
  2. The destination address cannot be redirected?

✅ Correct! ALL | ANYONECANPAY lets each donor commit to only their own input while still pinning the destination output.

❌ Not quite. Think about both halves: ANYONECANPAY is needed so new inputs don't invalidate old signatures, and ALL (on outputs) is needed to pin the destination.

Show solution

Solution:

Walk through the requirements one at a time:

  1. New donors must be able to add inputs without breaking existing signatures. Plain ALL commits to every input, so adding a new input invalidates earlier signatures. We need ANYONECANPAY, which restricts each donor's input commitment to only their own input.

  2. The destination must be pinned. NONE leaves outputs open — a miner could redirect funds. We need ALL on the output side so every donor signs over the campaign output.

Combining these: each donor signs with ALL | ANYONECANPAY (0x81).

  • ❌ SIGHASH_ALL: breaks when a new donor adds an input.
  • ❌ SIGHASH_NONE: outputs unlocked — funds could be redirected.
  • ✅ ALL | ANYONECANPAY: own input only, all outputs locked.
  • ❌ NONE | ANYONECANPAY: own input only, but outputs open — destination not safe.

Question 4

A "bearer check" pattern uses two inputs in one transaction:

  • Input A is signed with SIGHASH_NONE.
  • Input B is signed with SIGHASH_ALL.

Why is this combination considered safe, even though NONE on its own would be dangerous?

✅ Correct! Input B's ALL signature locks the outputs for the whole transaction, neutralizing the risk of NONE on Input A.

❌ Not quite. Each signature is independent, but each one must verify against the final transaction. Look for the option that explains how one signer's ALL can protect the other's NONE.

Show solution

Solution:

Each input is signed independently, but the transaction as a whole is only valid if all signatures verify against the final transaction.

  • Input A's NONE signature commits to inputs but not outputs — by itself, a miner could rewrite the outputs.
  • Input B's ALL signature commits to all outputs. If a miner changes any output, Input B's signature breaks.

So the moment Input B's ALL signature is in the transaction, the outputs are effectively pinned for everyone. Input A's signer has authorized "spend my input however the group decides," while Input B's signer has authorized "spend with these specific outputs." Together, the transaction is safe.

This is a clean separation of concerns — one party authorizes funds, another determines where they flow.

The other options describe behavior that simply doesn't exist:

  • ❌ Flags are not "upgraded" when combined.
  • ❌ Miners don't pick the most restrictive flag — every signature must independently verify.
  • ❌ Combining signatures doesn't cancel ANYONECANPAY (which isn't even used here).

Solved: 0 / 4