BA-06 · LESSON 03

Signature checks and sighashes

KEY DEFINITIONS

Terms used in this lesson

CHECKSIG: The Bitcoin Script operation that checks whether a signature is valid for the required public key and transaction message.
Sighash: The exact transaction digest and signature mode that determine which fields a Bitcoin signature authorizes.
Transaction ID: The identifier produced by hashing a Bitcoin transaction’s non-witness serialization.
SIGHASH mode: A Bitcoin signature mode describing which transaction fields the signature commits to.
SIGHASH NONE: A signature-hash choice that does not commit to transaction outputs.
SIGHASH SINGLE: A signature-hash choice that commits to the output with the same index as the signed input, subject to its defined edge cases.
ANYONECANPAY: A signature-hash modifier that commits only to the current input rather than every input.
SegWit: Segregated Witness: a Bitcoin upgrade that separates authorization data from the transaction identifier and introduces versioned witness programs.
Taproot: A Bitcoin output and spending design that can combine a public-key path with privately committed alternative scripts.
ECDSA: Elliptic Curve Digital Signature Algorithm, the signature scheme used by pre-Taproot Bitcoin outputs.
BIP340: The Bitcoin Improvement Proposal specifying Schnorr signatures for the secp256k1 curve.
Schnorr signature: Bitcoin’s Taproot signature scheme, whose algebra supports compact verification and advanced multi-party signing.
CHECKSIGVERIFY: A Bitcoin Script signature check that fails execution immediately when the signature is invalid.
BIP143: The Bitcoin Improvement Proposal that defines the version-zero SegWit transaction signature digest used by native P2WPKH and P2WSH spends.
BIP341: The Bitcoin Improvement Proposal specifying Taproot output validation and the transaction signature message used by Taproot signatures.
DER: Distinguished Encoding Rules: the structured byte encoding historically used for ECDSA signatures in Bitcoin Script.
UX: User experience: how a person understands and interacts with a product or device.

CHECKSIG validates a signature over a transaction digest selected by a sighash mode.

55 min Difficulty 2/5 Not started

VISUAL MODEL

See the whole mechanism before going step by step

Use the diagrams to orient yourself. Then the guided explanation below teaches every part in depth.

4 explanatory views

CONCEPT-SPECIFIC MAP · sighash boundaryA signature authorizes a defined transaction commitmentSelect any state to inspect its exact role.

RELATIONSHIP MAPOrdered mechanism flow

01
PREVOUTtxid:vout, amount, and script
SegWit signature hashing commits the input to its previous output data.
02
SIGHASHALL
All inputs and all outputs are committed.
03
MESSAGEComplete transaction field set
Serialization and sighash rules produce the 32-byte message digest.
04
CHECKSIGSignature and public key
The opcode verifies the signature against that digest and public key.
05
BOUNDARYAny input or output change fails
Later lessons cover why alternative sighash commitments require deliberate protocol design.

Rule shown: The sighash type decides which transaction fields enter the message digest; it never signs a vague human intention.

STAGE 1 OF 5PREVOUT: txid:vout, amount, and script

SegWit signature hashing commits the input to its previous output data.

Governing relationship: The sighash type decides which transaction fields enter the message digest; it never signs a vague human intention. Complete path: 1. PREVOUT, txid:vout, amount, and script. SegWit signature hashing commits the input to its previous output data. 2. SIGHASH, ALL. All inputs and all outputs are committed. 3. MESSAGE, Complete transaction field set. Serialization and sighash rules produce the 32-byte message digest. 4. CHECKSIG, Signature and public key. The opcode verifies the signature against that digest and public key. 5. BOUNDARY, Any input or output change fails. Later lessons cover why alternative sighash commitments require deliberate protocol design.

1. State transitionWhat exists, what changes, and what results

BEFORE

Alice signs an input with SIGHASH_ALL for outputs paying Bob 70,000 sats and change 28,000 sats.

MECHANISM

Validation needs the prior output's script and, for SegWit and Taproot signature hashes, its amount and other contextual data.

AFTER

A signature protects only the fields selected by its exact sighash algorithm and mode.

Text equivalent: Starting from Alice signs an input with SIGHASH_ALL for outputs paying Bob 70,000 sats and change 28,000 sats. The mechanism begins when Validation needs the prior output's script and, for SegWit and Taproot signature hashes, its amount and other contextual data. The resulting lesson is A signature protects only the fields selected by its exact sighash algorithm and mode.

2. Mechanism pathSelect a stage to inspect its job

STAGE 1 OF 5

Identify the spent output

Validation needs the prior output's script and, for SegWit and Taproot signature hashes, its amount and other contextual data.

Complete path: 1. Identify the spent output: Validation needs the prior output's script and, for SegWit and Taproot signature hashes, its amount and other contextual data. 2. Select committed fields: SIGHASH_ALL normally commits to all outputs. SIGHASH_NONE omits outputs, SIGHASH_SINGLE targets a corresponding output, and ANYONECANPAY changes which inputs are committed under defined combinations. 3. Construct the protocol digest: The node serializes and hashes fields exactly as defined for the output type. This is not the txid and may include data not present in the final transaction serialization. 4. Run signature verification: ECDSA or BIP340 Schnorr verification checks the signature equation using the public key and digest. 5. Return a Script result: CHECKSIG pushes true or false in ordinary form. CHECKSIGVERIFY fails immediately when verification is false.

3. Rule and failure boundaryWhat accepts the result and where it can stop

ACCEPTED PATH

The exact legacy, BIP143, or BIP341 digest is recomputed from transaction and prior-output context before DER ECDSA or BIP340 Schnorr verification.

CHANGED CONDITION

A covered-field mutation, wrong sighash mode, malformed signature, wrong key, or wrong prior-output amount changes verification and leaves the output unspent.

Important distinction: CHECKSIG verifies that the human-readable payment description was approved. It verifies a cryptographic signature over protocol-selected transaction fields. Wallet UX must accurately translate those fields for the signer.

Text equivalent: The accepted path is enforced by The exact legacy, BIP143, or BIP341 digest is recomputed from transaction and prior-output context before DER ECDSA or BIP340 Schnorr verification. If the required condition changes, A covered-field mutation, wrong sighash mode, malformed signature, wrong key, or wrong prior-output amount changes verification and leaves the output unspent.

Loading lesson visuals...

Learn the idea

OP_CHECKSIG verifies a signature for a public key against a transaction digest. A sighash mode selects which transaction fields the signature commits to. Legacy, SegWit version 0, and Taproot each define different digest algorithms. The signature is valid only for the exact digest, key, and signature encoding required by that spending context.

GUIDED EXPLANATION1/5 ideas inspected

Identify the spent output

Validation needs the prior output's script and, for SegWit and Taproot signature hashes, its amount and other contextual data.

The worked example follows the explanation

Inspect every idea above to open it.

Important distinction“CHECKSIG verifies that the human-readable payment description was approved.”

It verifies a cryptographic signature over protocol-selected transaction fields. Wallet UX must accurately translate those fields for the signer.

FINISH LEARNING FIRST

The questions unlock after every required learning activity

Inspect every guided idea, open the worked example, rebuild its mechanism, and complete the deterministic lesson tool. Your progress is saved automatically.