Why your Bitcoin will be safe when ‘Bitcoin Cash’ is released

On August 1st at 12:20 UTC a new cryptocurrency called Bitcoin Cash will be launched. It’s based upon Bitmain’s UAHF proposal which was initially created as a contingency plan to thwart the efforts of the UASF, which now looks likely to activate without incident.

Whilst the arrival of another cryptocurrency derived from Bitcoin’s source code is not newsworthy in itself, the fact that Bitcoin Cash shares a common transaction history (blockchain) with Bitcoin has raised its profile somewhat.

This shared transaction history exists because instead of creating a new ‘Genesis block’ (as Litecoin did) Bitcoin Cash is being activated by hard forking the existing Bitcoin blockchain.

We’ll examine the motivation behind the hard fork and look at how the risk of ‘replay attacks’ — where transactions can be sent and processed on different blockchains — has affected the proposal’s development. We’ll also see how the latest incarnation of the code will protect users from accidental transfer of both Bitcoin and Bitcoin Cash.

8 MB blocks added, Segwit removed

Bitcoin is on its way to a block capacity increase courtesy of Segwit activation. Segwit itself will enable solutions such as Lightning Network to bring massive, non-linear second layer scaling to Bitcoin.

The team behind Bitcoin Cash have decided to remove all Segwit related code from their proposal, preferring instead the linear scaling option of block size increases to expand the transaction capacity of their network.

The proposed hard fork to an 8 MB block size is set to have many client implementations. The first of these to be released is named “BitcoinABC”. Other compatible implementations are being worked on by the teams behind “Bitcoin Unlimited”, “Bitcoin XT” and “Bitcoin Classic”. All will conform to the protocol specification set out by the UAHF proposal.

The very short timeline for UAHF compatible client development is a reaction to the UASF’s own August 1st activation date. This has raised concerns over the quality of the client code being developed, something that plagued the “Bitcoin Unlimited” project earlier this year.

There is currently very little hash rate that has been publicly committed to the hark fork — the only pool currently supporting it is ViaBTC’s BCC pool which has just a quarter of a percent of global hash rate. In order to keep mining viable in the event of varying levels of support, the developers have introduced a way to rapidly adjust the difficulty of the algorithm used to mine blocks on the Bitcoin Cash chain.

The number of exchanges and wallets announcing some form of compatibility has grown noticeably over the last few weeks. The supporters of Bitcoin Cash have been keen to announce this as positive news and an indication of support for their approach to scaling. This view doesn’t seem to be shared by the wider Bitcoin community, who view exchange support as a reaction to customer demands to be able to sell their ‘air-dropped’ Bitcoin Cash when the split occurs. Many exchanges, perhaps most notably Coinbase, have decided to not list the new cryptocurrency at all.

“ We have no plans to support the Bitcoin Cash fork. We have made this decision because it is hard to predict how long the alternative version of bitcoin will survive and if Bitcoin Cash will have future market value.” — Coinbase July 27th.

Anyone holding Bitcoin on an exchange that does not intend to allocate the corresponding amount of Bitcoin Cash to their customers will lose the ability to later move or trade that Bitcoin Cash. If you want to be absolutely sure that you have access to all the Bitcoin Cash that you currently hold as Bitcoin you will have to either move your Bitcoin to a private wallet or move them to a trusted exchange that offers Bitcoin Cash account crediting.

The actual level of support for Bitcoin Cash will be seen on August 1st when supporting exchanges open for Bitcoin Cash trading.

Whether to use Bitcoin Cash or not is a choice for individual users to make. They may wish to ignore it, move to it wholeheartedly, only be interested in trading it or prefer to let things play out before making a decision. Because both chains share a transaction history a risk arises for those who prefer the latter two options.

That risk is due to something called ‘transaction replay attacks’ and we will look at this in more detail next.

The risk of transaction ‘replay’ attacks.

As the new cryptocurrency will inherit the transaction history of Bitcoin, any Bitcoin that a user currently holds will be represented within the new coin’s block chain.

However many Bitcoin you hold prior to Bitcoin Cash activation you will end up holding the exact same amount of Bitcoin Cash after the fork has occurred.

A poorly managed split of the Bitcoin blockchain leaves users of either chain open to having transactions sent on one network being broadcast and processed on the other, potentially without their knowledge or consent. Such an occurrence is called a ‘replay attack’. It is something that led to a detrimental outcome for some users following the Ethereum hard fork in 2016.

In order to address the concerns of existing Bitcoin users, and to prevent the movement of coins on one chain being replicated on the other, something called ‘replay protection’ was added to Bitcoin Cash.

This initially took the form of a change to the Bitcoin Cash code to include a special OP_RETURN value — effectively creating a new transaction type that would not be valid on the legacy Bitcoin network. What this did notdo was prevent transaction from the Bitcoin network being replayed on the Bitcoin Cash network. The replay protection was therefore only ‘one way’.

After listening to feedback from miners, payment processors and merchants, the Bitcoin Cash team have since decided to include a change that makes transactions on eithernetwork invalid on the other. This is called ‘strong replay protection’ or ‘two way replay protection’.

“After hearing feedback from users, exchanges, and wallet providers, developers of several Bitcoin Cash implementations have agreed to implement strong two-way replay protection.” — www.bitcoincash.org

Strong, two way replay protection has been implemented with the introduction of a new SIGHASH_FORKIDflag to Bitcoin Cash, which is invalid within Bitcoin (as so will be rejected) but required by miners processing transactions on Bitcoin Cash.

The new ‘two way’ replay protection ensures that Bitcoin Cash miners will not be able to mine Bitcoin transactions on the Bitcoin Cash network and also that Bitcoin Cash transactions will not be seen as valid on the Bitcoin network. Transactions on both chains will be technically independent of each other. This applies to all transactions — so transactions that move coins from addresses created before and after the fork will be protected.

The net effect of this most recent change is that when Bitcoin Cash performs its hard fork, and leaves the Bitcoin network, the users of both cryptocurrencies will find themselves with equal amounts of coins on both chains and free to transact without the risk of their actions on one chain having an effect on the other.

As we approach the activation of Segwit on Bitcoin it is now up to the community to judge whether the ‘big blocks, no Segwit’ scaling path Bitcoin Cash has chosen is as essential to success as its supporters so vehemently claim.