A hardfork is a way to upgrade the Bitcoin protocol to include new rules. Older bitcoin software would mark transactions and blocks following these new rules as invalid, which means that a hardfork requires everyone to upgrade their software in order to continue being part of the Bitcoin network.
Fundamentally, any fork changes the basic rules of Bitcoin. This can be a very subtle rule but also a new payment type or something as big and fundamental as the maximum amount of bitcoins that can exist. This page focuses on hardforking as a technique only. The specific changes that can be done in a hardfork are out of scope for this page.
A hardfork picks one point in time after which new protocol-level rules come into effect. For instance a new type of transaction is allowed and validated after the hardfork time. All the old rules will still be valid and the entire history recorded on the blockchain can still be validated. A client that doesn't follow that rule will reject the new transaction type and thus reject blocks including it. Which means it can no longer understand Bitcoin. They will stop being part of the network.
Due the the nature of deployment (see below for details) all miners and all full nodes that want to continue being part of Bitcoin need to run software with the new Protocol rules.
The politics of getting all nodes to upgrade to the new version means that a large range of the Bitcoin ecosystem has to agree with the change of rules before it can be deployed. People that disagree with the rules can avoid running software that enables the new rules and as long as there are not enough supporting nodes and miners the upgrade of Bitcoin will not happen.
A hardfork is a change in rules such that old clients no longer accept new
blocks made by miners following the new rules. This has the effect that
old nodes reject the new blocks. In the Bitcoin software this rejection is
typically accompanied by a disconnect and ban of the node that tried to
send the new block to the old node. In very short term this will mean that
old nodes will be completely isolated from new nodes after a block was
mined that violates the old-nodes rules.
A similar issue may exist when a new transaction type is introduced, a new node relays a transaction that an old one doesn't thing is valid. Causing a disconnect.
The result is the creation of two networks. One that follows all the new rules and one that doesn't. Most of the risks involve this basic problem.
The risk is there if there are miners on the old rules still creating blocks while new miners create new blocks. This creates a. Various scenarios are possible depending on the amount of luck and amount of hashpower on each side. The risk itself is based on the fact that we can't predict what kind of reorganizations will happen. It is typically best to wait for more confirmations in the hours that a fork is scheduled to take place.
There are not enough (non-miner) nodes to support the new rules. This in reality is unlikely to be an actual issue because miners user a separate relay network.
A hardfork is a moment in time when the first transaction or block is accepted in the network that formerly would not be accepted. An old client not aware of the new rules would reject this new block or transaction. Before that point in time, there is no hardfork.
At the time of the hardfork, all the miners need to be running the new software version. If they are not, they can't mine because they reject correct blocks made by other miners. Also there need to be an amount of full-nodes in production that support the new rules.
A safe way to upgrade is thus to agree on two things;
- That the majority of the community wants this hardfork.
- What point in time to pick after which the new rules will be operational.
There are multiple ways we have seen this being done in the past. The simplest by far is to have some discussions and then in all the software decide on a block-number that introduces the new rules. This is possible for upgrades that everyone will accept without issues and are planned a considerable amount of time in the future.
Another solution is to use BIP9 voting for the upgrade. Good example of a safe way to do this is the way that BIP109 was introduced with Bitcoin Classic. The design is that miners can choose to support the feature by signaling a bit in each block they mine. If 750 out of 1000 blocks have this bit this means that a very generous super-majority of the hashing power has this feature running. After the required count is hit another 4 weeks has to go by before the new rules go into effect. This is to allow anyone in Bitcoin to upgrade their software if they haven't done so yet.
This way there is nobody left behind, and the upgrade will be completely safe.
There are various myths about risks of hardforks. Issues people see as risks, but in reality are not.
This is based on the existing risk where there is mining power on both the old and the new side of the hardfork. The myth states that the amount of mining power will stay spread over both sides for such a long time (weeks) that we have to take both sides seriously.
Economics and indeed practical considerations make this story to be so highly unlikely that it is fine to disregard this myth to the bin of irrational fears.
Should a miner, or a group of miners, decide to not upgrade while the majority of the miners did upgrade they would end up creating a. There are several problems that those miners that are in minority will face;
- The network still assumes all miners on one chain, so they will have minority hashing power and the rate at which they find blocks will slow down relative to their percentage of hash power. So if 10% of the hashpower is on the minority chain, it will take on average 100 minutes, instead of 10, to find a block. The bi-weekly change of difficulty won't come every 2 weeks anymore. It will take much longer.
- With blocks not coming very regularly, the transaction backlog will grow. Notice that the transactions being sent on the main chain will be eligible for mining on the minority chain as well, causing this backlog to grow even faster. A larger backlog will make users unhappy and they may switch to the main chain even if they dislike the new policies.
- Miners mining on the minority chain will get paid in bitcoins that will have zero value on the main chain. This is because they are unknown there. A miner mining on a minority chain thus needs to find people willing to pay for his electricity bills otherwise.
- Mining profits (coinbase) are not spend-able until 100 blocks have been mined on top of it, as part of the protocol rules. 100 blocks is normally about a day of mining. But due to point 1, it may take considerably longer.
- All above points combine to make miners uncertain of getting payment on the minority chain. On the main chain, however, their mining power can generate coins that actually can be used as payment later on. If some miners leave they make the situation worse for everyone else on the minority chain.
- The last to leave the minority chain is the bag-holder. They get to pay all the unpaid bills and end up losing the most.
The high risk and near certainty that you won't get paid for working on a minority chain makes this myth totally busted.