Home › Browse › BIP 102

BIP 102: Block size increase to 2MB

In plain English: Proposed a single, simple increase in the maximum block size from 1 MB to 2 MB to allow more transactions per block. Being a change that older software would reject, it would have required a hard fork, and it was one of the competing options in the block size debate.

Status
Closed
Type
Specification
Layer
Consensus (hard fork)
Authors
Jeff Garzik
Assigned
Last changed
Topics
Capacity, Blocks
Source
bip-0102.mediawiki on GitHub · Markdown

Abstract

Simple, one-time increase in total amount of transaction data permitted in a block from 1MB to 2MB.

Motivation

  1. Continue current economic policy.
  1. Exercise hard fork network upgrade.

Specification

  1. MAX_BLOCK_SIZE increased to 2,000,000 bytes at trigger point.
  1. Increase maximum block sigops by similar factor, preserving SIZE/50 formula.
  1. Trigger: (1) Block time 00:00:00 on flag day, AND (2) 95% of the last 1,000 blocks have signaled support.

Backward compatibility

Fully validating older clients are not compatible with this change. The first block exceeding 1,000,000 bytes will partition older clients off the new network.

Discussion

In the short term, an increase is needed to continue to current economic policies with regards to fees and block space, matching market expectations and preventing market disruption.

In the long term, this limit should focus on reflecting the maximum network engineering limit.

Implementation

https://github.com/jgarzik/bitcoin/tree/2015_2mb_blocksize

Related proposals

  • BIP 30: Duplicate transactions: Deployed. Added a rule forbidding a block from including a transaction with the same ID as an earlier one whose outputs are not fully spent. Such duplicates can overwrite earlier coins and make them…
  • BIP 34: Block v2, Height in Coinbase: Deployed. Upgraded blocks to version 2 and required each block's coinbase transaction (the one paying the miner) to include the block's height. This makes every coinbase unique, preventing duplicate…
  • BIP 50: March 2013 Chain Fork Post-Mortem: Deployed. A post-mortem of the March 2013 incident in which a database limit in older Bitcoin software caused the blockchain to split temporarily. It explains what went wrong, how miners and developers…
  • BIP 66: Strict DER signatures: Deployed. Required all signatures to follow one strict encoding format, known as DER. Different software interpreted loosely encoded signatures differently, which risked splitting the network and let…
  • BIP 91: Reduced threshold Segwit MASF: Deployed. Proposed a way to activate SegWit with support from a simple majority of mining power instead of the 95 percent originally required. Participating miners would reject blocks that did not signal for…
  • BIP 100: Dynamic maximum block size by miner vote: Closed. Proposed replacing Bitcoin's fixed 1 MB block size limit with one that miners could vote to raise or lower, with votes counted on the same two-week cycle as mining difficulty adjustments. It was one…