Glossary

Block Size Limit

The maximum size of a Bitcoin block, currently measured in weight units (4M WU) after SegWit, constraining transaction throughput.

Key Takeaways

  • Bitcoin's block size limit caps how much data fits in each block: originally 1 MB of raw bytes, now measured as 4 million weight units after the SegWit upgrade in 2017, yielding an effective block size of roughly 1.5 to 2.3 MB.
  • The limit is a deliberate trade-off: it constrains base-layer throughput to approximately 3 to 7 transactions per second but preserves decentralization by keeping full-node hardware requirements accessible to ordinary users.
  • Layer 2 protocols like Lightning Network and Spark scale Bitcoin beyond this constraint, processing thousands of transactions off-chain while inheriting the security of the base layer.

What Is the Block Size Limit?

The block size limit is a consensus rule that restricts the maximum amount of transaction data a single Bitcoin block can contain. Every block mined on the network must satisfy this constraint, or other nodes will reject it as invalid. The rule exists to prevent the blockchain from growing so fast that running a full node becomes impractical for everyday participants.

Satoshi Nakamoto introduced the original 1 MB limit in September 2010, adding it quietly to the codebase to prevent denial-of-service attacks after a vulnerability was exploited in block 71,036. The change was intentionally low-profile: it was hidden inside commits with unrelated descriptions. Satoshi later suggested that increases could be phased in over time, but he left the project in December 2010 before any such change was made.

In August 2017, the activation of Segregated Witness (SegWit) replaced the simple byte limit with a weight-based system. The new rule allows up to 4 million weight units (4M WU) per block, which translates to roughly 2 MB for a typical mix of transactions. This was the resolution to one of Bitcoin's most contentious debates.

How It Works

Before SegWit, the rule was straightforward: serialized block data could not exceed 1,000,000 bytes. After SegWit activated at block 481,824 on August 24, 2017, Bitcoin switched to a weight-based accounting system that distinguishes between two categories of data.

Weight Unit Calculation

Every byte in a transaction is assigned a weight depending on its role:

  • Non-witness data (inputs, outputs, version, locktime): 4 weight units per byte
  • Witness data (signatures, redeem scripts): 1 weight unit per byte

A block's total weight is the sum of all its transaction weights. The consensus rule requires this total to stay at or below 4,000,000 weight units.

Transaction weight = (base size × 4) + (witness size × 1)

# Equivalently:
Transaction weight = (base size × 3) + total size

# Block constraint:
sum(all tx weights) ≤ 4,000,000 WU

For a block composed entirely of legacy (non-SegWit) transactions, 4M WU still equals exactly 1 MB, preserving backward compatibility. For blocks with typical SegWit transactions (where witness data makes up roughly 60% of total size), the effective block size lands around 1.6 to 2.0 MB. The theoretical maximum is approximately 4 MB for a pathological block composed almost entirely of witness data.

Virtual Bytes

Virtual bytes (vBytes) provide a simplified way to express transaction weight: 1 vByte equals 4 weight units. Fee estimation tools typically quote rates in satoshis per vByte, making it easier for wallets to calculate fee estimates without working directly with weight units.

The Block Size War

The block size limit became the focal point of Bitcoin's most significant governance crisis. From roughly 2015 to 2017, the community split into two factions with fundamentally different visions for scaling Bitcoin.

Big Blocks vs. Small Blocks

The "big blockers" argued that Bitcoin should scale by increasing the block size limit directly. Their position: Bitcoin was designed as peer-to-peer electronic cash, and rising fees from full blocks would push everyday users off the network. Prominent supporters included Roger Ver and Bitmain co-founder Jihan Wu.

The "small blockers" countered that larger blocks would centralize the network by pricing out home node operators. Their position: the base layer should remain a secure settlement layer with scaling handled by Layer 2 protocols. Most Bitcoin Core developers aligned with this view.

Key Events

DateEventOutcome
2015Bitcoin XT proposed (8 MB limit)Failed to gain consensus
Feb 2016Hong Kong AgreementSegWit + 2 MB hard fork promised; fork never delivered
May 2017New York Agreement (SegWit2x)SegWit first, then 2 MB fork in November
Aug 1, 2017Bitcoin Cash fork (block 478,558)Big blockers created BCH with 8 MB limit (later 32 MB)
Aug 24, 2017SegWit activated (block 481,824)4M WU weight limit replaced the 1 MB byte limit
Nov 8, 2017SegWit2x cancelledPlanned 2 MB hard fork abandoned due to lack of support
Nov 2018Bitcoin SV fork from Bitcoin CashBSV launched with 128 MB limit

