How a Bitcoin transaction works, end to end

A transaction is a list of inputs and a list of outputs. Each input names a previously created output — by the hash of the transaction that created it and its position in that transaction's output list — and supplies the data needed to unlock it. Each output states an amount and a spending condition, which in the common case is a public key or a script hash that a future signature must match.

The arithmetic that a node enforces is simple and absolute: the sum of the input amounts must be greater than or equal to the sum of the output amounts. The difference between the two is the fee, and it is not written anywhere in the transaction. It is implied by the gap between what goes in and what comes out, and the miner who includes the transaction in a block claims it. A transaction whose outputs exceed its inputs is invalid and will be rejected by every node that sees it.

Change is where the design becomes visible to an ordinary user. If a wallet holds a single output of one bitcoin and the user wants to send a tenth of that, the wallet cannot split the output in place. It must spend the whole coin and create two new outputs: one of a tenth of a bitcoin to the recipient, and one of roughly nine tenths back to an address the wallet controls. The sender's balance falls by the amount sent plus the fee, and the rest returns as a fresh output. A wallet that manages this badly — by creating many small change outputs, for instance — leaves its owner with a fragmented set of coins that are more expensive to spend later.

To spend an output, the spender must satisfy its condition. In the most common output type the condition is a public key, and the spender satisfies it by producing a digital signature over a commitment to the transaction's contents. The signature is created with a private key and verified with the corresponding public key. Anyone can verify it; only the holder of the private key could have produced it.

The commitment matters as much as the signature. The signature covers the specific inputs and outputs being authorised, so it cannot be lifted from one transaction and reused in another. If any detail of the transaction changes after signing — an output amount, a recipient, even the order of the inputs — the signature no longer verifies and the transaction is invalid. This is why a wallet must re-sign after any modification, and it is the property that makes fee-bumping techniques such as replace-by-fee safe to reason about.

The signature scheme used by Bitcoin is ECDSA over the secp256k1 curve, with Schnorr signatures available for certain output types since the Taproot upgrade. Both are described in the Bitcoin protocol documentation rather than in a single BIP, and both provide the same core guarantee: a valid signature proves control of the private key without revealing it.

A signed transaction is not yet part of the blockchain. It is a proposal, and the wallet's next step is to hand it to the network. The wallet sends it to one or more peers, and those peers validate it against the consensus rules and the current state of the chain. If it passes, they relay it onward, and within seconds it has usually reached a large fraction of the network's nodes.

Nodes that have accepted a valid transaction hold it in a pool of pending transactions, the mempool. The mempool is not a queue with a fixed order. It is a local, per-node collection, and each miner chooses which transactions to include in the block it is trying to find. The usual selection rule is economic: miners prefer the transactions that pay the most fee per unit of block space, because block space is the scarce resource and the fee is what they earn for allocating it. A transaction that pays too little relative to the current demand may sit in mempools for hours, or be dropped altogether when nodes prune their pools under memory pressure.

When a miner finds a valid block, the transactions it contains become part of the chain and their inputs are marked spent. The outputs they created become the new UTXOs available to be spent in turn. That is the whole lifecycle: select outputs, construct the transaction, sign it, broadcast it, wait for a miner to include it, and wait for enough subsequent blocks to make reversal impractical. The transaction fees page takes the pricing of block space apart, and the confirmations and settlement page explains what the wait actually buys.