Bitcoin XT

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". 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. 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." On December 27, 2014 Hearn released version 0.10 of the forked client XT, with the BIP 64 changes. It achieved significant attention within the bitcoin community in mid-2015 amid a contentious debate among core developers over increasing the block size cap.

: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. The new maximum transaction rate under XT would have been 24 transactions per second.

:On August 6, 2015 Andresen's BIP101 proposal was merged into the XT codebase. Bip 101 was reverted 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".

:''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." Developer Adam Back was critical of the 75% activation threshold being too low and that some of the changes were insecure.

:On August 25, 2017, Bitcoin XT published ''Release G'', which was a Bitcoin Cash client by default. 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. 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.
; Bitcoin Unlimited
All three software clients attempt to increase transaction capacity of the network. None achieved a majority of the hash power.

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).
** eCash: Forked at block 661648, 15 November 2020, for each Bitcoin Cash (BCH), an owner got 1,000,000 eCash (XEC).
* 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 a not-most-work block

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

Intended soft forks splitting from the most-work block

Segwit

Taproot

Taproot is an agreed soft fork in the transaction format. The fork adds support for Schnorr signatures, and improves functionality of smart contracts and the Lightning Network. The fork was installed in November 2021. The upgrade adds privacy features. Taproot includes Bitcoin Improvement Proposal numbers BIP340, BIP341, BIP342.

Advantages:
* Complex transactions, such as those requiring multiple signatures or those with delayed release, are indistinguishable from simple transactions in terms of on-chain data.
* Reduced transaction costs: The data size of complex Bitcoin transactions is reduced, which leads to lower transaction fees.
* Support for more complicated conditions for a transaction via Schnorr signatures.
* Benefits for the Lightning Network: More flexibility, privacy enhancement, lower costs.

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)March 2013 Chain Fork
/ref>
* CVE-2018-17144 (Bitcoin 0.15 allowed double spending certain inputs in the same block. Not exploited)

References

Source code

Other references

{{DEFAULTSORT:Bitcoin forks
*
Computing-related lists
Clients (computing)
Cryptocurrencies