TERM_DEF // TRANSACTION / INPUT
INPUT
Input. A reference to a previous output being spent, plus the data (scriptSig/witness) authorizing the spend.
This page sits in the Transaction section — How money moves: inputs, outputs, fees, signatures, sighash flags, and the formats that wrap them. Read on for what it is, why it exists, how it works under the hood, and what to watch out for.
This page sits in the Transaction section — How money moves: inputs, outputs, fees, signatures, sighash flags, and the formats that wrap them. Read on for what it is, why it exists, how it works under the hood, and what to watch out for.
WHAT_INPUT_IS
Input — at a glance
TRANSACTION
A transaction input consumes an existing UTXO. It points at the prior output by (txid + output index) and provides the unlocking data — a scriptSig or witness — that satisfies that output's scriptPubKey. Every input references exactly one previous output; every previous output can be referenced by exactly one input across the entire history of Bitcoin.
Why it exists
DESIGN
Inputs are how spending happens. By explicitly pointing at the UTXO being spent and supplying a cryptographic unlock, the protocol can verify ownership without a global registry. The (txid, vout) pointer is unique forever, so every spend is unambiguous; double-spending the same input twice is what the consensus rules specifically prevent.
HOW_IT_WORKS
Mechanism
HOW IT WORKS
Each input contains: a 32-byte previous txid (little-endian), a 4-byte vout index, a variable-length scriptSig (legacy) or an empty scriptSig with the unlock data placed in the witness field (SegWit), and a 4-byte sequence number. The sequence is used for relative timelocks (BIP-112) and RBF signalling (BIP-125).
1. Wallet selects an UTXO from the chain that it can spend (its keys match the output's lock).
2. Input is added to the new tx: prev_txid, vout, empty scriptSig (will be filled by signing), sequence = 0xffffffff (default).
3. After all inputs/outputs are placed, the wallet computes the sighash for this input.
4. The sighash is signed with the relevant private key → the signature is placed in scriptSig (legacy) or witness (SegWit).
5. Sequence can be lowered to enable RBF (any value < 0xfffffffe).
6. The signed input is verifiable by anyone: re-run the scriptSig + scriptPubKey on the stack machine, confirm the final stack is truthy.
WORKED_EXAMPLE
A SegWit input in full detail
EXAMPLE
prev_txid : 7b1eabe0209b1fe794124575ef807057c3f9895dd3e9d775e7d62cf5d2f50e
(32 bytes, little-endian on the wire)
vout : 00000000 (index 0 of that tx)
scriptSig_len: 00 (empty — SegWit puts data in witness)
sequence : feffffff (0xfffffffe enables relative locktime, opts out of RBF)
Witness stack (separate from scriptSig):
push <72-byte signature>
push <33-byte compressed pubkey>
To spend, network verifies:
1. Outpoint (txid + vout) refers to an unspent output in the UTXO set.
2. Witness program: scriptPubKey was OP_0 , and HASH160(pubkey) == hash.
3. Signature is valid for the sighash of this tx.
4. Sequence rules are satisfied for any relative timelocks.
Any failure → reject the entire transaction.
KEY_PROPERTIES
UNIQUE POINTER
Every input references a specific UTXO via (txid, vout). A given UTXO can be referenced at most once across all history.
INSEPARABLE FROM SIGNING
The signature commits to the specific input + output configuration — change anything material and the signature becomes invalid.
SEQUENCE FIELD
4 bytes with multiple purposes: relative timelocks (BIP-112), RBF signalling (BIP-125), and historical "soft" replacement.
PARALLEL VERIFIABLE
Each input's signature can be checked in parallel — modern Bitcoin Core uses multi-threaded sig verification for block processing.
COMMON_PITFALLS
Things that catch people out
PITFALLS
- An input that references a non-existent or already-spent UTXO is automatically invalid. This is the double-spend prevention rule.
- Forgetting to mark inputs as RBF (sequence < 0xfffffffe) means you cannot bump the fee if the tx gets stuck.
- For SegWit inputs the scriptSig is empty — the unlock data lives in the witness field. Mixing the two breaks the tx.
- Coinbase transactions are special: they have one input whose prev_txid is all-zeros and whose scriptSig contains the block height + arbitrary data, not a real outpoint.
RELATED_CONCEPTS
Other terms from Transaction — click any to read its page:
TERMINOLOGY_INDEX
TERMINOLOGY
Input
A reference to a previous output being spent, plus the data (scriptSig/witness) authorizing the spend.
Transaction (Tx)
A signed payload spending one or more UTXOs and creating new ones; every state change in Bitcoin is a tx.
Raw Transaction
The hex-serialized bytes of a transaction, ready to broadcast or analyze.
Transaction ID (TXID)
HASH256 of a transaction's pre-witness serialization; used to reference outputs by (txid, vout).
wTXID (Witness TXID)
HASH256 of the full transaction including witness data; commits to signatures and used in the witness commitment.
Output
An (amount, scriptPubKey) pair created by a transaction; spendable later by a tx whose input references it.
UTXO (Unspent Transaction Output)
An output that hasn't been spent yet; your "balance" is the sum of UTXOs you can sign for.
UTXO Set
The complete set of currently-spendable outputs maintained by every node/">full node — Bitcoin's state.