Hard vs soft fork: is there a third way to increase the Bitcoin block size?

The “blocksize debate” is currently a hugely contentious issue within the Bitcoin community.

Simply put, the blocksize limit is a cap on how many transactions can take place every 10 minutes and is currently limited to as many as will squeeze in a 1MB block.

There is an entirely different debate about how much or even whether this limit needs raising, but here I will solely be doing my best to explain one of the ways a future block size increase could be achieved.

To begin with, I need to explain the difference between a hard and soft fork.

It relates to backwards compatibility. Imagine you and many others are playing an online game where you all roam around a virtual world together collecting flowers to score points. You’re all trying to achieve a high score.

Mushrooms. Photo Copyright RoyaltyFreeImages.netOne day, the game releases an update, and adds mushrooms to this world. Just like flowers, the mushrooms can also be collected to score points.

How this upgrade is implemented can be compared to a soft fork and a hard fork.

 

If the upgraded version of the software is not compatible with the old version, you have a hard fork. In this situation, anybody who updates their software will be in a new world, we’ll call it mushroom land, and anybody who has the old software will be in flower land. The people in mushroom land know they arrived there through an update. Back in flower land, people may wonder where all the other players disappeared to, but will continue to continue playing amongst themselves, not realising that everybody else is playing an updated version of the game, and that the high scores they’ve worked so hard to achieve will be lost when they eventually realise that they need to upgrade to mushroom land.

If the upgraded software has backwards compatibility with the old version, you have yourself a soft fork. In this situation, maybe people with the upgrade can see mushrooms, but to those who haven’t, the new mushrooms just look like more flowers. Crucially, people with the old software can still play with those who have upgraded, and even though the world looks a little different – ultimately everybody is still playing the same game.

So is there a third way?

Maybe there is. Let’s imagine that for technical reasons there is no way mushrooms can be introduced, even as flowers, without a software upgrade. Perhaps though, all players can participate in the same virtual world, except that those with the upgrade can also see mushrooms, while those without cannot. Crucially, people are not playing a completely different game, and when someone in flower land does upgrade they can take their score with them, and start collecting mushrooms without losing out.

How can this be achieved in Bitcoin?

Instead of just losing points, a worst case scenario for a Bitcoin hard fork would be people losing money. Whatever happens, there must always be a block produced with 1MB or fewer transactions, otherwise Bitcoin will hard fork as old software will not recognise the new block.

So how do we prevent anybody losing money? We create a mushroom block. This mushroom block can be larger than 1MB. The existing 1MB block remains in place as a legacy block. Transactions that make it into the legacy block can be viewed by everybody on the network, those in the mushroom block can only be seen by those who have upgraded.

Once any Bitcoin has made its way into a mushroom block, it can not be viewed or spent again by software that has not been upgraded. This isn’t quite a hard fork though as people on the old software will still be participating in the same network, they just won’t be able to see all the transactions that are actually taking place. If they try and spend Bitcoin that appears to be theirs on the old software, but actually has been spent on a mushroom block and belongs to someone else, all that will happen is that the miners will reject the transaction and they will not be able to spend it.

Ultimately, this is not ideal, and while it would no doubt create confusion, it would not create a complete hard fork and should not lead to anybody losing Bitcoin.

The only people who would actually need to upgrade for this to take place would be the miners. Technically speaking, they could have already done this and none of us would know. Since mining is far more centralised and dominated by a smaller group with a huge financial stakes, it is likely that such an upgrade could be achieved rapidly, once the software is ready of course. For everyone who hasn’t upgraded, Bitcoin would just become increasingly less useful until they did so.

There are a few ways this type of upgrade could be implemented. In its harshest form, the 1MB block could be mined empty with all transactions occurring on the mushroom block. You would think people would start to upgrade pretty quickly as this would basically be a forced upgrade as their software would be useless to them. More reasonably, transactions generated by older software, and with the highest fees should be included in the smaller block, while those who have upgraded could be rewarded with lower fees having their transaction included in the upgraded network where there is more capacity.

When or how a block size limit will increase remains to be seen, but here is a very simplistic explanation of one way it could be achieved. There are no doubt many technical obstacles and reasons why this concept may not be viable, but I wanted to at least try and explain the principle, I hope you’ve found it helpful.

For a far more technical explanation, credit to ZoomT, head over to BitcoinTalk.

I’ve recently started blogging about Bitcoin. If you liked this article please check out my others. Any questions or suggestions, let me know in the comments. Tips welcome: 1H2zNWjxkaVeeE3yX6uVqng5Qoi6gGvYTE

Follow me

John Hardy

Software developer living in UK.
Longtime Bitcoin advocate.
Email [email protected]
Donations welcome: 1H2zNWjxkaVeeE3yX6uVqng5Qoi6gGvYTE
John Hardy
Follow me

Author: John Hardy

Software developer living in UK. Longtime Bitcoin advocate. Email [email protected] Donations welcome: 1H2zNWjxkaVeeE3yX6uVqng5Qoi6gGvYTE

1 thought on “Hard vs soft fork: is there a third way to increase the Bitcoin block size?”

  1. If done responsibly, nobody loses money from a hard fork.

    An XT-style “8 weeks to activation” fork will give everybody time to upgrade. If you send or receive money during the 8 weeks it goes onto both chains. After the 8 weeks virtually nobody will be left on the old client, and people who don’t upgrade will find that their transactions never get confirmed (I.e. returned to them on the old chain and never spent on the new). Anyone mining on the old chain would be insane to do so as there would be no payoff – all exchanges would be upgraded. And so few miners would be mining at such a high difficulty that it would be days or weeks between blocks.

    The problem only arises when people start demonising a hard fork and creating doubt in people’s minds. If XT was to get 75% supermajority and activate, perhaps a significant number of diehards would resist upgrading because “It’s an altcoin” or “It’s a hostile takeover” and convince others to stay with the old software.

    But handled responsibly, a hard fork need not be a problem.

Comments are closed.