{"id":1725,"date":"2018-11-14T18:27:23","date_gmt":"2018-11-14T18:27:23","guid":{"rendered":"https:\/\/bitcoinsv.io\/?p=1725"},"modified":"2020-09-28T05:13:17","modified_gmt":"2020-09-28T05:13:17","slug":"bitcoin-sv-notice-to-cryptocurrency-exchanges-wallet-service-providers-advisory-about-bch-protocol-upgrade-and-coin-splitting","status":"publish","type":"post","link":"https:\/\/bitcoinsv.io\/2018\/11\/14\/bitcoin-sv-notice-to-cryptocurrency-exchanges-wallet-service-providers-advisory-about-bch-protocol-upgrade-and-coin-splitting\/","title":{"rendered":"Bitcoin SV Notice to Cryptocurrency Exchanges, Wallet & Service Providers: Advisory about BCH Protocol Upgrade and Coin Splitting"},"content":{"rendered":"

We recently received inquiries from several cryptocurrency exchanges about the upcoming November 15 Bitcoin Cash (BCH) protocol upgrade and the role played by Bitcoin SV. There appears to be confusion by some exchanges and other cryptocurrency service providers about Bitcoin SV, perhaps caused by misleading statements made by supporters of other competing BCH implementations (such as Bitcoin ABC).<\/p>\n

We provide a Coin Splitting Advisory, which cautions against risks of immediately splitting BCH coins into BCH-SV and BCH-ABC coins until the contentious BCH upgrade is resolved.<\/p>\n

In addition, although we previously issued a notice on November 5<\/a>, we again answer questions about Bitcoin SV to clear up any remaining possible confusion.<\/p>\n

What is Bitcoin SV?<\/strong><\/p>\n

Bitcoin SV<\/strong> is a new full node implementation for Bitcoin Cash (BCH). We are not intending to create a new Bitcoin variant or token. We are not asking exchanges to list a new Bitcoin SV or BSV token.<\/p>\n

Instead, Bitcoin SV gives BCH miners another choice for consensus rules they wish to see implemented in Bitcoin Cash (competing with rule sets offered by Bitcoin ABC, and other existing BCH implementations). As set forth in the original Bitcoin white paper, it is up to miners\u2019 voting with their hash power (the Nakamoto consensus mechanism) to decide rules for the network.<\/p>\n

How Much Miner Hash Supports Bitcoin SV?<\/strong><\/p>\n

Bitcoin SV has now crossed well over majority support of total BCH mining hash. According to data on Coin.dance<\/a>, as of November 14, it is estimated that 72-78% of total BCH network hash power supports Bitcoin SV, compared to 12-22% support for Bitcoin ABC. (ABC is tied for 3rd place with Bitcoin Unlimited, which is remaining neutral and is compatible with both SV and ABC). This means Bitcoin SV stands a strong chance of becoming the dominant implementation for BCH.<\/p>\n

Coin Splitting Advisory<\/h3>\n

We have seen that some exchanges and other service providers are discussing plans to split BCH coins into BCH-SV and BCV-ABC coins. The following caution is offered to actors in the Bitcoin Cash space who are intent on splitting coins. There are numerous techniques to do this with various levels of complexity and many carry a very high risk of making coins unspendable.<\/p>\n

Recommendations:<\/strong><\/p>\n

1. For users and coin holders, the safest way to deal with your coins during the BCH 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.<\/strong><\/p>\n

2. 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.<\/p>\n

3. Exploitation of unexecuted branches of script code to hide illegal op codes from the script 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.<\/p>\n

4. 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.<\/p>\n

Additional Advisory<\/h3>\n