Author: Kalle Rosenbaum 2015-06-22 20:27:19
Published on: 2015-06-22T20:27:19+00:00
In this email, Kalle raises a few questions and comments about Gavin Andresen's proposal to increase the maximum block size in Bitcoin. Specifically, he questions the use of "t_start" instead of "time_start" in the specification and suggests that the specification should address the potential for miners to manipulate the max block size by manipulating the timestamp in the block header. Gavin Andresen's proposal is titled "Increase Maximum Block Size" and outlines a plan to replace the current fixed one megabyte maximum block size with a maximum size that grows over time at a predictable rate. The motivation behind this proposal is to reduce the impact of the current limit on Bitcoin adoption and growth as transaction volume on the network continues to grow. The new maximum block size will be calculated based on the timestamp in the block header and will start at 8,000,000 bytes at a timestamp of 2016-01-11 00:00:00 UTC. It will then double every 63,072,000 seconds (two years) until 2036-01-06 00:00:00 UTC, at which point the maximum size of blocks will be 8,192,000,000 bytes. The maximum size of blocks in between doublings will increase linearly based on the block's timestamp.Deployment of the new maximum block size will be controlled by hash-power supermajority vote, with activation achieved when 750 of 1,000 consecutive blocks in the best chain have a version number with bits 3 and 14 set. The activation time will be the timestamp of the 750th block plus a two-week grace period to allow miners and services time to upgrade to support larger blocks. This proposal is a hard-forking change to the Bitcoin protocol and anyone running code that fully validates blocks must upgrade before the activation time or risk rejecting a chain containing larger-than-one-megabyte blocks. Simplified Payment Verification software is not affected unless it makes assumptions about the maximum depth of a transaction's merkle branch based on the minimum size of a transaction and the maximum block size. In terms of objections or arguments against this proposal, Gavin Andresen's blog post (linked in the email) outlines several, including concerns about the potential for centralization and the difficulty of upgrading to support larger blocks. Additionally, there are other proposals for increasing the maximum block size that may have different advantages and disadvantages compared to this one.
Updated on: 2023-06-10T00:22:49.377976+00:00