Live prices are currently unavailable — the exchange feed could not be reached and no recent cached reading is held.

Bitcoin Data GuideBitcoin Reference

Protocol & Mining

Block size, block weight and how the limit is counted

A block is capped at 4,000,000 weight units. Non-witness bytes count four units each and witness bytes count one, so the original one-megabyte limit survives as the base-data component of a larger budget rather than as a separate rule.

Protocol referenceSource: BIP 141, Segregated WitnessThe weight multipliers and the 4,000,000-unit limit are quoted from BIP 141.

The original limit

Bitcoin's first block size rule was a cap of one million bytes on the serialised size of a block. It was introduced as a temporary measure against a denial-of-service concern rather than as a considered monetary parameter, and it was not expected to bind for years. It bound sooner than that. As transaction volume grew, the cap became the constraint that decided how many payments could be confirmed in a block, and the fee market that emerged was a direct consequence of it.

The limit was expressed in bytes, and bytes are a blunt unit for the purpose. A block is not a uniform substance: some of its bytes carry the inputs and outputs that define what a transaction does, and some carry the signatures and other data that prove it is authorised. The two are not equally costly to store or to propagate, and treating them as equivalent meant the limit was counting things that are not alike. The weight rule replaced the byte count with a measure that distinguishes them.

The distinction matters because it is the reason a SegWit transaction is cheaper than a legacy one. If all bytes counted equally, moving a signature into the witness would change nothing. Because witness bytes count at a quarter of the rate, moving them reduces the weight of the same economic transaction, and the fee market prices weight rather than bytes.

How weight is computed

BIP 141 defines a transaction's weight as the size of its non-witness data multiplied by four, plus the size of its witness data multiplied by one. A block's weight is the sum of its transactions' weights plus the weight of the block header, and the block is capped at 4,000,000 weight units. The multipliers are the whole rule; there is no separate byte limit to satisfy.

The arithmetic is worth working through because it explains where the familiar one-megabyte figure went. A block containing no witness data at all has a weight of four times its size, so a block of one million bytes weighs exactly 4,000,000 units and sits precisely at the limit. The old cap is therefore still enforced, as the case where the witness component is zero. A block that carries witness data can be physically larger than a megabyte, because the witness bytes are counted at a quarter of the rate and leave room in the budget for more base data.

The practical effect is that the maximum physical size of a block depends on its contents. A block of pure witness data could in principle be four million bytes, because four million witness bytes weigh four million units. A block of pure base data is capped at one million bytes. Real blocks sit between the two, and the mix shifts with how much of the network's traffic uses witness outputs. This is why the capacity increase from SegWit arrived gradually rather than as a step: it depended on adoption.

Why weight is what fees price

A miner choosing transactions for a block is choosing how to fill a fixed budget of weight. The rational choice is the set of transactions that returns the most fee for the weight they consume, which is why fee rates are quoted per unit of weight rather than per transaction. A transaction with a high absolute fee but a large weight may be less attractive than a smaller transaction paying less, and a wallet that estimates fees correctly is estimating the weight its transaction will consume.

This is the mechanism behind the witness discount. A native SegWit spend places its signature in the witness, where it counts at a quarter rate, so the same payment consumes less of the block's budget and can be included at a lower absolute fee. The saving is not a subsidy or a policy preference; it falls directly out of the weight definition. The address types page sets out which output forms benefit and by how much.

The weight rule also shapes how a mempool behaves. Because the budget is finite and the demand for it varies, the fee rate at which a transaction is likely to be confirmed moves with the backlog, and a transaction that is uneconomic to include waits. The mempool page describes how that queue is ordered and how entries leave it, and the SegWit page covers the change that introduced the weight rule.

Sources

Related reading