On Friday 23 October 2026 at 08:41:36 UTC, a miner added block 972,742 to the Bitcoin blockchain. It held 6,179 transactions and took up 1,602,946 bytes, according to the public explorer mempool.space, which credits it to the AntPool mining pool. Yet the part every node on the network checked first, and the only part miners hash over and over while they hunt for a valid block, is 80 bytes long. It is called the block header.
What is a block in blockchain, then? Put simply, a header plus a list of transactions. The header is a short label made of six fields, always 80 bytes in Bitcoin. The list, called the body, can hold one transaction or several thousand, and it always starts with a special one that creates new coins. The label commits to the whole list through a single 32-byte fingerprint, the Merkle root, so that changing one byte of one transaction would change the label too.
Our lesson on how a blockchain works covered the chain itself: how hashes link blocks to one another and why thousands of computers keep a copy of the same ledger. This one stays inside a single block, block 972,742, opened field by field, with an Ethereum block from the same morning for comparison. Every figure below was read on 23 October 2026.
A block in blockchain is an 80-byte header and a list of transactions
Think of a parcel with a shipping label. The box can be small or heavy; the label always has the same boxes to fill in. In Bitcoin the label has six of them, and their sizes never change, which is why every Bitcoin header since 2009 measures exactly 80 bytes.
| Field | Size | What it records |
|---|---|---|
| Version | 4 bytes | which set of validation rules the block follows |
| Previous block hash | 32 bytes | the fingerprint of the block just before it |
| Merkle root | 32 bytes | one fingerprint summarising every transaction in the body |
| Time | 4 bytes | a timestamp in seconds, set by the miner within limits |
| Bits | 4 bytes | the target the block hash must stay below, in compact form |
| Nonce | 4 bytes | a number the miner changes until the hash meets the target |
Add them up: 4 + 32 + 32 + 4 + 4 + 4 = 80. The Bitcoin developer reference lists the same six fields in the same order, and that order matters, because the block’s identity, its hash, is computed over these 80 bytes and nothing else.
The body sits after the header. It begins with a counter saying how many transactions follow, then the transactions themselves, one after the other. Block 0, the very first block, created on 3 January 2009, carried a single transaction and weighed 285 bytes in total; its full story is told in our lesson on the genesis block and the 2008 crisis. Block 972,742 carried 6,179 transactions. Both have an 80-byte header.
The header does not contain the transactions. It contains a fingerprint of them. A node that holds only the header can later check any transaction someone shows it against that fingerprint, without having to trust whoever sent it.
Block 972,742 read field by field
An explorer shows each block twice: as a friendly page of numbers and, if you ask for it, as raw bytes. The raw header of block 972,742, returned by the mempool.space interface on 23 October 2026, is a string of 160 hexadecimal characters (two characters per byte). Cut into its six fields, it reads as follows.
| Field | Raw bytes (hex, as stored) | Read as |
|---|---|---|
| Version | 00a00320 | 0x2003a000, or 537,108,480 |
| Previous block hash | 9da364f8 … 310c0000 00000000 00000000 | 0000…0c31167384b4…f864a39d (block 972,741) |
| Merkle root | fae40539 … 84070b67 | 670b0784f7d7…3905e4fa |
| Time | c01ddb6a | 1,792,744,896, i.e. 23 October 2026, 08:41:36 UTC |
| Bits | 93000217 | 0x17020093 |
| Nonce | 2e06d2b1 | 2,983,331,374 |
One detail trips up nearly everyone who compares the raw bytes with the explorer page: the order of the bytes is reversed. Numbers are stored little-endian, smallest byte first, so the four version bytes 00 a0 03 20 read 0x2003a000 once flipped. Hashes are kept in what the developer reference calls “internal byte order”, and explorers print them backwards. Reverse the raw Merkle root fae40539… byte by byte and you get the 670b0784… shown on the block page.
The check that ties it all together takes a few lines of code. Run SHA-256 twice over these 80 bytes, reverse the result, and you get 00000000000000000000a1bf4e832b290e803eb681fd3fd0d48a845e141cc803, the hash the explorer gives for block 972,742. We ran it on 23 October 2026 and the two matched. Every node on the network does the same before accepting the block.
Version: which rules the block follows
The first four bytes tell nodes which set of validation rules the block claims to follow. The value 0x2003a000 starts with the bit pattern 001, the convention introduced by the BIP9 proposal, under which the remaining bits can be switched on by miners to signal that they are ready for a soft fork, a backward-compatible rule change. Which upgrade, if any, those particular bits refer to in October 2026 is not something the header says by itself, and this lesson does not try to decode it.
Previous block hash: the link to block 972,741
The next 32 bytes are the hash of the header of block 972,741, mined at 08:37:13 UTC the same morning with 3,427 transactions, 4 minutes and 23 seconds before ours. This field is the “chain” in blockchain. Because each header includes the hash of the one before, altering an old block would change its hash, break the link stored in the next header, and so on up to today. The lesson on how a blockchain works follows that chain reaction in detail; a later lesson in this path explains why it makes the record so hard to rewrite.
Note the long run of zeros at the start of both hashes. Block 972,742’s own hash begins with 20 zero hexadecimal digits, that is 80 zero bits. That is no coincidence: it is what the next two fields are about.
Merkle root: one fingerprint for 6,179 transactions
The third field, 670b0784…3905e4fa once displayed, is the Merkle root. It is computed from the identifiers of all 6,179 transactions, in their exact order, folded together pair by pair until a single 32-byte value is left. We recomputed it on 23 October 2026 from the list of transaction identifiers published by mempool.space and obtained the same value as the header. How the folding works, and why it is useful, is explained in its own section below.
Time: a Unix timestamp with loose rules
The timestamp is a count of seconds since 1 January 1970 at midnight UTC, the usual way computers store time. For block 972,742 it is 1,792,744,896, which converts to Friday 23 October 2026 at 08:41:36 UTC.
Nobody expects a precise clock reading here, and the network does not require one. The developer reference says it must be strictly greater than the median time of the previous 11 blocks, which for our block was 1,792,742,614 (08:03:34 UTC). The Bitcoin Wiki adds an upper bound: less than the network-adjusted time plus two hours. Between those two limits miners are free to move it, and they do, updating it every few seconds while they search for a valid hash. Since the rule looks at the median and not at the block just before, a block may even carry an earlier time than its predecessor.
Bits: the target, written in compact form
Course outlines often call this field the difficulty target, a slightly misleading name. The header does not store the difficulty number. It stores “bits”, an encoding of the target that the block hash must be less than or equal to. The developer reference describes the format as a base-256 version of scientific notation: the first byte is an exponent, the other three a significand.
For block 972,742 the bits read 0x17020093. The exponent 0x17 is 23, the significand 0x020093, so the target is 0x020093 multiplied by 256 to the power of 20. Written out, that is a 256-bit number whose first 78 bits are zeros. The block hash, read as a number, is below it; we checked. Any hash above it would have been rejected by every node.
Difficulty is derived from this target: it says how many times harder the current target is to hit than the easiest one the protocol allows, the target of block 0, set at difficulty 1. For block 972,742 mempool.space gives a difficulty of 140,577,680,051,919.62, about 140.6 trillion. It was set at block 971,712 on 16 October 2026 at 12:37 UTC, a rise of 5.92%. Bitcoin recalculates it every 2,016 blocks, two weeks at the intended pace of one block every ten minutes, according to the Bitcoin Wiki. The next recalculation falls at block 973,728, 986 blocks after ours. For the mining contest itself, see our glossary entry on proof of work.
Nonce: the number miners keep changing
In cryptography a nonce is a “number used once”. In a Bitcoin header it is the last four bytes, and its only job is to be changed. A miner fills in the other five fields, sets the nonce to some value, hashes the 80 bytes twice with SHA-256 and compares the result with the target. Too high? Change the nonce and hash again. The winning nonce of block 972,742 was 2,983,331,374. It has no meaning of its own; it simply happened to produce a hash below the target, with the other fields as they were.
Four bytes allow 232 values, 4,294,967,296 in all. At a difficulty above 140 trillion that is far too few: most of the time every one of them fails. The Bitcoin Wiki’s page on the block hashing algorithm explains what happens then. When the nonce runs out, the miner changes a field called the extraNonce inside the first transaction of the body. That transaction changes, so its identifier changes, so the Merkle root changes, and the miner gets a fresh header with 4.3 billion new nonces to try. Updating the timestamp has a similar effect.
The word has a second meaning on Ethereum, where each account has a nonce that counts the transactions it has sent. That counter has nothing to do with mining; the Bitcoin header nonce is the one this lesson describes.
The body: 6,179 transactions, and the first one creates coins
Right after the header comes the list. The developer reference sets one firm rule for its order: “The first transaction in a block must be a coinbase transaction.” The coinbase is the transaction through which the miner pays itself. It spends no earlier coins. Its single input is a placeholder, and its outputs send the block reward to addresses the miner chose.
In block 972,742 the coinbase (identifier 97a170a9…33386cb5) paid out 313,361,901 satoshis, or 3.13361901 BTC, a satoshi being one hundred-millionth of a bitcoin. That sum has two parts, and the arithmetic checks out exactly:
- the block subsidy, 3.125 BTC (312,500,000 satoshis), new bitcoins that did not exist before this block;
- the fees paid by the other 6,178 transactions, 861,901 satoshis in total, or 0.00861901 BTC.
A coinbase that tried to pay out more than subsidy plus fees would make the whole block invalid. The subsidy has been 3.125 BTC since block 840,000, mined on 20 April 2024, and it halves every 210,000 blocks, according to the Bitcoin Wiki’s supply table. At block 1,050,000, about 77,000 blocks after ours, it drops to 1.5625 BTC; at ten minutes a block that is roughly a year and a half away. Our glossary entry on the bitcoin halving covers the schedule and its history. We give no dollar value for the reward here: it would only mean something with the price of a precise minute.
The coinbase has a second use. Its input carries a free-form field, and miners write in it. Decoded, the coinbase of block 972,742 contains the readable text “Mined by AntPool”. That text is inside the block, while the pool name displayed by mempool.space is the explorer’s own label. Neither proves who ran the machines, but the two agree. The same coinbase also carries outputs worth zero that store data, one of them a commitment to the SegWit witness data of the block, covered in the section on size.
The 6,178 other transactions are ordinary payments and transfers. Together they spent 8,155 inputs (earlier outputs being consumed) and created 12,724 new outputs, with an average size of about 259 bytes per transaction. How a transaction is built, signed and priced, and why it may wait before being picked, is the subject of our guide to how crypto transactions work. What matters here is that the miner chose which transactions to include and in which order, and that this order is locked into the Merkle root.
The Merkle tree: how 6,179 fingerprints fold into one
Every transaction has an identifier, its txid: the double SHA-256 hash of the transaction, 32 bytes. A block could have stored all of them in the header, but 6,179 txids weigh close to 200 KB. The Merkle tree, named after the cryptographer Ralph Merkle, whose 1980 paper the Bitcoin white paper cites, squeezes them into one hash.
Take a small block with eight transactions, A to H. Draw the tree upside down, with its root at the top. On the bottom row sit the eight txids. Pair them up from the left: A with B, C with D, E with F, G with H. For each pair, join the two hashes end to end and hash the result twice: that gives four new hashes, AB, CD, EF and GH, on the row above. Do it again and you get two, ABCD and EFGH. Once more and a single hash remains at the top. That top hash is the Merkle root written in the header. Eight leaves, three rounds of pairing.
What if a row has an odd number of hashes? The rule in the developer reference is simple: “the last TXID is concatenated with a copy of itself and hashed.” With five transactions, A to E, the bottom row pairs A-B and C-D, then pairs E with a copy of E. The row above has three hashes, so the third is again paired with itself, and so on until one remains.
Block 972,742 needed 13 rounds. The rows shrink like this: 6,179 txids, then 3,090, 1,545, 773, 387, 194, 97, 49, 25, 13, 7, 4, 2 and finally 1. Nine of those rows had an odd count and duplicated their last hash. We redid the 13 rounds from the published list and landed on 670b0784…3905e4fa, the value in the header.
Two properties come out of this design. First, any change at the bottom climbs to the top: alter one byte of one transaction and its txid changes, then its pair’s hash, then every hash above it, up to the root. The header would no longer match the body, and nodes would reject the block. Second, proving that one transaction is in the block takes very little data. To show that C belongs to the eight-transaction block, you only need D, AB and EFGH: with C you rebuild CD, then ABCD, then the root, and compare it with the header. One hash per round.
For block 972,742 such a proof, called a Merkle branch, is 13 hashes of 32 bytes, 416 bytes, plus the 80-byte header: less than 500 bytes to confirm one transaction out of a block of 1.6 MB. The Bitcoin white paper builds on exactly this in section 8, “Simplified Payment Verification”: a light wallet keeps only block headers and asks the network for the Merkle branch of the payments that concern it.
How big is a Bitcoin block? From 1 MB to 4 million weight units
Ask how big a Bitcoin block can be and you will often read “1 MB”. That was the rule for years, and the developer reference still quotes it: “a block is not valid unless its serialized size is less than or equal to 1 MB.” Block 972,742, at 1,602,946 bytes, would have broken it. It did not break anything, because the rule changed in 2017.
The change is Segregated Witness, or SegWit, defined in BIP141 and active since block 481,824, mined on 24 August 2017. SegWit moved the signatures and related data of a transaction, the “witness”, into a separate part of the transaction, and replaced the size limit with a weight limit. In the words of BIP141: “Block weight is defined as Base size * 3 + Total size.” The base size is the block without witness data, the total size the block with it. The rule: “block weight ≤ 4,000,000.”
Put more simply, each byte of witness data counts once, and every other byte counts four times. Witness data gets a 75% discount. Explorers express the result in weight units (WU), or divide it by four to get virtual bytes (vB), a unit that can be compared with the old 1 MB rule.
Block 972,742 shows how this plays out. Its weight was 3,994,021 WU, 99.85% of the limit, so the block was full. Its virtual size was 998,505.25 vB, just under the old million. Its real size was 1.6 million bytes, because 6,119 of its 6,179 transactions used SegWit. Working back from the formula, about 797,025 bytes were base data and about 805,921 bytes were witness data.
| Measure (block 972,742, 23 October 2026) | Value |
|---|---|
| Transactions | 6,179 |
| Size in bytes | 1,602,946 |
| Weight | 3,994,021 WU (limit 4,000,000) |
| Virtual size | 998,505.25 vB |
| SegWit transactions | 6,119 |
| Header | 80 bytes |
| Reward paid by the coinbase | 3.13361901 BTC (3.125 subsidy + 0.00861901 fees) |
So there is no fixed answer in bytes. A block packed with small transactions without witness data stays near 1 MB; a block with a lot of witness data can go well above it. What is fixed is the weight, and in late October 2026 blocks were hitting it.
Why cap it at all? A larger limit would let more transactions in, but every node has to download, check and store every block, forever. The cap keeps that work within reach of an ordinary computer and an ordinary internet connection, so that checking the chain is not reserved to data centres. The cost of the cap is competition: when more transactions are waiting than a block can hold, senders bid with fees, and the miner picks the most profitable set that fits under 4,000,000 WU.
Why the header was kept to 80 bytes
The size of the header was a design choice from the start. Section 7 of the white paper, “Reclaiming Disk Space”, introduces the Merkle tree so that old spent transactions can one day be pruned while the block hash stays valid. It then does the sum. In the paper’s words, “A block header with no transactions would be about 80 bytes.” At one block every ten minutes, it adds, that makes 80 bytes times 6 times 24 times 365, or 4.2 MB a year.
The estimate has held up. On 23 October 2026 there were 972,743 blocks from block 0 to block 972,742, so the headers of the entire history of Bitcoin add up to about 77.8 million bytes, under 80 MB. A phone can store that easily, which is what makes light wallets possible: keep every header, check that each one points to the previous and meets its target, and ask for Merkle branches only when needed. Our lesson on the Bitcoin white paper explained walks through the rest of the paper.
An Ethereum block from the same morning works differently
Every blockchain has blocks, but not every block has the same label. Twelve minutes before Bitcoin block 972,742, at 08:29:11 UTC on 23 October 2026, Ethereum produced block 26,254,134. We read it through a public Ethereum node (publicnode.com). It held 444 transactions and 16 staking withdrawals in 382,756 bytes.
| Bitcoin block 972,742 | Ethereum block 26,254,134 | |
|---|---|---|
| Time (23 October 2026, UTC) | 08:41:36 | 08:29:11 |
| Transactions | 6,179 | 444 (plus 16 withdrawals) |
| Size | 1,602,946 bytes | 382,756 bytes |
| Capacity rule | 4,000,000 weight units | 60,000,000 gas (56,884,349 used) |
| Pace | about 10 minutes on average | one slot every 12 seconds |
| Who adds the block | a miner, by proof of work | a validator, by proof of stake |
| Nonce | 2,983,331,374 | 0 (field kept, unused) |
| Roots in the header | one Merkle root (transactions) | state, transactions, receipts and withdrawals roots |
Three differences stand out. The first is how the block is chosen. Since the Merge of 15 September 2022, Ethereum uses proof of stake: time is cut into 12-second slots, and a validator selected for the slot proposes the block. Nobody searches for a nonce, so the nonce field is all zeros and the difficulty field reads 0; both survive for compatibility.
The second is how capacity is counted. Ethereum measures the computing work of transactions in gas rather than their size in bytes. According to ethereum.org, each block has a target of 30 million gas and a limit of 60 million; this one used 56.9 million of its 60 million, about 94.8%. Its base fee was 57,247,900 wei per unit of gas, about 0.057 gwei. Our glossary entry on gas fees explains the units.
The third is what the header commits to. Bitcoin’s header has one root, for transactions. Ethereum’s execution header carries several, among them a state root that summarises every account balance and contract after the block, a transactions root and a receipts root that records the outcome of each transaction. They are built with a cousin of the Merkle tree, but the principle is the same: one short hash in the header that stands for a much larger set of data. Bitcoin has no state root at all, a difference that comes from how each network tracks who owns what. Our guide to Ethereum describes the network more broadly.
Reading a block yourself in an explorer
Nothing in this lesson required special access. Bitcoin blocks are public, and explorers such as mempool.space, whose code is open source, show them free of charge and without an account. To repeat the exercise on any block:
- Open the explorer and type a block height, such as 972742, in the search bar. The height is simply the block’s position: block 0 is the first, so block 972,742 has 972,742 blocks before it.
- On the block page, find the fields of the header: the previous block hash (often a link back), the Merkle root, the timestamp, the bits, the nonce and the version, sometimes under a “details” button.
- Look at the transaction list. The first entry is the coinbase; its output is the subsidy plus the total fees shown for the block.
- Compare size and weight. Divide the weight by 4,000,000 to see how full the block was.
Those who code can go one step further, as we did for this lesson: download the raw 80-byte header, hash it twice with SHA-256, reverse the bytes and compare the result with the block hash. It takes a few lines in most languages and turns the lesson’s claims into something you have checked for yourself.
The next difficulty recalculation is due at block 973,728, around 30 October 2026 if blocks keep a ten-minute pace. A later lesson in this path takes the next step after this one: why the links between these headers make an old block practically impossible to change.
