Constructing Transaction Inputs
How to build transaction inputs by referencing UTXOs. Each input points to a coin you're about to spend.
0steps ·
What You’ll Learn
- The structure of a transaction input
- How inputs reference previous UTXOs
- The role of ScriptSig and sequence numbers
Input Structure
Each transaction input tells the network: “I want to spend this specific UTXO.” It contains four fields:
| Field | Size | Description |
|---|---|---|
| Previous TX Hash | 32 bytes | The txid of the transaction that created the UTXO |
| Output Index | 4 bytes | Which output in that transaction (vout) |
| ScriptSig | Variable | Unlocking script (proof of ownership) |
| Sequence | 4 bytes | Used for RBF and timelocks |
Here is what a single input looks like in hex (annotated):
# Previous TX Hash (32 bytes, little-endian)
7b1eabe0209b1fe794124575ef807057c77ada2138ae4fa8d6c4de0398a14f3f
# Output Index (4 bytes, little-endian)
00000000
# ScriptSig Length
00
# ScriptSig (empty for now — filled during signing)
# Sequence
fdffffff
Previous TX Hash: Pointing to the Coin
The Previous TX Hash is the txid of the transaction whose output you want to spend. One critical detail: it must be in little-endian byte order in the serialized transaction.
If the txid displayed by your block explorer is:
3f4fa19803dec4d6a84fae3821da7ac7577080ef754512794e1f9b20e0ab1e7b
You reverse the bytes to get the internal representation:
7b1eabe0209b1fe794124575ef807057c77ada2138ae4fa8d6c4de0398a14f3f
This is a common source of bugs for first-time transaction builders.
Output Index
The Output Index specifies which output within the referenced transaction you are spending. Transactions can have multiple outputs, so you need to specify exactly which one. Index 0 is the first output, 1 is the second, and so on.
This is encoded as a 4-byte little-endian integer:
0 → 00000000
1 → 01000000
2 → 02000000
ScriptSig: The Unlocking Script
The ScriptSig is where you prove you have the right to spend this UTXO. For a P2PKH output, the ScriptSig contains your signature and public key:
<signature> <public_key>
When a node validates your transaction, it runs the ScriptSig against the UTXO’s ScriptPubKey. If execution succeeds (returns true), the spend is authorized.
Important: When constructing the transaction for signing, the ScriptSig is left empty (length byte = 0x00). We fill it in during the signing step. This creates a chicken-and-egg situation — the signature depends on the transaction data, but the transaction includes the signature. Bitcoin solves this with a specific signing procedure we’ll cover later.
For SegWit inputs (P2WPKH), the ScriptSig is always empty. The unlocking data goes into the witness field instead — covered in Step 8.
Sequence Number
The 4-byte sequence field was originally designed for in-channel transaction replacement (an idea Satoshi had but never fully implemented). Today it serves two purposes:
- RBF signaling: A sequence value below
0xfffffffesignals that the transaction is replaceable via Replace-By-Fee (BIP125) - Relative timelocks: When used with
OP_CHECKSEQUENCEVERIFY(BIP112), it enforces a minimum age before the input can be spent
Common values:
ffffffff → Final (no RBF, no relative timelock)
fdffffff → RBF enabled, no relative timelock
For our tutorial transaction, we’ll use 0xfffffffd (fdffffff in little-endian) to enable RBF — a best practice that lets us bump the fee if needed.
Multiple Inputs
A transaction can have any number of inputs. If your UTXOs are small, you may need several to cover the amount you want to send. Each input adds roughly 41 bytes (without ScriptSig) to your transaction size, which means more fees — a practical consideration we’ll address in Step 5.
Next Step
Continue to Constructing Transaction Outputs to define where the bitcoin is going.