Bitcoin block weight vs block size comes down to what is being counted. Block size measures serialized bytes; block weight gives non-witness bytes four times the weight of witness-only bytes. Since Segregated Witness, Bitcoin’s capacity rule uses this weighted measurement.

A block can therefore have a total serialized size above one megabyte while remaining within the network’s four-million-weight-unit rule. That is expected behaviour, not evidence that the limit disappeared.

The BIP 141 weight formula

BIP 141 defines:

block weight = base size × 3 + total size

Base size is the size of the block when transactions are serialized without witness data. Total size includes both the base data and the witness data. The consensus rule is that block weight must not exceed 4,000,000 weight units.

Another equivalent way to think about the formula is:

block weight = base size × 4 + witness size

The second form makes the discount easier to see. Each byte of base transaction data contributes four weight units. Each byte that exists only in the witness contributes one.

The word “discount” describes this accounting. Witness data is still transmitted, validated and stored by full nodes.

Why raw byte size is not the consensus metric

Before SegWit, discussions often treated the one-megabyte serialized block limit as the central capacity number. BIP 141 replaced that rule with weight.

Bitcoin Core still places hard bounds on serialized data for implementation safety, but the consensus capacity check is the weight calculation. The current Bitcoin Core consensus constants define a maximum block weight of 4,000,000 and a witness scale factor of four.

A block explorer may display several figures:

  • total serialized size, including witness data;
  • stripped or base size, without witness data;
  • weight in weight units;
  • a derived virtual size.

These numbers describe the same block from different accounting views. Comparing a total-size figure from one explorer with a stripped-size figure from another will produce a misleading conclusion.

Virtual size translates weight into fee units

For a transaction, BIP 141 defines virtual size as transaction weight divided by four, rounded up to the next integer. Wallets and fee markets commonly express rates in satoshis per virtual byte, or sat/vB.

If a transaction has a weight of 800 weight units, its BIP 141 virtual size is 200 vbytes. At an illustrative rate of 5 sat/vB, the transaction fee would be 1,000 satoshis.

That example is arithmetic, not a current fee recommendation. Fee rates change with demand, and Bitcoin Core also documents sigop-adjusted policy measurements that can differ from the bare BIP 141 calculation in special cases.

The Bitcoin Core mempool terminology explicitly distinguishes BIP 141 virtual size from policy values adjusted for signature-operation limits. When reading an RPC field, check the version-specific definition rather than assuming every field called “vsize” means exactly the same thing.

A simple two-transaction comparison

Consider two hypothetical transactions with the same total serialized size.

Transaction A keeps most of its data in the base serialization. Transaction B moves eligible signatures and related data into the SegWit witness. Even if both occupy the same number of raw bytes on disk, Transaction B can have lower weight because witness-only bytes count once instead of four times.

At the same sat/vB rate, the lower-weight transaction generally pays a lower absolute fee. This is one reason a comparable Native SegWit spend can be more fee-efficient than a Legacy spend.

It does not follow that every Taproot or SegWit transaction is automatically smaller. Input count, output count and script structure still matter. See Bitcoin address types for the formats, and Bitcoin fees and payment amounts for the relationship between size and fee.

Weight is not a count of transactions

A block has no fixed transaction count. Thousands of compact transactions can fit into the same weight budget that accommodates far fewer large or complex transactions.

That is why “transactions per block” varies. A block filled with one-input, two-output payments has a different capacity profile from one containing consolidation transactions with many inputs or transactions with many outputs.

Transaction value also does not determine weight. A payment moving 10 BTC can use less weight than a payment moving 0.01 BTC if its input and output structure is simpler.

Why the witness discount exists

SegWit separated signature-related witness data from the legacy transaction serialization. The weight formula made that data cheaper in the capacity calculation while retaining a bounded resource cost.

BIP 141’s design also addressed transaction malleability for SegWit spends and enabled later protocol work built on witness versions. The discount should not be interpreted as “signatures do not matter.” It is a deliberate ratio in the consensus accounting model.

The four-to-one scale factor is a protocol rule. It is not a dynamic market setting and does not change when the mempool becomes busy.

What an explorer’s percentages mean

An explorer might say a block is 95% full based on weight, while the total-size number looks lower or higher relative to a one-megabyte reference. Those percentages are answering different questions.

For current consensus capacity, weight utilization is the relevant measure. Total bytes still matter for bandwidth and storage observations. Stripped size helps show how much non-witness data the block contains.

When comparing blocks, record the field name and unit:

  • bytes for size;
  • weight units for weight;
  • vbytes for virtual size;
  • sat/vB for fee rate.

A value without its unit is easy to misread.

Practical takeaway for wallet users

Most users do not need to calculate block weight. A wallet estimates the virtual size of the transaction it is building and combines that with a fee rate for the selected confirmation target.

You should still distinguish the inputs to that estimate. A high total fee can come from a large transaction, a high fee rate, or both. Sending a larger bitcoin amount does not directly increase weight.

If a transaction remains pending, read what Bitcoin confirmations mean before assuming a displayed block-size number explains the delay. Confirmation depends on miner selection and competing fee rates, not just the maximum block weight.