Block Size

Block size is Bitcoin's most famous consensus parameter. The original 1 MB hard cap (a MAX_BLOCK_SIZE constant of 1,000,000 bytes that Satoshi slipped into the code in July 2010, generally read as an anti-spam measure) was the focus of years of debate and ultimately the 2017 SegWit soft fork. The current rule isn't a flat size in bytes; it's a 4 million weight unit limit, where non-witness data costs 4 weight units per byte and witness data costs 1.

Effects in practice:

• Typical block sizes run around 1.5 to 1.6 MB on disk, with a spread from under 1 MB to about 2.75 MB over the past month, depending on what fraction of transactions are SegWit/Taproot (which pay the witness discount). More than nine blocks in ten are full by weight, just under 4 million units, whatever their byte size.
• The hard cap keeps validation costs bounded. The minimum bitcoin.org lists for a Bitcoin Core full node is ordinary desktop or laptop hardware with 2 GB of memory and a broadband connection. That's deliberate. Larger blocks would shift node-running cost upward and centralize the validator set.
• The block weight limit has been politically untouchable since 2017. The 2015-2017 block size war (see BIP 101 and BIP 102) ended with the SegWit soft fork plus the Bitcoin Cash hard fork; the surviving Bitcoin community settled on "blocks stay small, scaling happens off-chain via Lightning."

What this isn't:

• It's not 1 MB anymore. Anyone citing "Bitcoin's 1 MB blocks" in 2026 is using outdated information.
• It's not a literal byte limit. The weight unit framing matters because it changes the economics of SegWit vs legacy transactions.

The block-size question is settled for the foreseeable future. The substantive throughput debates have moved to Lightning channel design, payment-routing efficiency, and Taproot script optimization, not on-chain capacity.

See The Block Size War for how this limit became the center of a two-year governance fight.