It must be done… but is not a panacea

There are two related arguments I hear against raising the maximum block size:

There is no need to raise the maximum block size because the Lightning Network / Sidechains / Impulse / Factom solves the scaling problem.

If the maximum block size is raised, there will be little incentive for other scaling solutions to emerge

The first is easy to address: if any of the other proposed scaling solutions were tested, practical and already rolling out onto the network and being supported by all the various Bitcoin wallets then, indeed, there would be no hurry to schedule a maximum block size increase.

Unfortunately, they’re not; read Mike Hearn’s blog post for details. We are years away from a time when we can confidently tell a wallet developer “use this solution to give your users very-high-volume, very-low-cost, very-low-minimum-payment instant transactions.”

The second is also easy to address. The “layer 2” services that are being built on top of the blockchain are absolutely necessary to get nearly instant real-time payments, micropayments and high volume machine-to-machine payments, to pick just three examples. The ten-minute settlement time of blocks on the network is not fast enough for those problems, and it will be the ten minute block interval that drives development of those off-chain innovations more than the total number of transactions supported.

Scheduling an increase to the maximum block size now is a short-term, “kick the can down the road” fix. It is ugly, but necessary.


Now read this

A definition of “Bitcoin”

Engineers are great at not seeing the forest for the trees. They get stuck on details and lose track of the bigger picture. I’ve seen it most often (and have been guilty myself) when they’re optimizing something to make it faster. They’... Continue →