How the Bitcoin blockchain works

If you have already read what Bitcoin is, you know that the network records payments without a central intermediary. This article looks under the hood: it shows how a transaction is created, how it gets into a block and why, after a few hours, undoing it becomes impractical.

The main technical reference is Satoshi Nakamoto’s original paper (Bitcoin: A Peer-to-Peer Electronic Cash System) and the developer documentation maintained by the project. Some details have changed since the original paper, and they are pointed out along the way.

What the blockchain is, in one sentence

The Bitcoin blockchain is an ordered list of blocks of transactions, in which each block points to the previous one by means of a cryptographic fingerprint. Every full participant in the network keeps a copy and checks each block before accepting it.

To understand why this works, you have to start with the smallest piece: the transaction.

Transactions and UTXOs

Bitcoin does not record accounts with balances. It records transaction outputs. Each output states an amount, in satoshis, and a condition for spending it, usually “whoever proves control of this key”.

An output that has not yet been used is called a UTXO, short for unspent transaction output. The developer guide explains that each output waits, as a UTXO, until a later input spends it (Developer Guide: Transactions). An output can only be spent once.

A transaction’s input points to an earlier UTXO, by the transaction identifier and the output’s position, and carries the signature that satisfies the condition. The balance your wallet shows is the sum of the UTXOs your keys can spend.

An example helps. Imagine you have a single UTXO of 0.5 BTC and want to pay 0.2 BTC:

• The transaction uses the entire 0.5 BTC UTXO as input.
• It creates an output of 0.2 BTC for the recipient.
• It creates another output, of slightly less than 0.3 BTC, back to an address of yours. This is the change.
• The difference between what goes in and what comes out goes to the miner as a fee.

The original paper describes exactly this arrangement: inputs that combine or split amounts and, normally, at most two outputs, one for the payment and one for the change (Nakamoto, section 9). The fee is what is left when the sum of the outputs is less than that of the inputs (section 6). If you forget to create the change output, the entire remaining amount becomes a fee. Wallets do this math for you, but the mechanism explains why mistakes at this point are permanent.

Signatures: proving without revealing

To spend a UTXO, the payer reveals the public key and a digital signature made with the corresponding private key. The developer guide states that Bitcoin uses ECDSA signatures over the secp256k1 elliptic curve (Developer Guide: Transactions).

The signature proves that the payer controls the private key without showing the key. It also covers the transaction data. If someone changes the amount or the destination along the way, the signature is no longer valid and nodes reject the transaction.

Hashes: the fingerprint of data

A hash is the output of a function that turns any data into a fixed-size number. In Bitcoin, the function is SHA-256, applied twice in a row to block headers (Developer Reference: Block Chain).

Three properties matter here:

• The same data always produces the same hash.
• A tiny change in the data produces a completely different hash.
• There is no practical way to find data that produces a hash chosen in advance, other than by trial.

The first and second make it possible to detect any alteration. The third is the basis of proof of work.

Inside a block

A block has two parts: the list of transactions and an 80-byte header. According to the technical reference, the header has six fields (Developer Reference: Block Chain):

• version, which indicates the validation rules followed;
• hash of the previous block’s header;
• Merkle root, a summary of all the transactions in the block;
• time, when the miner started hashing the header;
• nBits, the compact form of the difficulty target;
• nonce, a number the miner changes in search of a valid hash.

The Merkle root comes from a tree of hashes. The transaction hashes are grouped in pairs and combined repeatedly until only one is left (Developer Guide: Block Chain). If a single transaction changes, the root changes, and so does the header.

The first transaction in every block is special. Called the coinbase, it creates the new coins of the reward and collects the fees from the other transactions. Its outputs can only be spent after at least 100 blocks.

How blocks form a chain

Because each header stores the hash of the previous one, the blocks are chained together. The developer guide sums up the consequence: a transaction cannot be modified without modifying the block that contains it and all the blocks that follow (Developer Guide: Block Chain).

The path of an alteration would be this: changing a transaction changes the Merkle root, which changes the block’s hash, which no longer matches what the next block stored. To hide the change, every later block would have to be redone. That is where the cost comes in.

Proof of work and difficulty adjustment

A block is only valid if its header’s hash is equal to or lower than a target set by the difficulty. Since the hash cannot be predicted, the miner changes the nonce and other data and recalculates, billions of times, until it gets it right. Checking the result, on the other hand, takes a single calculation.

The original paper sums up the effect: once the effort has been expended, the block cannot be changed without redoing the work, and the same goes for all the blocks that came after it (Nakamoto, section 4).

