This is the seventh in a series of posts where we discuss the core concepts behind the Blockchain, Bitcoin and Ethereum. At Verify, we’re building a reputation protocol on the Ethereum blockchain and are sharing these posts in an effort to share our knowledge with the wider crypto community.
Forks are generally the result of a change or split in events, in code for example,when new code is developed separately from the original code creating another code that retains some properties of the original code and some new ones. This inherently means that backers would be split between the two; those who back the original copy and those who back the new, modified copy.
You may have already heard about forks in the context of cryptocurrencies like Bitcoin. Forks happen in bitcoin in various forms that can be categorized to two main categories; a fork due to the decentralized nature of bitcoin or what is
called an “unintended fork” and intended forks done intentionally either by a developer or an attacker.
Let us examine a scenario where a fork could happen in Bitcoin.
When miners mine for proof-of-work and land a valid block, there is a chance that two miners would get a valid block somewhat at the same time (when I say “somewhat” I mean when a miner successfully finds a block and broadcasts that to other nodes, some other node get the block and distribute it before receiving the successful block). So when two nodes get a valid block simultaneously a fork happens. Say the two valid blocks are A and B.
Now the blockchain will resume on the next found block. Some miners are mining on A others are mining on B; the chain that hits the next block first C will be the main chain, given it will be the longest. It rarely happens that the forks extends more than 4 blocks. It only happened twice and in both occurrences issues that caused it were fixed. That is why merchants do not accept transaction with 0–1 confirmations. It is recommended to wait for 6 confirmations to accept a transaction. By confirmation, it means more blocks get on top of the block that has your transaction.
There are ways to calculate the probability of a transaction being reversible by using the hash power (usually obtained from miners but it is not accurate and can be hidden) and the number of confirmations (here is a website to implements the calculation). Usually as mentioned 6 confirmations is enough and to be certain that a transaction is irreversible some might recommend waiting a day i.e 144 blocks.
So generally miners keep mining on the blocks they receive with the longest chain. Inherently nodes propagate blocks that they expect would sit on the longest chain.
It’s worth noting here that there is an alternative bitcoin blockchain called Testnet where it is possible to have long forks. Testnet is used for testing and its coins have no actual value so it is even possible that the long forks that happen in them happen on purpose. The distinction between Testnet’s blockchain and the main blockchain is important. The current version of Testnet is Testnet3, Testnet diverted from being a testing area over the blockchain with no coin value to commercial and people started trading the coins, so versioning was somewhat important to combat such problems.
This kind of split can be argued that it is not a fork rather a state on the network, but for this post we will consider it a fork because it is split and can be expanded even though expansion is temporary. Until the moment it merges with the main chain, we will call it a “fork”.
Now what will happen to the transactions that are in the branch? Wouldn’t this be prone to double-spend attacks? What happens to the mined coins that miners should get on valid block?
The branch that is not selected to be the main chain is usually called an orphaned branch or orphaned blocks. The transactions that are in the orphaned blocks go through what is called chain reorganization. It is worth noting the “chain re-organization” does not happen over the network at the same time, rather on clients. Basically the clients that have the orphans have to adjust and organize according to the main chain. So what happens during chain reorganization?
All transactions would go or return to the memory pool (memory pool is basically the queue of transactions to be added to blocks). If a conflicting transaction exists in the memory pool then it will dropped and it basically “never happened”. Also any transactions that conflict with the main chain will also be dropped. So to the main chain that transaction never occurred; hence, no buyer or seller would have a change in their balances. After all, anything that happened in the orphaned blocks would not be in the main chain. The other valid transactions would sit on the memory pool awaiting to be added in the upcoming block or blocks in the main chain.
To be added to the next block it has to meet the minimum fee requirements otherwise it is likely that miners will not add it in the block. Also note the coinbase of the orphan blocks are not stored. Coinbase is basically a transaction without a parent, or in other words the coins rewarded to valid block miner; remember that the coins rewarded to miners are also transactions.
Orphaned blocks happen every now and then and you can track the list of orphaned blocks here. Notice how the incidence rate is inconsistent.
The longest orphaned fork that ever happened was called the “value overflow” in which the output of one transaction was in the billions (recall the maximum bitcoin supply is 21 million) and happened at block 74638 and the fork extended to 74691. This was basically the only long fork that ever happened and was fixed to ensure it never happens again. The second longest fork was about 24 blocks and started at block 225430 (on March 2013) which was caused by client version incompatibility. Then bitcoin v 0.8 was able to handle larger number of transactions while older versions which was ran by more than 50% of nodes rejected the blocks because they could not handle it.
We have answered the question of “what will happen to the transactions that are in the branch?” Let us move to the second question of how are double spends treated?
We were introduced to the term double spends in “What you should know about nonces and difficulty” post. In short it concerns being able to spend the same coins/money twice. We mentioned earlier the way this could be countered through merchants or receivers waiting for a number of confirmations, ideally 6 confirmations. The more confirmations, the more likely the transaction would become irreversible.
Now what about the coins rewarded to miners for successfully finding a valid block? What will happen to the coins in case the valid blocks they found turned out to be orphaned blocks?
Only miners whose blocks end up in the main blockchain get rewarded. Now miners who mined orphaned blocks did not know their block is orphaned only after other blocks were mined, so what happens to the rewarded coins? Basically a maturity rule or COINBASE_MATURITY comes to play. Maturity rule states that the miner can spend their reward only after 100 confirmations i.e 100 new blocks are mined on top of that valid block (older bitcoin versions required 120 block confirmations).
Recall we mentioned that if a block is orphaned it is like it has never happened because the main chain will have no record of that orphaned block; this means that the miner who got rewarded for the orphan block no longer exists in the main chain it is like we did a reset.
With such a rule in place many issues could be avoided when a fork happens to the blockchain. It is almost impossible that a fork would be 100 blocks long but it is always better to be safe.
Having discussed unintended forks caused by the network; let’s now cover the more deliberate intended forks. In several cases, intended forks split the network resulting in a new currency and new program and even a new community like what happened with ethereum and ethereum classic.
However it is not always the case that the intended fork splits the underlying work of the network; sometimes the fork is temporary because a new rule or client has been introduced and the nodes are behind on the upgrade; eventually they catch up merging with the main chain.
There is also another type of categorization to forks. It is commonly known as Hard fork and a Soft fork. An intentional fork can (not necessarily) be soft intentional fork or hard fork and so does the Unintentional fork, it can (though not necessarily) either be soft or hard fork as per diagram below:
In the aforementioned fork of 24 blocks that happened at block 225430, it was a hard fork. The nodes running a newer version of bitcoin generated blocks that were invalid to the older version nodes. In such forks an upgrade is required by all bitcoin users to stay in sync with the network. This means that with hard forks newly generated blocks are not backward compatible with older versions or to be precise the hard forks are not forward compatible i.e the older version do not accept the newly generated blocks.
With a soft fork the previously accepted blocks would be considered invalid with the newer version. The blocks generated by older versions would be incompatible in the newer versions and the blocks generated by the newer version are backward compatible. It will be up to the hashing power to decide which split will overtake the other.
For example if more than 50% of the hashing power upgraded to the newer version, ultimately the older version would end up working on a branch that will be orphaned and vice versa. Usually the upgrade is optional because newer blocks generated by the update are still backward compatible. Also soft forks are mostly considered temporary forks were the branches will merge.
Now with that in mind, let us think about the fork when two valid blocks are generated simultaneously. What kind of fork is that?
Surely it is unintended. But is it hard fork or soft fork? Tell us what you think down below.
Verify.as
Verify is a Reputation Protocol for buying and selling things using
cryptocurrencies → https://verify.as/