BA-14 · LESSON 01

Raw transaction construction

KEY DEFINITIONS

Terms used in this lesson

Witness: Signatures, scripts, or other data supplied to satisfy a Bitcoin output’s spending condition.
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.
BIP143: The Bitcoin Improvement Proposal that defines the version-zero SegWit transaction signature digest used by native P2WPKH and P2WSH spends.
Outpoint: A transaction ID plus output number that identifies one exact prior output.
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.
Witness transaction ID: An identifier that commits to a transaction including its witness data.
P2WPKH: Pay to Witness Public Key Hash: a native SegWit output for one public-key hash.
Preimage: The original secret data whose hash equals a previously committed value.
DER: Distinguished Encoding Rules: the structured byte encoding historically used for ECDSA signatures in Bitcoin Script.
ECDSA: Elliptic Curve Digital Signature Algorithm, the signature scheme used by pre-Taproot Bitcoin outputs.

Engineers serialize fields, compute sighashes, sign inputs, and inspect witnesses without relying solely on wallet abstractions.

35 min Difficulty 3/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 · state machineOne valid action transforms a known stateSelect any state to inspect its exact role.

RELATIONSHIP MAPOrdered mechanism flow

01
BEFOREKnown state
Identify the facts and objects that exist before the action.
02
ACTIONRaw transaction construction
The Raw transaction construction lesson isolates the event that proposes a change.
03
RULEDeterministic check
The enforcing rule accepts or rejects the proposed transition.
04
AFTERSuccessor state
Accepted work creates a new state without silently changing the prior facts.
05
FAILUREState unchanged
A failed condition must not produce a partially accepted successor.

Rule shown: A valid transition names the prior state, action, enforcing rule, and successor state.

STAGE 1 OF 5BEFORE: Known state

Identify the facts and objects that exist before the action.

Governing relationship: A valid transition names the prior state, action, enforcing rule, and successor state. Complete path: 1. BEFORE, Known state. Identify the facts and objects that exist before the action. 2. ACTION, Raw transaction construction. The Raw transaction construction lesson isolates the event that proposes a change. 3. RULE, Deterministic check. The enforcing rule accepts or rejects the proposed transition. 4. AFTER, Successor state. Accepted work creates a new state without silently changing the prior facts. 5. FAILURE, State unchanged. A failed condition must not produce a partially accepted successor.

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

BEFORE

Start from separately serialized version, inputs, outputs, witness stacks and locktime plus the referenced amount and scriptCode for the second input.

MECHANISM

Record each outpoint, amount, scriptPubKey, confirmation state, key path, and spending type. Signature and fee calculation require correct prior-output data.

AFTER

Learner-constructed canonical bytes, a recomputed digest, and mathematical signature verification are evidence; a fixture label is not.

Text equivalent: Starting from Start from separately serialized version, inputs, outputs, witness stacks and locktime plus the referenced amount and scriptCode for the second input. The mechanism begins when Record each outpoint, amount, scriptPubKey, confirmation state, key path, and spending type. Signature and fee calculation require correct prior-output data. The resulting lesson is Learner-constructed canonical bytes, a recomputed digest, and mathematical signature verification are evidence; a fixture label is not.

2. Mechanism pathSelect a stage to inspect its job

STAGE 1 OF 5

Freeze input facts

Record each outpoint, amount, scriptPubKey, confirmation state, key path, and spending type. Signature and fee calculation require correct prior-output data.

Complete path: 1. Freeze input facts: Record each outpoint, amount, scriptPubKey, confirmation state, key path, and spending type. Signature and fee calculation require correct prior-output data. 2. Design outputs and fee: Decode destination scripts, calculate payment and change in satoshis, estimate weight, and ensure inputs equal outputs plus fee. 3. Serialize the unsigned form: Encode version, compact-size vectors, outpoints, scriptSig placeholders, sequence, values, scripts, and locktime with field-specific byte order. 4. Compute and sign each digest: Use the exact legacy, SegWit, or Taproot sighash algorithm and mode for each input, then insert correctly encoded signatures and witness data. 5. Decode and test before broadcast: Round-trip decode, compare txid and wtxid, run node test-mempool acceptance, inspect fee and policy result, then broadcast intentionally.

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

ACCEPTED PATH

The learner-built transaction must use canonical serialization, conserve integer satoshis, bind the selected prior output and sighash, verify its signature, round-trip independently, and receive the predicted Core result.

CHANGED CONDITION

A noncanonical CompactSize, wrong outpoint value, negative fee, covered-byte mutation, bad signature, missing input, or policy rejection leaves the transaction unaccepted.

Important distinction: If raw transaction hex decodes successfully, it is safe and valid to broadcast. Decoding proves structural parse only. Inputs, values, signatures, locks, fee, policy, and intent can still be wrong.

Text equivalent: The accepted path is enforced by The learner-built transaction must use canonical serialization, conserve integer satoshis, bind the selected prior output and sighash, verify its signature, round-trip independently, and receive the predicted Core result. If the required condition changes, A noncanonical CompactSize, wrong outpoint value, negative fee, covered-byte mutation, bad signature, missing input, or policy rejection leaves the transaction unaccepted.

Loading lesson visuals...

Learn the idea

Raw transaction construction means choosing and serializing every Bitcoin transaction field without delegating the complete job to a wallet. The engineer identifies prior outputs, builds version, inputs, outputs, sequence, witness, and locktime, computes each signature hash, signs, finalizes, and asks a node to validate before broadcast.

GUIDED EXPLANATION1/5 ideas inspected

Freeze input facts

Record each outpoint, amount, scriptPubKey, confirmation state, key path, and spending type. Signature and fee calculation require correct prior-output data.

The worked example follows the explanation

Inspect every idea above to open it.

Important distinction“If raw transaction hex decodes successfully, it is safe and valid to broadcast.”

Decoding proves structural parse only. Inputs, values, signatures, locks, fee, policy, and intent can still be wrong.

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.