Difficulty is not fixed. Every 2,016 blocks, nodes recalculate the target based on how long those blocks took. The ideal value is 1,209,600 seconds, or two weeks (Developer Guide: Block Chain), which corresponds to the target of one block every ten minutes defined in the Bitcoin Core code (chainparams.cpp). If blocks come too fast, difficulty rises; if they come too slowly, it falls. The adjustment at each recalculation is capped.

Mining itself, with its energy consumption and economics, has its own article in this section.

Nodes: who checks the rules

A full node is, in the words of the project’s website, a program that fully validates transactions and blocks (Bitcoin.org, Running A Full Node). Most also relay the data they receive to other nodes.

The life cycle of a transaction on the network is as follows:

1. Your wallet signs the transaction and sends it to one or more nodes.
2. Each node checks the transaction and, if it is valid, relays it to its peers.
3. Until it is included in a block, it sits in the mempool, the memory area where nodes keep unconfirmed transactions (Developer Guide: P2P Network).
4. Miners pick transactions from the mempool, generally prioritizing those that pay higher fees, and try to complete a block.
5. When someone finds the proof of work, the block is broadcast. Nodes only accept it if all transactions are valid and not already spent (Nakamoto, section 5).

A new node needs to download and validate every block from the beginning before checking recent transactions. The project’s page, consulted in October 2026, mentions about 740 GB for the full chain. With the pruning option, which discards old blocks after validating them, disk usage drops to about 7 GB (Bitcoin.org, Running A Full Node).

There are also lightweight wallets that do not validate everything. They store only the headers and ask full nodes for proof that a transaction is in a block. The original paper calls this simplified payment verification and warns that it is more vulnerable if an attacker overpowers the network (Nakamoto, section 8).

Forks and the valid chain

Sometimes two miners find different blocks at almost the same time. The network is split for a few moments: some nodes see one block first, others see the other. This is a temporary fork.

The original paper says nodes consider the longest chain to be the correct one (Nakamoto, section 5). Current documentation is more precise: nodes follow the chain with the most accumulated difficulty, that is, the most work (Developer Guide: Block Chain). When the next block appears on top of one of the branches, the tie is broken. The block on the other branch is abandoned, and its transactions return to the mempool to be included in a future block.

Confirmations: when a payment is safe

A transaction included in the most recent block has one confirmation. Each block built on top adds another.

The developer guide explains why this matters (Developer Guide: Payment Processing):

• Zero confirmations: the transaction has been broadcast but is not in any block. It should not be treated as received without a risk analysis.
• One confirmation: the risk drops considerably, but the most recent block is sometimes replaced by accident, as in the fork described above.
• Six confirmations: this is the recommended threshold for high-value payments or payments exposed to fraud.

The original paper calculates the probability of an attacker with less computing power than the honest miners rewriting history to undo a payment. That probability drops exponentially with each block the attacker needs to catch up on (Nakamoto, section 11). Security therefore depends on one premise: most of the mining power must not be coordinated to attack the network.

The same section points out an important limit. Even an attacker with more power cannot create coins out of thin air or spend other people’s funds, because nodes would reject blocks with invalid transactions. What the attacker can try is to undo a payment they made themselves.

Block size

Blocks cannot grow at will. Since the upgrade known as SegWit, the limit is measured in “weight”, and the rule sets a maximum weight of 4,000,000 per block (BIP 141). The same proposal removed signatures from the calculation of the transaction identifier, which fixed a technical problem called malleability.

The limit is one of the reasons fees rise during periods of high demand: space in each block is contested. Solutions that process payments off the main chain are the subject of the article on layers 1 and 2.

What the blockchain does not guarantee

Understanding the mechanism also helps you see its limits:

• It does not know who you are. Addresses are public and have no names. That is not anonymity: all activity remains visible forever.
• It does not fix mistakes. A valid transaction sent to the wrong address is recorded and confirmed like any other. There are no chargebacks.
• It does not protect your keys. The chain can be perfectly secure while your wallet is stolen through a scam or an infected device.
• It says nothing about price. The technical workings are independent of the price, which can swing sharply.

Key takeaways

• Bitcoin records unspent outputs (UTXOs), not balances. Each payment consumes old UTXOs and creates new ones, with change and a fee.
• Hashes chain the blocks together and summarize the transactions. Changing the past means redoing the proof of work for every subsequent block, and difficulty adjusts every 2,016 blocks to keep the average at ten minutes.
• Independent nodes check every rule and follow the chain with the most work. Each new confirmation reduces the chance of reversal; six is the usual threshold for large amounts.

For the big picture, including wallets, fixed supply and risks, go back to the guide What Bitcoin is and how it works.