Bitcoin Cash will fork into two new coins, BCHSV and BCHABC, around November 15. Currently, BCHABC is projected to be about four times as valuable as BCHSV, despite BCHSV projecting to start out with twice as much hashrate as BCHABC. The difference between these two is that BCHABC is being supported by most major exchanges and merchants, while more and more mining pools are claiming that they will mine BCHSV at a loss.
This absurd starting situation, where there could be at an 8-16x profitability increase in SHA-256 mining for a period of time, is something that we will make sure to take advantage of. Unlike with previous forks, Chris will be awake regardless of the time that this fork occurs so that we can immediately begin mining to take advantage of this huge imbalance.
Here is what you need to know:
- The coin currently called "BitcoinCash" will be discontinued at the time of the fork. All static coin miners currently mining Bitcoin Cash will be disconnected from the mining servers. To avoid this from happening to you, enable dynamic mining or statically mine a different coin before November 15.
- Sometime within 24 hours of the fork, all customers with BCH balances will be credited an equal amount of two new coins, "BitcoinCashSV" and "BitcoinCashABC."
- All miners with payout proportions of Bitcoin Cash will see that payout proportion redistributed equally across the two forks. Those earning 33% bitcoins and 66% BCH will now see their proportions read 33% bitcoins, 34% BCHSV, and 33% BCHABC. These customers will begin earning an equal amount of both coins immediately at the time of the fork. If you don't wish to earn both coins, then you can later remove the one you don't want to earn, or you can remove Bitcoin Cash from your payout proportions before the fork occurs so that the automated distribution is not applied to your account.
- The system will begin mining both coins immediately beginning at the fork block and converting mined blocks to the payout coins, taking advantage of the expected mismatch between price and difficulty.
- If you want to use mining power to support one of the forks, then you can use the password argument "c=bitcoincash[whatever]." This will earn you less money than omitting the "c=" password argument.
- If you want to drive down the price of the fork you don't support, and make less money by not mining the most profitable coin, you can use password argument "c=bitcoincash[whatever]" and elect 100% payout proportions in the other fork.
- If exchanges lock their wallets for one of the forks, and we have not found enough blocks in that fork, then payouts for that fork will be delayed until we can withdrawal the debt that we owe to customers. Exchanges frequently lock wallets when forks occur. Be aware of this possibility, because it is out of our control.
You can use us to prevent replay attacks
Finally, payout addresses will be duplicated for both forks for those who have addresses entered. If you are currently earning Bitcoin Cash, you will see two rows with the same address.
Replay attacks are a way that anyone can steal money from your wallet when you spend it. You can use our payout system to safely protect a wallet from replay attacks. Just wait until you receive payouts on one of the forks. Then, in your wallet software, send the entire balance of the wallet to yourself on that network. It is not necessary to send money to yourself on the other network. You must send the entire balance of the wallet, not just a small portion of it. Sending part of the balance will provide no protection.
In the Bitcoin ABC client, for example, you can call ./bitcoincash-cli getbalance to get the full balance, after waiting for six confirmations. Then, ./bitcoincash-cli sendtoaddress [your wallet address] [amount returned from getbalance - 0.000001 to account for fees)]. Then wait for six confirmations and you are protected on both networks forever after, despite not having sent a transaction on the other network.
After you've sent the entire balance, any future transactions you send from the wallet will not be subject to replay attacks, which could have resulted in losing your money in the other fork. You are also protected against replays from the initial full-wallet send, which is complex to pull off without using this method.
