Gavin Andresen experiments with bigger blocks

Gavin Andresen

As Bitcoin scales, the protocol is encountering all sorts of growing pains. Bitcoin is being used more and more (and that’s good), but this is bringing to the forefront potential issues with the protocol that have to be resolved. The most dramatic scale problem is the miner bandwidth issue, which prompted discussions of tree chains and side chains to alleviate it. Another issue, in the nearer term, is more straightforward: there’s a hard limit on the size of the blocks of 1MB. Gavin Andresen has recently been looking into changing that.

The problem, in a nutshell, is that you can only fit so many transactions into 1MB, and the network can only add new blocks so quickly. If we reach a point where more than an MB of transactions are being generated for every new block, then low-fee transactions will start getting ignored, potentially indefinitely. There are some more exotic approaches to this problem (like invert-able bloom filters), but there’s also a really simple way: raise the cap on block sizes. The question is, can the network take it?

The answer, according to Gavin Andresen’s blog post on the subject is, seemingly, yes. Andresen talks through his process for generating a small mock block chain (from real transaction data that he’s collected by running a full node), and the results of his tests, which are promising. Performance scales well with the size of the blocks, and his laptop can continue to mine and run a full node at twenty, or even 200 MB (though the latter only if he allocates the mining process more resources).

Andresen is going to run some more tests, but, if they go well, he’s likely to advocate a hard fork in the relatively near future, to allow the maximum block size to scale as needed to keep ahead of increasing demand. For those who don’t know, a hard fork is a software change that breaks backwards compatibility with previous versions of the mining client and causes them to accept different block chains as canonically, effectively splitting the Bitcoin network between those who updated and those who did not. Hard forks are expensive, inconvenient, destructive, and — sometimes — necessary.

For more details on the development and testing process, check out Andresen’s original blog post, and the inevitable long discussions on the BitCoinTalk mailing.