Bitcoin Cash Hard Fork Report
For more in-depth research on crypto assets, visit Circle Research and make sure to subscribe to receive our latest releases in your inbox.
Bitcoin Cash (BCH) will undergo a planned hard fork on November 15, 2018 at around 4:40PM UTC (11:40AM EST) or at UNIX time 1542300000. Bitcoin Cash is itself a hard fork of the Bitcoin blockchain. Bitcoin Cash (BCH) emerged from the part of the Bitcoin (BTC) community that believed too many changes were being made to the original Bitcoin vision in terms of SegWit and layer two scaling solutions such as Lightning network. This part of the community (now the Bitcoin Cash community) believed in scaling on chain by increasing the block size, for instance. Thus, Bitcoin underwent a hard fork in August 2017, resulting in BTC and BCH.
Now, the Bitcoin Cash community is facing another partition. BCH undergoes scheduled hard forks twice a year to implement network upgrades. The first planned hard fork took place in May 2018, increasing the block size limit to 32MB from 8MB. This time, the fork is contentious, given the community is faced with two competing proposals — one from Bitcoin ABC (the main BCH client) and one from Bitcoin SV (a new BCH client). The two implementations are incompatible. As a result, the upcoming hard fork could create a split in BCH, resulting in two different chains with two different tokens.
Bitcoin ABC published its proposal for the upcoming hard fork on August 8, 2018. This is considered the original roadmap of Bitcoin Cash from bitcoincash.org. A part of the Bitcoin Cash community did not agree with the changes proposed by Bitcoin ABC. They insisted that Bitcoin ABC’s proposal made unnecessary changes to what the original Bitcoin was intended to be. This part of the community includes crypto heavyweights such as cryptographer Craig S. Wright (self-proclaimed Satoshi Nakamoto) and his company, nChain, and Calvin Ayre and his mining pool, CoinGeek (the largest Bitcoin Cash mining pool, with 29% hashing power over the last seven days). In response, nChain announced the creation of Bitcoin SV (“Satoshi’s Vision”), a full node implementation of BCH, and published a new proposal for the upcoming hard fork on August 16, 2018.
Supporters of both communities have conflicting definitions of “economic freedom”, conflicting views on the purpose and future of Bitcoin, and conflicting ideas of what is needed to achieve that goal.
Bitcoin ABC proposal
The Bitcoin ABC community wants to make Bitcoin Cash more usable, nimble, and developer friendly by adding smart contract capabilities, layer two scaling solutions, oracles, etc. Mining pools backing Bitcoin ABC include Antpool (operated by Bitmain), BTC.com, Btc.top, ViaBTC, and Bitcoin.com. Crypto leaders backing ABC include Jihan Wu of Bitmain and Roger Ver of bitcoin.com.
The main changes proposed by Bitcoin ABC are as follows:
- Canonical transaction ordering, or CTOR, proposes changing the way transactions are ordered within a block such that the transaction id or hash with the lowest number appears first in a block and the transaction id with the highest number appears last. The reason for implementing CTOR is to optimize the software to scale on chain.
- OP_CHECKDATASIGVERIFY, OP_DSV, or DSV enables non-cash transactions and allows for the creation of decentralized applications (dApps).
- OP_CHECKDATASIG allows users to use oracles and import and validate messages from outside the blockchain. This is complementary to OP_DSV.
Currently, BTC and BCH use a low level programming language called Script. It is very challenging for developers to build applications using Script, and, as a result, they refrain from using it to deploy smart contracts. Additionally, clients explicitly disallow non-standard scripts. In response, Bitcoin ABC is in the early stages of developing a new high level programming language for Bitcoin Cash called Spedn. The changes implemented by Bitcoin ABC in the upcoming fork would allow Spedn to be more useful. This post by its lead developer outlines additional specs of Spedn.
Bitcoin SV proposal
The SV in Bitcoin SV stands for Satoshi’s Vision. Mining pools backing Bitcoin SV include CoinGeek, BMG, and SVPool. Crypto leaders backing SV include Craig S. Wright and Jimmy Nguyen of nChain and Calvin Ayre of CoinGeek.
The Bitcoin SV community believes it is fulfilling the original promises of Bitcoin versus other implementations they claim are making unnecessary changes to the original Bitcoin protocol. Bitcoin SV’s proposal is as follows:
- Increase the maximum block size to 128MB (from 32MB), as the SV community believes the original Bitcoin whitepaper placed no limit on the block size.
- Restore original Satoshi opcodes from version 0.1¹.
- Remove the limit of 201 opcodes per script.
In summary, the changes proposed by Bitcoin ABC aim to scale Bitcoin Cash using layer two solutions and optimization, make Bitcoin Cash more usable and open doors for smart contract development on Bitcoin Cash. The Bitcoin SV camp, on the other hand, is more conservative and views these changes as unnecessary and illegitimate.
This time is different
While contentious forks can be nasty, the ideological debate surrounding this fork has turned the situation into a much nastier fight than we’ve seen before. In prior hard forks, such as BTC vs BCH or ETH vs ETC, the communities eventually agreed to disagree and coexist. In this instance, while it seems that Bitcoin ABC is open to such an outcome, Bitcoin SV is taking a much more aggressive stance.
Why? Because the Bitcoin SV community believes that ABC is destroying Bitcoin’s “original vision” by implementing changes such as DSV and CTOR, which make the ABC implementation “invalid” and “illegal”. As a result, the Bitcoin SV community feels justified in taking action against ABC because they believe they are defending Bitcoin from Bitcoin ABC. Action includes nullifying replay protection or threatening to attack Bitcoin ABC (or what they consider to be the illegitimate chain), if two chains emerge from the hard fork².
No replay protection
The Bitcoin SV community believes that there should only be one chain — the chain that uses Bitcoin SV’s full node implementation. While Bitcoin ABC attempted to implement replay protection, Bitcoin SV has said it will take actions to nullify this protection.
In the event of a hard fork that results in two chains, a user receives an equal amount of tokens on each chain. If a user has 1 BCH prior to the fork, she will now have 1 BCHABC and 1 BCHSV³. In order to implement replay protection, developers can change the transaction format on chain A to be incompatible with the transaction format on chain B. This makes the fork cleaner and prevents the transaction on chain A from “replaying” on chain B. Without replay protection, the user is susceptible to a replay attack: if user A sends 1 BCHABC to user B, anyone can cause an equivalent amount of BCHSV to go to user B from user A, without her intending to do so (situation X). Similarly, if user A sends user B 1 BCHSV, anyone can cause user A to send user B 1 BCHABC (situation Y).
Bitcoin ABC began publicizing that users could use the opcodes from its upgrade to prevent situation X. If user A includes one of the new opcodes (OP_DSV or OP_CHECKDATASIG) in her transaction of BCHABC to user B, then that transaction would no longer be valid on the BCHSV chain (because the opcodes don’t exist), so it couldn’t be replayed. BCHABC effectively replay-protected both situation X and Y.
However, BCHSV has said it could counter this by adding the same opcodes to BCHSV. If it chooses to do so, the transaction could be replayed on BCHSV. However, Bitcoin SV has a different intention: if a transaction uses the aforementioned opcodes, they will give all of the BCHSV in that transaction to the first miner to include it in a block as a miner fee.⁴
This has two effects: (1) It nullifies the replay protection implemented by BCHABC, since if A includes one of the new opcodes in her send of BCHABC, then the transaction can be replayed to “steal” that amount of A’s BCHSV (2) It causes any BCHABC transaction using the new opcodes to cost the user an equivalent amount of BCHSV. This is an aggressive move by Bitcoin SV to prevent users from using Bitcoin ABC. Their reasoning for doing so is that they view the opcodes proposed by Bitcoin ABC as invalid and illegal.
“If and when the dishonest miners on the BCH(ABC) chain seek to send an invalid OP_CODE to split the chain, they are really giving away any money they have on the BCH(SV) chain to the miners that are mining on the BCH(SV) chain. That is, the dishonest miners/attackers would need to subsidise the honest miners seeking to maintain the original Bitcoin protocol. This incentivises miners to mine on the BCH(SV) chain.” — Craig S Wright
Mining empty blocks
The Bitcoin SV community has also indicated willingness to devote hashpower to mine empty blocks on Bitcoin ABC if the planned hard fork results in two separate chains. The impact of mining empty blocks on ABC is that it increases congestion on the network and prevents legitimate transactions from being confirmed. If Bitcoin SV miners have 30% of the hashpower, they can find 30% of the blocks, which they can mine as empty blocks. If they have over 51% of the hashpower, the move could be much more destructive (i.e. Bitcoin SV could reject all transactions using the Bitcoin ABC opcodes, which would make the chain unreliable, prevent users from using the chain, and negatively affect the value of the chain and its token).
In response to this threat, a Bitcoin ABC developer suggested preparing a last resort “nuclear option” that would change the hashing algorithm from the current SHA-256. This would make it very expensive for Bitcoin SV miners to attack the chain as they would have to purchase new hardware capable of solving the new algorithm. However, it could be just as difficult and expensive for Bitcoin ABC miners to mine blocks on their chain unless they switch to an algorithm that ABC miners (specifically Antpool) could solve, but that SV miners could not⁵.
These are potential actions that have been discussed in both communities, but it is still too early to know if Bitcoin SV will indeed employ these tactics and what action Bitcoin ABC will take in response.
Stance of major exchanges
Over the past few weeks, major exchanges have expressed their stance on the debate and support for the hard fork. While the majority of exchanges have expressed support for the original roadmap outlined on bitcoincash.org (aka the Bitcoin ABC implementation), multiple exchanges have said they will take a snapshot of customer balances prior to the fork and plan to monitor the situation. This means if the fork results in two distinct chains and there is strong market demand for BCHSV, major exchanges and wallets could eventually roll out support for it, even if they don’t initially offer support for it. This is similar to the situation in August 2017 with the Bitcoin and Bitcoin Cash fork.
Poloniex launched pre-fork trading of BCHABC and BCHSV tokens on November 8 to allow the community to decide which chain to support. HitBTC and Bitfinex followed suit and launched pre-fork trading on November 10 and 13, respectively.
Volumes on Poloniex started off light but have been steadily increasing. Initially, on November 9, the closing price of the BCHABC token was over seven times as high as the price of the BCHSV token, indicating greater market support for BCHABC. Since, the gap has steadily narrowed day by day. As of November 14, the price of BCHSV is almost as high as the price of BCHABC, implying that support for one chain isn’t significantly stronger than support for the other.
Stance of major mining pools
According to coin.dance estimates (based on current hash rates), 15% to 26% of Bitcoin Cash miners are backing the ABC implementation and 73% to 76% of Bitcoin Cash miners are backing the SV implementation, indicating support for SV seems to be much higher⁶. However, it’s unclear if this many miners will actually update their software.
Community/wallet/exchange support for an implementation will not alone determine the outcome of the fork. Neither will hashpower devoted to each proposal, though these two factors work hand in hand and are likely two of the main factors in determining the outcome. However, there are many additional unknowns at this stage. A few key questions include:
- How many miners will actually upgrade to each implementation (ABC and SV) — i.e. what will be the hashpower devoted to each chain following the fork?
- If SV emerges as the chain with greater hashpower, and there is customer demand, will exchanges and wallets offer support for it, particularly exchanges and wallets that have publicly committed to only supporting Bitcoin ABC?
- If ABC emerges as the chain with the greater hashpower devoted to it⁷ or any hashpower devoted to it, will SV employ the tactics it has mentioned (replay attacks, mining empty blocks) or will the SV community allow the chains to co-exist?
- If SV uses its tactics, will ABC deploy its “nuclear option” — i.e. changing the hashing algorithm? If it does, will Bitmain divert resources from mining other coins with this hashing algorithm to ABC?
- If the situation turns out to be unstable and insecure, for how long will exchanges and wallets suspend deposits and withdrawals?
- Does this set precedence for future hard forks to be this contentious or is this situation the exception?
It is possible that two coins are created, but it is unclear which coin would retain the Bitcoin Cash name and ticker. If two coins are created, it is unclear how the Bitcoin ABC/Bitcoin SV communities and exchanges/wallets will respond. It is also possible (though a lot less likely) that at the time of the fork, all Bitcoin Cash miners devote their hashpower to a single chain, either Bitcoin ABC or Bitcoin SV. This survey by CoinDesk Markets shows the market’s uncertainty on the upcoming fork:
While this report scratches the surface, we wanted to shed some color on the origins of the debate and context behind the upcoming BCH hard fork, and the unanswered questions that may affect the potential outcomes of the upcoming fork.
For more in-depth research on crypto assets, visit Circle Research and make sure to subscribe to receive our latest releases in your inbox.
¹ OP_MUL, OP_LSHIFT, OP_RSHIFT, OP_INVERT — these original opcodes enable smart contracts and allow users to perform different operations on Script, but the experience is not as developer friendly.
² Thanks to Jack Liu for the explanation, 11/12.
³ We are using BCHABC and BCHSV for now since we don’t know which one will be referred to as BCH.
⁴ 11/19 Update: Bitcoin SV has not implemented OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY as OP_MINER_REDIRECT1 and OP_MINER_REDIRECT2, that would allow them to redirect the outputs to miners. Thus, transactions that use these opcodes on the Bitcoin ABC chain are not currently replay-able on the Bitcoin SV chain.
⁵ Thanks to Marcus Boorstin for the explanation, 11/14.
⁶ As of 11/15 at 9AM ET.
⁷ A chain that has less hashpower devoted to it can still continue to exist. A chain only ceases to exist if it has no hashpower devoted to it.
This report has been prepared solely for informative purposes and should not be the basis for making investment decisions or be construed as a recommendation to engage in investment transactions or be taken to suggest an investment strategy in respect of any financial instruments or the issuers thereof. This report has not been prepared in accordance with the legal requirements designed to promote the independence of investment research and is not subject to any prohibition on dealing ahead of the dissemination of investment research under the Market Abuse Regulation (EU) No 596/2014. Reports issued by Circle Internet Financial Limited (“Circle”) or its affiliates are not related to the provision of advisory services regarding investment, tax, legal, financial, accounting, consulting or any other related services and are not recommendations to buy, sell, or hold any asset. The information contained in this report is based on sources considered to be reliable, but not guaranteed, to be accurate or complete. Any opinions or estimates expressed herein reflect a judgment made as of the date of publication, and are subject to change without notice. Trading and investing in digital assets involves significant risks including price volatility and illiquidity and may not be suitable for all investors. Circle’s affiliate offered trading in the digital assets that are the subject of this report prior to the fork. Circle and its affiliates trade and hold positions in digital assets and may now or in the future trade or hold a position in the asset that is the subject of this report. In addition, employees and other associated persons may trade and hold positions now or in the future in the asset that is the subject of this report. As a result, Circle, its affiliates, and its employees or other associated persons may be subject to certain conflicts of interest in connection with the provision of this report. Circle will not be liable whatsoever for any direct or consequential loss arising from the use of this Information.
Note: Bitmain is an investor in Circle Internet Financial, Inc.