Bitzuma

Raising the Block Size Limit with a Soft Fork

Updated

Contrary to popular belief, the block size limit can be raised with a soft fork. This article explains how. The same technique can be applied to any change that would otherwise require a hard fork update.

Imagine a soft fork called Bitcoin Neo that works as follows. If ≥ 75% of the last 2000 block headers vote in support of Neo, then every subsequent block must:

  1. Vote for Neo;
  2. Contain only a coinbase transaction; and
  3. Include in the coinbase transaction the hash of a valid Neo block.

A Neo block works exactly like a current Bitcoin block, but it can be of any size whatsoever. Perhaps the size of Neo blocks is capped at two megabytes. Maybe Neo abolishes the cap altogether. The limit could even be set algorithmically or through dynamic miner consensus.

Soft Fork Block Size Increase

After Neo has been activated, old nodes see blocks that only contain a coinbase transaction (left). Neo nodes see the same old blocks, but each one is linked to a Neo block through the coinbase transaction (right).

For the moment, the size of Neo blocks is less important than the way they get introduced. By adding the right kind of structured data to the coinbase transaction, just about any Neo block scheme can be supported.

Bitcoin Neo is based on ideas outlined in Peter Todd’s “Forced Soft Forks“ post. It also resembles the deployment mechanism for the Segregated Witness proposal. The same deployment mechanism could, in principle, be used to change nearly any Bitcoin consensus rule.

Even though Neo lifts the effective block size limit, it would work just like a soft fork. In other words, nothing required by Neo breaks the current consensus rules. The current protocol allows miners to add multiple user transactions, but nothing obligates them to add even one. Miners can (and have) embedded a variety of data within the coinbase transaction, the best-known case of which was Satoshi Nakamoto himself. Bitcoin Neo simply forces miners to adopt certain behaviors that are already valid.

Most importantly, Neo could be implemented by miners acting alone — unlike a hard fork.

Old non-generating nodes would remain part of the network. They’d see exactly the same old block headers, and find exactly the same lonely coinbase transaction as Neo nodes. Moreover, old nodes would identify and follow the same active chain as Neo nodes. As far as any old node could tell, it would continue to follow the consensus chain and all reorganizations.

But old nodes would also notice something very strange: transactions would never confirm. Unconfirmed transactions, both with and without parents, would clog an old node’s memory pool. None of them would ever show up in a block.

Neo nodes, in contrast, would see transactions enter the memory pool and get confirmed, just as they always did. But unlike old nodes, Neo nodes would note the hash value embedded within the coinbase transaction, using it to request a Neo block from peers.

The net result would be to increase transaction throughput without subjecting the network to a hard fork. Backward-compatibility would be maintained, but at the cost of rendering old nodes practically useless in the process.

Although the wisdom of such an approach could be endlessly debated, the more practical questions are: (a) how feasible is this kind of soft fork; and (b) what, if anything could prevent it?

End Mark