Blocks and transactions: what's inside
Open up a block and see what's actually stored, and why Bitcoin and Ethereum keep track of money differently.
A block is a bundle of transactions plus a small header. The header holds the previous block's hash, a timestamp and a Merkle root, one hash that summarizes every transaction in the block. Bitcoin tracks money as unspent outputs (UTXOs), like individual banknotes; Ethereum tracks balances in accounts, like a bank ledger.
The block header
Bitcoin's block header is just 80 bytes, whatever the block holds. It has six fields:
| Field | Size | What it's for |
|---|---|---|
| Version | 4 bytes | Which rules the block follows; also used to signal support for upgrades |
| Previous block hash | 32 bytes | The link that makes it a chain |
| Merkle root | 32 bytes | One hash summarizing every transaction |
| Time | 4 bytes | When the miner says it made the block (must be later than the median of the previous 11 blocks and no more than two hours ahead of network time) |
| Target (nBits) | 4 bytes | How low the block's hash must be: the difficulty |
| Nonce | 4 bytes | The number miners change while searching for a valid hash |
The block's own ID is the double SHA-256 hash of these 80 bytes. Ethereum blocks have a larger header with fields Bitcoin doesn't need: a state root (a fingerprint of every account balance and contract after the block), a receipts root, the gas used and gas limit, and the current base fee.
Merkle trees: summarizing thousands of transactions in one hash
A Merkle tree hashes each transaction, then hashes the results in pairs, then pairs of those, until one hash is left: the Merkle root. Bitcoin uses double SHA-256 at every step and, if a level has an odd number of hashes, pairs the last one with itself.
Two things follow. Change any transaction and the root changes, so the 80-byte header commits to the whole block. And you can prove one transaction is inside a block by showing only the hashes along its path: for a block of 4,000 transactions that's about 12 hashes, not 4,000 transactions. Light wallets rely on this (see types of nodes).
Bitcoin's UTXO model: digital banknotes
Bitcoin has no balances. It has unspent transaction outputs (UTXOs): chunks of bitcoin, each locked to a key. Your wallet's "balance" is the total of the UTXOs it can unlock.
Example. Ana's wallet holds two UTXOs: 0.30 BTC and 0.50 BTC. She pays Ben 0.60 BTC. Her wallet spends both UTXOs (0.80 BTC in) and creates two new outputs: 0.60 BTC locked to Ben and 0.1999 BTC back to a new address of Ana's ("change"). The missing 0.0001 BTC is the fee; there's no fee field, it's simply inputs minus outputs. A wallet that forgets the change output gives the whole difference to the miner.
Ethereum's account model: a ledger of balances
Ethereum keeps a balance and a counter (the nonce) for every account. A payment simply subtracts from one balance and adds to another. The nonce goes up by one with each transaction, so the same signed transaction can't be replayed, and transactions from one account run in order. Smart contracts are accounts too, with code and storage.
| Compare | UTXO (Bitcoin, Litecoin, Cardano) | Account (Ethereum, most smart-contract chains) |
|---|---|---|
| What's stored | Individual unspent coins | A balance per address |
| Fee | Inputs minus outputs | Gas used × gas price |
| Privacy | Easier to use a fresh address each time | One address tends to collect all history |
| Parallel checking | Independent coins can be checked in parallel | Shared state makes ordering matter more |
| Complex apps | Harder; scripts are deliberately limited | Easier; contracts can hold and update state |
What a transaction contains
- Bitcoin: a list of inputs (which UTXOs are spent, with signatures that unlock them) and outputs (amounts and the conditions to spend them later). Since SegWit, signatures sit in a separate "witness" section.
- Ethereum: the sender's nonce, the recipient, the value in wei, data (for contract calls), a gas limit, fee settings, and a signature. Newer transaction types add blob data for rollups (type 3) and account delegation (type 4, see account abstraction).
Limitations and trade-offs
- Limited room. Bitcoin blocks are capped by "weight" (4 million weight units); Ethereum blocks by a gas limit. When demand exceeds the room, fees rise.
- Everything is public. Amounts and addresses in normal Bitcoin and Ethereum transactions can be read by anyone (see is crypto anonymous?).
- Mistakes are permanent. A wrong amount or a missing change output can't be reversed once confirmed.
- Growing history. Every full node stores and checks it all, which is why chains limit block size (see the scalability trilemma).
Frequently asked questions
How many transactions fit in a Bitcoin block?
It depends on their size. Typical blocks hold a few thousand transactions. The limit is 4 million weight units, which works out to roughly 1 to 2 MB of data for typical transactions.
What is a Merkle proof?
The short list of hashes needed to show that one transaction is included under a given Merkle root, without downloading the whole block.
Why does my Bitcoin wallet show a payment to an address I don't recognize?
Often it's your own change output going back to a new address in your wallet. Check whether the address belongs to your wallet before worrying.
What is a nonce?
Two different things. In a Bitcoin block header it's the number miners change while mining. In an Ethereum account it's a counter of how many transactions the account has sent.
Is a UTXO the same as a coin?
Roughly. A UTXO is an amount of bitcoin that hasn't been spent yet, locked to a key. Spending it destroys it and creates new UTXOs.
Where to next
Sources
- Block chain, Bitcoin developer guide
- Transactions, Bitcoin developer guide
- Block headers, Bitcoin developer reference
- Blocks (ethereum.org)
- Transactions (ethereum.org)
- Bitcoin white paper, sections 7–8
Written for beginners and checked against the sources listed. Last reviewed November 4, 2026. This page is educational and is not financial, tax or legal advice. How we write and check pages.