提要
此BIP提议将采用随时间增长的线性区块扩容的方式，来替代1mb的区块大小上限。
动机
鉴于比特币网络上的交易一直在增长，且很快将达到1mb区块大小（每十分钟1mb）的限制。该方案的目的，是对比特币区块进行扩容，以减少比特币交易增长而产生的限制影响。
规范
部署网络之后（详见部署部分），主网络上的最大块大小将根据区块头（block header）中的时间戳来计算。
块最大上限将在UTC时间2016-01-11 00:00:00 达到8mb（时间戳为1452470400），且区块大小上限将以每63,072,000 秒进行翻倍（两年，忽略闰年），直到UTC时间2036年1月6日00：00:00 （时间戳为2083190400），比特币的区块最大上限将达到8192MB。
在伪代码中，使用的是整数运算，假定block_timestamp是在激活时间之后（代码如下）：
function max_block_size(block_timestamp):
time_start = 1452470400
time_double = 60*60*24*365*2
size_start = 8000000
if block_timestamp >= time_start+time_double*10
return size_start * 2^10
// Piecewise-linear-between-doublings growth:
time_delta = block_timestamp - time_start
doublings = time_delta / time_double
remainder = time_delta % time_double
interpolate = (size_start * 2^doublings * remainder) / time_double
max_size = size_start * 2^doublings + interpolate
return max_size
部署
部署将由算力投票来决定（类似在BIP34中所使用的技术），最早的激活时间可能是UTC时间 2016-01-11 00:00:00 。
激活的完成，将由最佳链中1000个连续块中的750个块具有（十六进制0×20000004）的版本号来实现。
激活时间将是第750个块的时间戳加上两周的时间（1,209,600秒），这个宽限期是为了给剩余的矿工或服务，提供升级时间。如果大多数矿工在 UTC时间2016-01-11 00:00:00前两周完成了升级，则激活时间将是UTC时间2016年1月11日00:00:00 。
区块版本号将仅用于激活，一旦激活完成，区块的最大块大小应是说明部分中描述的大小（8mb），区块的版本号不用管。
原理解释
8mb的初始区块大小，是根据矿工们反馈的关于网络带宽限制问题，之后进行权衡的结果（特别是中国矿工受到GFW限制的原因）。
进行翻倍的决定是基于CPU、存储和互联网带宽长期的增长趋势而得出。而选择20年为限，是因为考虑到指数增长不能永远持续。
整个计算是基于时间戳，而不是基于区块链高度，因为时间戳是每个区块头的一部分。在下载区块头之后就可以知道区块的最大体积，而无需等待任何交易的下载。
部署计划取自 Jeff Garzik提出的BIP100 区块扩容方案，方案的设计将给矿工、商家以及运行全节点的用户足够的时间来升级软件，以支持更大的区块。鉴于75%的算力选择了该方案，因此，仅仅一个大的矿池并不能否决该区块扩容方案。版本号方案的设计和Pieter’s Wuille提出的 “Version bits” BIP相兼容。
兼容性
这需要一个硬分叉来实现对比特币协议的改动，任何运行全节点的用户必须要在激活时间前完成升级，否则将会面临拒绝包含大于1mb区块大小链的风险。
简化验证支付软件（SPV）将不受影响。
执行代码
－－－－
原文：
https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki作者：gavin andresen
翻译：洒脱喜
责编：洒脱喜
稿源（译）：
巴比特资讯
