The upcoming Bitcoin Cash (BCH) hard fork on November 15 will likely cause two branches of the blockchain to exist, at least temporarily. Some actors believe both branches will persist, effectively creating two “coins.” Other observers believe that one chain will die off with the alternate “coin” simply becoming unusable, and leaving a single “coin” once everything is resolved. Regardless of the final outcome, any coins that exist prior to the hard fork will exist on both branches whilst they remain viable.
If a user only does standard transactions with these old coins, the transactions will happen on both branches and wallet contents will remain the same. However, there is a practice being advocated called “coin splitting” which taints coins on one branch with inputs unrecognised on the other branch which effectively severs the connection between coins on either branch.
For the unskilled, this practise is fraught with peril. Even for highly skilled engineers, it is risky and must be tested extremely carefully before using it with live coins. There are several methods that can be used and many permutations of each given the combinations of differing rulesets on each chain, the use of P2SH versus bare scripts and the various quirks of how and when transactions are rejected by a node. There is a VERY high risk of making coins un-spendable on at least one chain using these techniques, rendering the coins burned.
Recommendations:
1. For users and coin holders, the safest way to deal with your coins during the hash war period is simply to have them in a wallet you control and do nothing. After it is resolved, your coins will still be there on whichever chain survives.
2. Do not assume that exchanges will split your coins safely for you. A hard fork without replay protection is a rare scenario and there are many consensus rules unique to this scenario that must be accounted for. Mistakes can happen even on exchanges.
3. Do not use op codes to split coins (e.g. OP_CHECKDATASIG, OP_MUL). The rules around when and if transactions containing these op codes are accepted or rejected are complex and have subtle differences on each chain. The intended goal of this is to create a transaction that will be rejected by one chain leaving two different coins on each chain. However, It is entirely possible (even easy) to create a transaction spending to outputs containing these op codes that will be accepted by both chains. Once this happens, the coins will exist on both chains but be unspendable and effectively burnt on one chain.
4. Exploitation of unexecuted branches of script code to hide illegal op codes from the interpreter should not be assumed to be safe. Not only are these tools needlessly complex and prone to error. There is also an inconsistency in behaviour between disabled versus new op codes that will likely be resolved at a later date. If this is done it will not be retrospective however the proliferation of tools using this technique exacerbates the risk of people using them unwittingly at a later time.
5. If you must attempt to split coins or build tools for others to do so, the safest way is to mix your coins with an input that does not exist on one chain. The most likely source of these single chain inputs is coins mined after the chains diverge as they can only exist on one chain.
