What is inside a block: header, height, size and subsidy
A block is a small fixed header plus a body of transactions. Knowing which is which explains what mining actually hashes and why.
Two parts, and only one of them gets hashed
A block has a header and a body. The body is the transactions, and it can be a few hundred bytes or several megabytes depending on how busy the chain is. The header is a fixed summary of the block, and on most chains it is exactly 80 bytes.
Mining hashes the header and nothing else. That is the single most useful fact in this article, because it explains something that otherwise looks impossible: a miner tries billions of variations per second, and it could not do that if each attempt meant rehashing a block full of transactions. It does not. It rehashes 80 bytes.
The six fields in the header
The header holds a version, the hash of the previous block, the merkle root, a timestamp, the difficulty bits and the nonce. Every one of them is there for a reason, and two of them do most of the work.
The previous block hash is what makes it a chain. Each header names the one before it, so rewriting an old block would change its hash, which would break the next header, and the next, all the way to the tip. That is the whole security argument for proof of work in one field.
The merkle root is a single hash that summarises every transaction in the body. Change one transaction, even by a single byte, and the merkle root changes, so the header changes, so every hash attempted so far is worthless. This is how 80 bytes can honestly stand in for a block of any size.
The difficulty bits are the target the hash has to come in under, in a compact form. The timestamp is roughly when the block was made, and it is allowed to be approximate. The nonce is the field the miner is free to change, which is what makes the search possible at all.
The nonce runs out, and that is fine
The nonce is a small counter, and a modern miner exhausts every value it can hold almost instantly. This sounds like a dead end and is not, because the nonce is only the most convenient thing to change, never the only one.
When it runs out, the miner changes something else that feeds the header. The timestamp can move. The coinbase transaction can be altered slightly, which changes the merkle root, which gives a completely fresh header to search. On a pool this is exactly what the extra nonce is for: it lets the pool hand every miner a different starting point so no two of them are grinding the same numbers.
Height is a position, not a field
Block height is how many blocks came before a given block. The genesis block is height zero, the next is one, and so on. It is the number you see beside every entry on the pool blocks page and on any explorer.
It is worth knowing that height is not really stored in the header. It is derived from where the block sits in the chain. On most modern chains the height is written into the coinbase transaction as well, which is a rule added later so that two blocks at different heights can never be byte identical, but the authoritative answer to how high a block is remains its position.
This is also why height is the natural way to talk about confirmations. A transaction buried six blocks deep is one whose block height is six below the tip, and each further block makes rewriting it that much more expensive.
Size is the body, and it is what fills up
Block size is essentially the size of the body, because the header is a rounding error next to it. When people say a chain has a block size limit, they are talking about how many transactions can fit, not about the header.
A full block and an empty block take exactly the same amount of mining work. Difficulty decides how hard a block is to find; size decides how much the block carries. They are unrelated, and confusing them is the source of a lot of bad intuition about fees.
What size does affect is the fee market. When more transactions want in than fit, the ones offering higher fees get in first, and the total fees in the block rise. That flows straight into what the block pays.
The coinbase transaction and the subsidy
The first transaction in every block is special. It has no sender, it creates coins out of nothing, and it pays them to whoever made the block. It is called the coinbase transaction, which has nothing to do with the exchange of the same name.
What it pays is the subsidy plus the fees of every other transaction in the block. The subsidy is the newly issued part, set by the chain's emission schedule and reduced over time on most coins. The fees are what users attached to their transactions to get included. Together they are the block reward.
On a pool the coinbase pays the pool, which then distributes the reward across everyone who contributed shares to that round. That is not a detour: it is how a pool can pay many people for a reward that arrives as one indivisible payment.
Why any of this matters while you are mining
Three things become obvious once the shape of a block is clear, and all three come up constantly.
- Why a new block invalidates your work instantly. The previous block hash field changed, so the header you were searching no longer exists. Anything you submit for it afterwards is a stale share, and no amount of speed fixes that.
- Why the pool sends you fresh work so often. Every new transaction the pool wants to include changes the merkle root, and a fresher template carries more fees, which is more reward for the same effort.
- Why block size never appears in an earnings estimate. What you earn is decided by difficulty, the subsidy and the fees, not by how many bytes were in the body.
The blocks page on this pool shows the height, the reward and when it was found, which is the useful part of all of the above condensed into a row. The explorer will show you the rest, including the coinbase transaction that paid it.