Input
Bitcoin transaction inputs explained: an input names an earlier output by TXID and VOUT, then unlocks it. Learn its five fields, sizes and examples.
By Dimitar Zurnov · Updated 4 Nov 2026
Adapted from Learn Me a Bitcoin by Greg Walker.
A transaction input is a reference to an earlier output, plus the code that unlocks it. It holds a TXID and a VOUT to name the output, a ScriptSig to unlock it, and a sequence number. Each input spends exactly one output. Once the transaction is mined, that output counts as spent.
A transaction usually has one or two inputs. It needs as many as it takes to cover the amount it sends and the fee.
What does an input do?
An output is a UTXO until something spends it. To spend it, a new transaction names it in one of its inputs and supplies the unlocking code. The network checks that the code satisfies the lock, and if it does, the output is marked as spent.
An input does not carry a value. The raw data holds the reference and the unlocking code, but not the amount that the referenced output held. To learn that amount, you look at the transaction that created the output. That is also why a wallet has to track which outputs it can spend.
What are the fields of an input?
Every input has the same five fields, repeated once per input.
| Field | Size | Format | What it holds |
|---|---|---|---|
| TXID | 32 bytes | Natural byte order | The hash of the transaction that created the output. See TXID. |
| VOUT | 4 bytes | Little-endian integer | The index of the output in that transaction, counted from 0. See VOUT. |
| ScriptSig size | Variable | Compact size | The length in bytes of the ScriptSig that follows. |
| ScriptSig | Variable | Script | The unlocking code for a legacy lock. Empty for native segwit inputs. See ScriptSig. |
| Sequence | 4 bytes | Little-endian bit field | Finality settings: locktime, RBF and relative locktime. See sequence. |
The TXID and VOUT together form an outpoint, a unique label for one output on the chain. Native segwit inputs keep the same five fields, but their unlocking data moves to the witness section, so their ScriptSig size is 00. A segwit input wrapped in P2SH-P2WPKH keeps a short ScriptSig, which pushes the 22-byte witness program.
What does a one-input transaction look like?
This transaction, 05d350c8a65010bbe9d220b2accd7601b4c6541b7c6d7f5ad451efbcc07f8d66, is about as simple as a transaction gets. Here is its raw data:
02000000019945a5a440f2d3712ff095cb1efefada1cc52e139defedb92a313daed49d5678010000006a473044022031b6a6b79c666d5568a9ac7c116cacf277e11521aebc6794e2b415ef8c87c899022001fe272499ea32e6e1f6e45eb656973fbb55252f7acc64e1e1ac70837d5b7d9f0121023dec241e4851d1ec1513a48800552bae7be155c6542629636bcaa672eee971dcffffffff01a70200000000000017a9148ce773d254dc5df886b95848880e0b40f10564328700000000
Its input reads:
- TXID:
9945a5a440f2d3712ff095cb1efefada1cc52e139defedb92a313daed49d5678, which the explorer shows reversed as78569dd4…. - VOUT:
01000000, so output 1 of that transaction. - ScriptSig size:
6a, which is 106 bytes. - ScriptSig: a 71-byte signature with its sighash byte, then a 33-byte compressed public key. That is the unlock for a P2PKH lock.
- Sequence:
ffffffff, which is final.
The transaction has one output. Its amount field is a702000000000000. In little-endian that is 02a7, or 679 satoshis. The output is a P2SH lock.
How does one transaction spend several outputs?
Some payments need more than one input. Suppose a wallet holds two small outputs and wants to send more than either one. It spends both, and the transaction has two inputs.
Transaction 42563ae3e391d74de7160e64ebfc730885306faad799197b80ebe5fb1386b7a2 does exactly that. Its inputs name two outputs: output 25 of one transaction, worth 1,000,000 satoshis, and output 31 of another, worth 6,690,000 satoshis. Together they fund one output of 7,684,711 satoshis. The inputs add up to 7,690,000, so the 5,289 satoshis left over are the fee.
More inputs make a bigger transaction. Each input adds its own signature and public key, so the size grows with every input. That affects the fee, because miners rank transactions by fee per virtual byte.
What is a coinbase input?
The first transaction in every block is the coinbase. Its single input is special. It does not spend an earlier output, so its TXID is 32 zero bytes and its VOUT is ffffffff. The miner puts whatever data it likes in the ScriptSig, within 2 to 100 bytes. The coinbase gets its own page: see coinbase.
From block 227,931 onward, BIP 34 requires the ScriptSig of a coinbase input to start with the height of the block. Our block height page explains why that helps tell blocks apart.
Can you choose which inputs to use?
Yes, with the right wallet. The inputs of a transaction are the coins it spends, so choosing inputs is choosing coins. Wallets call this coin selection or coin control.
Many wallets pick inputs for you, and they try to keep the fee low by using as few inputs as possible. Others let you pick the outputs yourself. That can help privacy: if you do not want two payments linked, you can keep their coins apart. It can also help fees. Combining many small outputs into one larger output while fees are low saves money when you spend later, when fees may be higher.
The next page, TXID, explains the first field of each input: how the hash that names the earlier transaction is built.
Sources
- BIP 34: Block v2, height in coinbase
- Bitcoin Core source, chainparams.cpp, for the BIP 34 activation height of 227,931
In this section: Transactions
Something look wrong? Tell us