Permalink
Find file
Fetching contributors…
Cannot retrieve contributors at this time
50 lines (38 sloc) 2.64 KB

  BIP: 100
  Title: Floating block size hard limit
  Author: Jeff Garzik <jgarzik@gmail.com>
  Status: Draft
  Type: Standards Track
  Created: 2015-06-11

Table of Contents

Abstract

Replace static 1M block size hard limit with a hard limit that floats between 1M and 32M.

Motivation

  1. Long term, wean the bitcoin protocol away from any block size limit; let the free market establish a natural size limit equilibrium.
  2. Eliminate 1M limit as impediment to adoption.
  3. Execute a hard fork network upgrade within safety rails, gathering data and experience for future upgrades.
  4. Contain checks-and-balances that users must opt into, to enable system activation and growth.
  5. Validated growth: a large majority (80%) is required to change the value.

Specification

  1. Replace static 1M block size hard limit with a floating limit ("hardLimit").
  2. hardLimit floats within the range 1-32M, inclusive.
  3. Initial value of hardLimit is 1M, preserving current system.
  4. Changing hardLimit is accomplished by encoding a proposed value within a block's coinbase scriptSig.
    1. Votes refer to a byte value, encoded within the pattern "/B\d+[M]{0,1}/" Uppercase suffix 'M' applies a 1,000,000x multiplier. Example: /B8000000/ or /B8M/ votes for a 8,000,000-byte hardLimit.
    2. A new hardLimit is calculated at each difficulty adjustment period (2016 blocks), and applies to the next 2016 blocks.
    3. Calculation:
      1. Absent/invalid votes are counted as votes for the current hardLimit. Out of range votes are counted as the nearest in-range value.
      2. Votes are limited to +/- 20% of the current hardLimit.
      3. Sort the votes from the previous 12,000 blocks from lowest to highest.
      4. The raise value is defined as a vote for 2400th highest block (20th percentile).
      5. The lower value is defined as a vote for 9600th highest block (80th percentile).
      6. If the raise value is higher than current hardLimit, the new limit becomes the raise value.
      7. If the lower value is lower than current hardLimit, the new limit becomes the lower value.
      8. Otherwise, hardLimit is unchanged.

Deployment

  1. 75% rule: If 9,000 of the last 12,000 blocks are version 4 or greater, reject invalid version 4 blocks. (testnet4: 501 of last 1000)
  2. 95% rule ("Point of no return"): If 11,400 of the last 12,000 blocks are version 4 or greater, reject all version <= 3 blocks. (testnet4: 750 of last 1000)
  3. Block version number is calculated after masking out high 16 bits (final bit count TBD by versionBits outcome).

Backward compatibility

All older clients are not compatible with this change. The first block larger than 1M will create a network partition excluding not-upgraded network nodes and miners.