On October 7, 2026, a miner published block 970,400. It held 6,074 transactions and weighed 3,993,559 weight units, which is 99.8 percent of the maximum the rules allow. Every node on the network checked it, filed it, and moved on to the next one.
Nobody had to trust whoever mined it. Every claim inside that block, from who paid whom to how much new bitcoin was created, could be verified by anyone with a copy of the software.
That works because a block is not a loose bag of data. It is a tightly specified structure where each part has a job. Open one up and the design of the whole system comes into focus.
The 80 Bytes That Get All the Attention
Every block starts with a header that is exactly 80 bytes long, shorter than a single text message. It is the only part miners hash during proof of work, and the main thing a lightweight wallet downloads to follow the chain.
| Field | Size | What it does |
|---|---|---|
| Version | 4 bytes | Signals which rules the block follows; some bits are used for upgrade signaling |
| Previous block hash | 32 bytes | The hash of the block before it, which is what chains blocks together |
| Merkle root | 32 bytes | A single fingerprint of every transaction in the block |
| Timestamp | 4 bytes | When the miner says it built the block, in Unix time |
| nBits | 4 bytes | The current target, in compact form |
| Nonce | 4 bytes | The number miners change while searching for a valid hash |
Two of these fields carry most of the security. The previous block hash means altering any old block changes its hash, which breaks the link from every block after it. The merkle root means altering any transaction changes the root, which changes the header, which invalidates the proof of work.
The timestamp is looser than you might expect. Nodes only require it to be later than the median of the previous 11 blocks and no more than two hours ahead of their own clock. That slack is fine because the timestamp is used mostly for the difficulty adjustment, which averages over two weeks.
The Merkle Root: Thousands of Transactions, One Fingerprint
A block with 6,074 transactions cannot fit them all in an 80-byte header. Instead, the miner builds a merkle tree. Each transaction ID is hashed in pairs with its neighbor, those results are hashed in pairs again, and so on, until a single 32-byte hash remains at the top. If a level has an odd number of entries, the last one is paired with itself.
Analogy: Think of a shipping container sealed with a tamper-evident tag. The tag does not list every item inside, but the tag number is derived from the full manifest. Swap out a single box and the number no longer matches. Customs only needs to check the tag to know the cargo is untouched.
The tree has a second benefit, described in section 8 of the whitepaper. To prove one transaction is in a block, you only need the hashes along its branch, not the whole block. For a block of about 6,000 transactions, that is roughly 13 hashes. This is how lightweight wallets confirm payments without downloading everything.
The Coinbase: The Transaction With No Sender
The first transaction in every block is special. It is called the coinbase transaction, and it has no real input. It creates new bitcoin from nothing, under strict limits:
- It pays the miner. The output can claim the block subsidy plus all fees in the block, and not one satoshi more. Since block 840,000 the subsidy is 3.125 BTC, per the halving schedule.
- It records the block height. Since BIP34 activated in 2013, the first item in the coinbase's input script must be the block's height, which keeps every coinbase transaction unique.
- It carries a free-form field. The input script can hold 2 to 100 bytes. Miners use it for extra nonce space and pool tags. The genesis block used it for a newspaper headline: "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks."
- It commits to witness data. When a block contains segwit transactions, BIP141 requires an extra coinbase output holding a commitment to all signature data, starting with the bytes
aa21a9ed. - It is locked for 100 blocks. Coins created by a coinbase cannot be spent until 100 more blocks are built on top, in case the block is orphaned.
Weight, Not Size: The 4 Million Rule
For years, the limit was simple: a block could be at most 1 MB. The Segregated Witness upgrade, which activated at block 481,824 in August 2017, replaced that with block weight.
The formula in BIP141 is base size times 3, plus total size, and it must not exceed 4,000,000. Base size is the block without signature (witness) data; total size includes it. In practice, non-witness bytes count 4 weight units each and witness bytes count 1. A block with no segwit transactions still tops out at 1 MB, but blocks heavy with witness data can be larger in raw bytes.
Block 970,400 shows the effect. It was 1,599,130 bytes on disk, well over the old 1 MB limit, while staying just under 4 million weight units. This is also why fees are quoted per virtual byte (weight divided by 4) rather than per raw byte. How transactions compete for that space is covered in The Mempool.
The Transactions Themselves
After the coinbase come the ordinary transactions. Each one spends outputs from earlier transactions and creates new outputs, a model explained in How Transactions Work. The order matters: a transaction can spend an output created earlier in the same block, but never one that appears later.
Nodes check every one. Signatures must be valid, inputs must exist and be unspent, and outputs cannot exceed inputs. A single bad transaction makes the entire block invalid, no matter how much work went into its header.
What This Means for You
- Your payment is sealed by the merkle root. Once your transaction is in a block, changing it would mean redoing that block's proof of work and every block since.
- Block space is the scarce resource. With a hard ceiling of 4 million weight units about every 10 minutes, fees are an auction for room, and fee rates are counted in satoshis per virtual byte. The BTC to sats converter helps make sense of them.
- You can inspect any block yourself. Every field described here is public. Open a block explorer, pick a height, and read its header, coinbase and transactions.
- Segwit transactions are cheaper by design. Witness bytes weigh a quarter of other bytes, so wallets that use segwit addresses typically pay less for the same payment.
Eighty bytes of header, one special transaction, a weight limit. Everything else in Bitcoin is built on that container.