Glossary / Transactions & fees
Transaction input
Also known as Input, TxIn.
- Definition
- A transaction input is the half of a payment that names one specific coin you already own and proves you are allowed to spend it, consuming it completely.
Every input is a pointer plus a proof, and what it costs depends on the kind of coin being spent: about 57.5 virtual bytes for a Taproot coin, about 68 for a native SegWit one, and about 148 for a legacy one. Because inputs are always consumed whole, a wallet holding many small deposits pays more for the same payment than a wallet holding one large coin. Each deposit you receive is an input you will pay for later.
How it works
An input has four fields, and only one of them is the signature.
First comes the outpoint, 36 bytes: the id of the transaction that created the coin, followed by the position of the coin in that transaction's output list. This is the pointer, and it is what makes bitcoin auditable, because anyone can follow it backwards to the block where the value was created.
Second is a script length, and third the signature script, which for older coin types holds the signature and public key satisfying the previous output's lock. SegWit changed where that data lives, not what it contains: for a bc1 coin the script field is empty and the unlocking material moves into a separate witness section, where each byte counts as a quarter of a weight unit. Identical cryptography, a quarter of the billing.
Fourth is the sequence number, 4 bytes. It was originally intended for an in-mempool replacement scheme that never worked, then repurposed. BIP68 gave it meaning as a relative timelock, which is what lets a lightning channel say "spendable, but only after 144 blocks", and values below 0xfffffffe also signal that the transaction may be replaced by a higher-fee version.
The property that surprises people is consumption. Inputs are all or nothing. If you hold a single 0.4 BTC coin and want to pay 0.01 BTC, the input spends the entire 0.4, and the wallet creates a change output to give you the remainder back. There is no partial spend and no concept of deducting an amount.
One input is special. A coinbase transaction, the one that pays the miner, has exactly one input whose outpoint points at nothing: 32 zero bytes and an index of 0xffffffff. Its script carries arbitrary data instead of a signature, which is where the block height goes and where messages such as the one in the genesis block were written.
Where you see it
Inputs are the left-hand column on a block explorer, and the reason your wallet's fee estimate moves when you change nothing else.
In a coin control screen they are the checkboxes. Selecting one large coin instead of four small ones is the difference between one input and four, which at 68 virtual bytes each and a fee rate of 20 sat/vB is a saving of about 4,080 satoshis on a single payment.
They also leak information. Two inputs in one transaction tell every observer that one party controlled both coins, which is the assumption behind almost all blockchain clustering. Choosing which inputs to combine is therefore a privacy decision as well as a cost one.
The practical takeaway for anyone stacking regularly: batch buys into fewer withdrawals. Twelve monthly withdrawals leave twelve inputs waiting, and their bill arrives on the day you finally spend, at whatever rate the market charges then.
Transaction input vs transaction output
An input is a claim on the past and an output is an offer to the future, and the same chunk of value plays both roles in its lifetime. It is born as an output, sits in the unspent set, and dies as an input in the transaction that spends it. The asymmetry that matters is economic: outputs are cheap to create, at 31 to 43 bytes each, while inputs are expensive to spend, at 57.5 to 148 virtual bytes each. Receiving costs almost nothing and spending costs real money, which is exactly backwards from how most people expect a payment network to bill them.