The resolution preserved Bitcoin's conservative base layer while opening the door to off-chain scaling. The SegWit activation also enabled the Lightning Network by fixing the transaction malleability bug that had blocked payment channel designs.

Why It Matters

The block size limit shapes Bitcoin's most fundamental characteristics. It is not merely a technical parameter: it reflects a deliberate design philosophy that prioritizes security and decentralization over raw throughput.

Decentralization

Every full node must download, validate, and store every block. As of 2026, the Bitcoin blockchain exceeds 600 GB. Larger blocks would accelerate this growth, increasing the bandwidth, storage, and processing power required to run a node. The limit ensures that participants with consumer-grade hardware and a standard internet connection can still independently verify every transaction.

Spam Prevention

Without a size constraint, an attacker could flood the network with enormous blocks filled with junk data, overwhelming nodes and degrading performance. The block size limit acts as an economic gatekeeper: filling a block requires paying market-rate transaction fees, making sustained spam attacks expensive.

Block Propagation

Larger blocks take longer to propagate across the global network. Slow propagation increases the stale block rate: blocks that are valid but arrive too late to be included in the longest chain. This disproportionately harms smaller miners, creating centralization pressure in the mining industry. Technologies like compact block relay have reduced propagation times, but larger blocks would reverse those gains.

The Fee Market

When demand for block space exceeds supply, users compete by offering higher fees. This creates a fee market that sustains miner revenue as the block subsidy diminishes with each halving. A higher block size limit would reduce fee pressure in the short term but could undermine the long-term security budget.

Throughput in Practice

With 10-minute average block intervals and the 4M WU weight limit, Bitcoin's base layer processes approximately 3 to 7 transactions per second (TPS), depending on the average transaction size. For comparison, Visa's network can handle an estimated 65,000 TPS at peak capacity.

Average block sizes in 2025 and 2026 have typically ranged from 1.5 to 2.0 MB, with a peak of approximately 2.3 MB in March 2024 driven by Ordinals inscriptions. The gap between actual block sizes and the theoretical 4 MB maximum reflects the real-world mix of SegWit and legacy transactions.

Scaling Beyond the Limit

Rather than increasing the block size, the Bitcoin ecosystem has pursued a layered scaling strategy. The base layer provides finality and security, while upper layers handle volume.

Lightning Network

The Lightning Network creates off-chain payment channels between participants. Thousands of transactions can occur within a channel, with only the opening and closing transactions recorded on-chain. This approach offers near- instant settlement and dramatically higher throughput without changing Bitcoin's consensus rules. For a deeper comparison of scaling approaches, see the Bitcoin Layer 2 comparison.

Spark Protocol

Spark takes a different approach using FROST threshold signatures and statechain concepts. Instead of payment channels, Spark transfers ownership of UTXOs by rotating cryptographic keys off-chain. This eliminates the need for channel management while preserving self-custody: users can always exit to Bitcoin Layer 1 without permission from any third party. Spark also supports native stablecoin transfers through the USDB stablecoin.

Other Approaches

Additional Layer 2 strategies include sidechains (like Liquid, which uses federated consensus for faster block times), state channels, and proposals like channel factories that reduce the on-chain footprint of opening multiple Lightning channels.

Risks and Considerations

Throughput Constraints

At 3 to 7 TPS, Bitcoin's base layer cannot serve as a global payment system on its own. During periods of high demand, the mempool grows and fees spike, sometimes making small transactions uneconomical. Layer 2 adoption is not optional: it is a prerequisite for Bitcoin to function as everyday money.

Future Debate

The block size debate is settled for now, but not permanently. As Bitcoin adoption grows, the question of whether the base layer should accommodate more throughput will likely resurface. Any change would require broad community consensus and a soft fork or hard fork, depending on the approach.

Ordinals and Inscriptions

The Ordinals protocol, which embeds arbitrary data in witness space, has reignited discussion about how block space should be used. Critics argue that inscriptions consume weight units that could serve financial transactions. Proponents counter that the witness discount was designed to make data-heavy transactions cheaper, and the fee market already adjudicates competing uses of block space.

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.