Block Weight

What Is Block Weight?

Block weight is the metric Bitcoin uses to measure how much data a block contains, expressed in weight units (WU) rather than raw bytes. Before SegWit, Bitcoin enforced a simple rule: no block could exceed 1,000,000 bytes (1 MB). This byte-count limit was straightforward but created problems as the network grew, contributing to congestion and high fees during peak demand periods.

BIP 141 (Segregated Witness) replaced the byte-based cap with a weight-based cap of 4,000,000 WU per block. The change activated at block 481,824 on August 24, 2017. Under this system, different parts of a transaction contribute differently to the block's total weight: signature and witness data receive a discount relative to the rest of the transaction. This design effectively increases Bitcoin's throughput without changing the block header structure or requiring a hard fork.

How It Works

Every Bitcoin transaction consists of two categories of data after SegWit:

• Base data (non-witness): version, inputs (previous outpoint references, sequence numbers), outputs (amounts and scripts), and locktime. This data determines who owns what and how coins move.
• Witness data: signatures and public keys that prove authorization. This data validates the transaction but does not affect the UTXO set.

The Weight Formula

Block weight is calculated using a simple formula defined in BIP 141:

Weight = (Base Size × 4) + (Witness Size × 1)

// Equivalently:
Weight = (Base Size × 3) + Total Size

// Where:
// Base Size = transaction size without witness data
// Witness Size = size of witness data only
// Total Size = Base Size + Witness Size

Under this formula, each byte of non-witness data costs 4 WU, while each byte of witness data costs only 1 WU. A legacy transaction with no witness data has a weight equal to its byte size multiplied by four. A SegWit transaction gets a discount on its signature data, making it lighter per byte of total serialized size.

Weight to Virtual Bytes

Fee estimation and mempool policy use virtual bytes (vbytes) instead of raw weight units. The conversion is straightforward:

vbytes = ceil(weight / 4)

// Examples:
// Legacy tx: 250 bytes → weight 1000 WU → 250 vbytes
// SegWit tx: 250 bytes total (150 base + 100 witness)
//   weight = (150 × 4) + (100 × 1) = 700 WU → 175 vbytes

Fee rates are expressed in sats per vbyte, which means SegWit transactions pay lower absolute fees than equivalent legacy transactions at the same fee rate. This built-in incentive encourages wallet developers and users to adopt SegWit address types.

Practical Block Sizes

The 4,000,000 WU limit does not translate directly to 4 MB blocks. A block could only reach 4 MB if it consisted entirely of witness data, which is not possible in practice because every transaction must include non-witness components (inputs, outputs, version, locktime).

Real-world blocks contain a mix of transaction types. As of late 2026, the average Bitcoin block size ranges from approximately 1.5 to 2.0 MB, with most blocks approaching the 4,000,000 WU weight limit. The all-time high daily average block size reached roughly 2.5 MB in February 2023, driven by heavy Ordinals inscription activity.

Why the Witness Discount Exists

The decision to give witness data a 75% discount was not arbitrary. It reflects fundamental differences in how witness and non-witness data affect the network:

• UTXO set impact: non-witness data determines the UTXO set, which every full node must store in memory for fast validation. Witness data does not change the UTXO set. Growing the UTXO set is more expensive for the network than growing block sizes.
• Validation cost: witness data (signatures) is verified once when a transaction enters a block, then can be discarded by pruned nodes. Non-witness data must be retained indefinitely by any node tracking the chain state.
• Backward compatibility: by weighting existing (non-witness) data at 4x, the upgrade ensured that legacy transactions would not suddenly allow larger blocks. A block full of legacy transactions still respects the effective 1 MB limit.
• Incentive alignment: the discount encourages developers to move signature data into the witness structure, which also fixes transaction malleability and enables second-layer protocols like the Lightning Network.

Use Cases

Fee Optimization

Understanding block weight is essential for minimizing transaction fees. Wallets that use native SegWit addresses (bech32 and P2WPKH/ P2WSH) produce transactions with lower weight than legacy or wrapped SegWit formats. During periods of high fee market activity, this weight reduction translates directly into lower costs.

For a deeper analysis of how block weight interacts with fee dynamics, see the research article on Bitcoin fee market dynamics.

Mining and Block Construction

Miners construct block templates to maximize fee revenue within the 4,000,000 WU weight limit. The block packing algorithm selects transactions by their fee-per-weight-unit ratio (feerate), not simply fee-per-byte. This means a SegWit transaction paying 10 sats/vbyte is more attractive per unit of block space than a legacy transaction paying the same nominal rate.

Transaction Batching

Exchanges and payment processors use transaction batching to consolidate many payouts into a single transaction. Because the witness discount reduces the marginal weight of each additional input signature, batched SegWit transactions are substantially more efficient than batched legacy transactions.

Layer 2 Efficiency

The witness discount directly benefits layer 2 protocols. Lightning Network channel opens and closes, splicing operations, and submarine swaps all require on-chain transactions that are heavily signature-dependent. Lower weight means lower fees for these operations, improving the economics of Bitcoin's scaling layers. Spark, as a Bitcoin layer 2, benefits from this dynamic whenever users move funds on-chain through cooperative or unilateral exits.

Risks and Considerations

Block Size Debate

The introduction of block weight was part of the broader Bitcoin block size debate that dominated 2015 to 2017. Critics argued that the weight system was an indirect capacity increase that should have been implemented as a straightforward block size raise. Supporters countered that the weight-based approach was superior because it aligned costs with actual network burden and enabled SegWit's malleability fix without a hard fork.

Complexity for Developers

The weight system adds complexity compared to simple byte counting. Developers building wallets or fee estimators must account for the distinction between raw bytes, weight units, and virtual bytes. Incorrectly estimating transaction weight can lead to overpaying fees or having transactions stuck in the mempool during congestion.

Theoretical vs. Practical Capacity

The gap between the theoretical 4 MB maximum and the practical 1.5 to 2.0 MB average can cause confusion. Some commentators cite the 4 MB figure to argue that Bitcoin has already scaled sufficiently, while others point to the real-world average to argue the opposite. The actual capacity depends on the mix of transaction types in each block, making simple comparisons misleading.

Witness Data Growth

Because witness data is discounted, protocols that place large amounts of data in the witness section (such as Ordinals inscriptions and certain OP_RETURN alternatives) can push block sizes closer to the theoretical maximum. This has renewed debate about whether the witness discount is being used as originally intended and whether the block space market adequately prices these data-heavy transactions.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.