Transaction Input

Overview

Bitcoin-style inputs contain a reference to a previous transaction output, an output index, unlocking data or witness, and sequence information. The transaction is valid only if the referenced output exists, remains unspent, and the spending condition is satisfied.

Input selection affects privacy and fees. Combining several UTXOs makes transactions larger and can link addresses through common-ownership heuristics. Wallets choose inputs based on amount, fee rate, confirmation, and coin-selection policy.

Smart-contract platforms use different models. A transaction can include calldata, an account nonce, value, signatures, and a list of accounts or objects that execution may access. These are not UTXO inputs, but they serve as execution inputs.

Applications should validate all referenced values before signing. An attacker-controlled transaction builder can choose unexpected inputs, permissions, or contract arguments. Hardware wallets should display the economic effect rather than only raw serialized data.

Inputs can become invalid before inclusion. A referenced UTXO may be spent by another transaction, or account state may change. Simulation and mempool acceptance do not guarantee final execution.

Transaction inputs define the resources being consumed and the instructions being authorized. Their exact structure is protocol-specific and central to fee, privacy, and validity analysis.

Input verification should include ownership and policy. A wallet can technically spend a UTXO that the user intended to preserve for privacy or accounting, or select funds associated with a different customer. Institutional systems often label inputs and apply coin-control rules. In smart-contract transactions, the equivalent review includes account permissions and calldata. Safe construction verifies not only spendability but also whether the chosen resources are appropriate.