Constructing Transaction Inputs

How to build transaction inputs by referencing UTXOs. Each input points to a coin you're about to spend.

0steps ·

Progress 0/0

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:

FieldSizeDescription
Previous TX Hash32 bytesThe txid of the transaction that created the UTXO
Output Index4 bytesWhich output in that transaction (vout)
ScriptSigVariableUnlocking script (proof of ownership)
Sequence4 bytesUsed 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 0xfffffffe signals 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.