Bitcoin forks are defined variantly as changes in the protocol of the bitcoin network or as the situations that occur "when two or more blocks have the same block height".^[1] A fork influences the validity of the rules. Forks are typically conducted in order to add new features to a blockchain, to reverse the effects of hacking or catastrophic bugs. Forks require consensus to be resolved or else a permanent split emerges.

Forks of the client software

The following are forks of the software client for the bitcoin network:

Bitcoin XT

A fork initiated by Mike Hearn. The current reference implementation for bitcoin contains a computational bottleneck.^[2] The actual fork was preceded by Mike Hearn publishing a Bitcoin Improvement Proposal (BIP 64) on June 10, 2014, calling for the addition of "a small P2P protocol extension that performs UTXO lookups given a set of outpoints."^{[src 1]} On December 27, 2014 Hearn released version 0.10 of the forked client XT, with the BIP 64 changes.^{[src 2]} It achieved significant attention within the bitcoin community in mid-2015 amid a contentious debate among core developers over increasing the block size cap.^[3]

On June 22, 2015, Gavin Andresen published BIP 101 calling for an increase in the maximum block size. The changes would activate a fork allowing eight MB blocks (doubling in size every two years) once 75% of a stretch of 1,000 mined blocks is achieved after the beginning of 2016.^{[src 3]} The new maximum transaction rate under XT would have been 24 transactions per second.^[4]

On August 6, 2015 Andresen's BIP101 proposal was merged into the XT codebase.^{[src 4][src 5]} Bip 101 was reverted^{[src 6]} and the 2-MB block size bump of Bitcoin Classic was applied instead.

The August 2015 release of XT received widespread media coverage. The Guardian wrote that "bitcoin is facing civil war".^[3]

Wired wrote that "Bitcoin XT exposes the extremely social — extremely democratic — underpinnings of the open source idea, an approach that makes open source so much more powerful than technology controlled by any one person or organization."^[5] Developer Adam Back was critical of the 75% activation threshold being too low and that some of the changes were insecure.^[6]

On August 25, 2017, Bitcoin XT published Release G, which was a Bitcoin Cash client by default.^{[src 7]} Subsequently, Release H was published, which supported the November 2017 Bitcoin Cash protocol upgrade, followed by Release I, which supported the May 2018 Bitcoin Cash protocol upgrade.

Bitcoin Classic

In its first 8 months, Bitcoin Classic promoted a single increase of the maximum block size from one megabyte to two megabytes.^[7] In November 2016 this changed and the project moved to a solution that moved the limit out of the software rules into the hands of the miners and nodes.^[8]

Bitcoin Unlimited

All three software clients attempt to increase transaction capacity of the network. None achieved a majority of the hash power.^[9]

Intended hard forks splitting the cryptocurrency

Hard forks splitting bitcoin (aka "split coins") are created via changes of the blockchain rules and sharing a transaction history with bitcoin up to a certain time and date. The first hard fork splitting bitcoin happened on 1 August 2017, resulting in the creation of Bitcoin Cash.

The following is a list of notable hard forks splitting bitcoin by date and/or block:

• Bitcoin Cash: Forked at block 478558, 1 August 2017, for each bitcoin (BTC), an owner got 1 Bitcoin Cash (BCH)
  • Bitcoin SV: Forked at block 556766, 15 November 2018, for each Bitcoin Cash (BCH), an owner got 1 Bitcoin SV (BSV).
• Bitcoin Gold: Forked at block 491407, 24 October 2017, for each bitcoin (BTC), an owner got 1 Bitcoin Gold (BTG)

Intended soft forks splitting from not-most-work block

• The fork fixing the value overflow incident was controversial because it was announced after the exploit was mined. It was assigned CVE-2010-5139.

Unintended hard forks

Two hard forks were created by "protocol change" definition:

• March 2013 Chain Fork (migration from BerkeleyDB to LevelDB caused a chain split)^[10]
• CVE-2018-17144 (Bitcoin 0.15 allowed double spending certain inputs in the same block. Not exploited)

References

Source code

Other references