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.

 
426
Kudos
 
426
Kudos

Now read this

Bigger blocks another way?

Get ten engineers on a mailing list, ask them to solve a big problem, and you’ll probably end up with eleven different solutions. Even if people agree that the one megabyte block size limit should be raised (and almost everybody does... Continue →