Block Size and Weight Limits

One of the most intensely debated topics in Bitcoin's history is the block size limit. This seemingly simple parameter regulates how many transactions can be recorded on the blockchain every 10 minutes and defines the trade-off between network throughput and decentralization.

To understand modern Bitcoin, you must understand the transition from the legacy 1MB Block Size Limit to the modern 4MB Block Weight Limit introduced by Segregated Witness (SegWit).

️ The Legacy 1MB Limit

In 2010, Satoshi Nakamoto introduced a hard limit of 1 Megabyte (1,000,000 bytes) per block. At the time, Bitcoin had virtually no transaction fees, and blocks were mostly empty.

Satoshi added this limit for two defensive reasons:

1. Anti-Spam Shield: To prevent an attacker from flooding the network with millions of free transactions, bloating the blockchain database to hundreds of gigabytes instantly.

2. Decentralization Guardrail: If blocks were allowed to grow to 100MB, only massive data centers could afford the bandwidth and storage to run a full node. Capping the block size ensured home users on cheap laptops could continue validating the blockchain.

As Bitcoin adoption exploded in 2015–2017, blocks filled up completely, causing transaction fees to spike and leading to the historic conflict known as the "Blocksize Wars."

The SegWit Revolution (BIP 141)

In August 2017, the Bitcoin network activated Segregated Witness (SegWit). SegWit was a highly sophisticated backward-compatible upgrade (a soft fork) that effectively bypassed the 1MB limit without breaking old software.

Every Bitcoin transaction has two main components:

• Base Transaction Data: Who is sending coins, who is receiving them, and how much is being sent.

• Witness Data (Signatures): The cryptographic signatures proving ownership of the spent coins. Signatures are heavy, accounting for up to 65% of a transaction's size in bytes.

Legacy Transaction Schema:
 ┌────────────────────────────────────────────────────────┐
 │ Base Data (Inputs & Outputs) + Witness Data (Signature) │ ◄── Capped at 1MB
 └────────────────────────────────────────────────────────┘

SegWit Transaction Schema:
 ┌──────────────────────────────┐ ┌───────────────────────┐
 │ Base Data (Inputs & Outputs) │ And │ Witness Data (Sign) │ ◄── Separated & Discounted
 └──────────────────────────────┘ └───────────────────────┘

SegWit "segregated" (separated) the witness data from the base transaction data.

• Old Legacy Nodes only saw the base transaction data and ignored the signatures. To them, the block still appeared to be under the 1MB limit.

• Upgraded SegWit Nodes downloaded both the base data and the separate witness data, verifying the signatures.

⚖️ Weight Units (WU) and Virtual Bytes (vBytes)

By separating signature data, Bitcoin developers could change how transaction sizes are calculated. They introduced Block Weight to replace Block Size.

A block is now capped at 4,000,000 Weight Units (WU). Weight is calculated using a 4x multiplier: $$\text{Weight} = (\text{Base Bytes} \times 4) + (\text{Witness Bytes} \times 1)$$

Because witness bytes are multiplied by 1 while base bytes are multiplied by 4, witness signature data receives a 75% discount in weight! This discount incentivizes users to adopt SegWit and Taproot addresses, which keep the UTXO set more compact.

What is a Virtual Byte (vByte)?

To make transactions easy to compare to legacy transactions, developers created the metric vSize (Virtual Size), measured in vBytes: $$\text{vSize} = \frac{\text{Total Weight}}{4}$$

Under this new metric:

• A legacy transaction has a weight of 400 WU. Capping at 4,000,000 WU means a maximum of 1,000,000 bytes (1MB).

• A SegWit transaction has heavily discounted witness data. When a block is packed with SegWit transactions, its physical size can easily reach 2MB to 2.4MB, and theoretically up to 4MB, while still strictly remaining under the 4,000,000 WU limit.

By upgrading to SegWit, Bitcoin increased its transaction capacity by roughly 2.2x without requiring a risky hard fork or raising the hardware requirements for home users running full nodes.