Overview
A transaction input is a reference to a previously created, unspent transaction output (UTXO) that the sender is consuming in a new transaction. Each input identifies which UTXO is being spent and provides cryptographic proof (typically a digital signature) that the spender is authorized to do so. A transaction can have one or many inputs, and the combined value of all inputs must be greater than or equal to the sum of all outputs plus the transaction fee.
Input Structure
Transaction Input (txin):
┌──────────────────────────────────────────────────────┐
│ │
│ Previous TX Hash (32 bytes) │
│ → Identifies the transaction containing the UTXO │
│ │
│ Output Index (4 bytes) │
│ → Which output of that transaction (0-indexed) │
│ │
│ ScriptSig / Witness (variable) │
│ → Proof of authorization to spend │
│ → Contains signature + public key (legacy) │
│ → Or witness data (SegWit) │
│ │
│ Sequence Number (4 bytes) │
│ → Used for RBF signaling and timelocks │
│ │
└──────────────────────────────────────────────────────┘
How Inputs Work
Previous Transaction (txid: abc123...):
┌──────────────────────────────┐
│ Output 0: 0.5 BTC → Alice │ ← This UTXO exists
│ Output 1: 0.3 BTC → Bob │
└──────────────────────────────┘
New Transaction (Alice spends her 0.5 BTC):
┌──────────────────────────────────────────┐
│ Input 0: │
│ prev_tx: abc123... │
│ output_index: 0 │
│ scriptSig: <Alice's signature> │
│ <Alice's public key> │
│ │
│ Output 0: 0.45 BTC → Carol (payment) │
│ Output 1: 0.04 BTC → Alice (change) │
│ │
│ Implied fee: 0.01 BTC (0.5 - 0.49) │
└──────────────────────────────────────────┘
Input Authorization
The method of proving authorization depends on the script type of the UTXO being spent:
| Script Type | Authorization Method |
|---|---|
| P2PKH | Signature + Public Key in ScriptSig |
| P2SH | Redeem script + signatures in ScriptSig |
| P2WPKH | Signature + Public Key in witness data |
| P2WSH | Witness script + signatures in witness |
| P2TR | Schnorr signature (key path) or script (script path) in witness |
Multiple Inputs
Transactions frequently have multiple inputs to gather enough value for the desired payment:
Input 0: 0.1 BTC (from tx aaa...) ─┐
Input 1: 0.2 BTC (from tx bbb...) ─┤─► Total: 0.5 BTC
Input 2: 0.2 BTC (from tx ccc...) ─┘
Output 0: 0.45 BTC (payment)
Output 1: 0.04 BTC (change)
Fee: 0.01 BTC
The Sequence Number
The 4-byte sequence number field in each input serves multiple purposes:
- RBF signaling: A sequence number below 0xFFFFFFFE signals that the transaction is replaceable (opt-in Replace-By-Fee)
- Relative timelocks: Encodes the minimum age of the referenced UTXO before it can be spent (BIP68)
- nLockTime enablement: A sequence number below 0xFFFFFFFF enables the transaction's nLockTime field
Common Misconceptions
- Inputs do not contain bitcoin. They are references to UTXOs that hold bitcoin. The input "unlocks" the UTXO by satisfying its spending conditions.
- A UTXO can only be spent once. Once referenced as an input in a confirmed transaction, that UTXO is consumed entirely. Any leftover value must be explicitly sent back as a change output.
- More inputs mean higher fees. Each input adds to the transaction's size, increasing the fee required. This is why UTXO management and consolidation matter.