I have already written about the false narratives of different parties vying for political control during a fork upgrade. Indeed it is the only time that the protocol can be changed substantially and as such hard forks attract politics of those who want to alter the protocol to benefit themselves. It is a side effect of the competitive nature of blockchains. That is why hard forks and chain splits should be avoided if at all possible. Sometimes (like the split of 2017 which gave birth to BCH) they are unavoidable (as Segwit was just unacceptable to some in the BTC community), but when they are, such as when the differences between the parties are not fundamentally incompatible, they should be avoided. This, it seems is the reason why the BCH upgrade of Nov has become contentious; the fact that one side believes that the protocol should not hard fork unless absolutely necessary, and should never split the ledger, while the other side believes that hard forks should be regular and often, new features should be put into the protocol, and that splitting the chain into new coins is acceptable.
Those 2 ideologies are not compatible.
So now we have the Bitcoin community split into 3 distinct sub-groups:
1) Those that believe that the coin should never split, and will sacrifice upgradability in order to ensure it, and are OK, with Segwit -- these are the original BTC supporters
2) Those that believe that the coin should never split, and will sacrifice upgradability in order to ensure it, and are NOT OK with Segwit, so a split was necessary -- These are the supporters of Bitcoin SV
3) Those that believe the coin can split if parties disagree on features, and new coins will just be created when such disagreement occurs -- These are the supporters of Bitcoin ABC
During the split that gave birth to BCH, Group 2 and Group 3 were united, (possibly for different reasons), so the BCH split occurred. But now that the second potential split is upon us, it is time to rationalize hard about what we want BCH to be. For any business that values continuity, splitting the ledger is a very painful and disruptive process, and materially discourages any serious use of the blockchain. But many devs feel that they want to improve upon the blockchain to compete with the other blockchain projects, because they feel that if they don't compete and fast, then some how businesses may be compelled to use a competing project.
So here we are. That is the summary of the contention points of the debate. Now, if a split were to occur, as a point of order, WHICH of the chains should inherit the BCH ticker symbol?
This is a decentralized system, there is no authority, so every business will be free to choose whichever one they wish to represent 'BCH' and give the other fork splits a different name. And yes, doing so will confuse the public. But that is the price we pay for decentralization.
I will go over some of the methods of coming to this decision which are wrong, and then suggest one which seems the best and fair.
1) Exchanges choose: This one seems to make sense because exchanges are what most people trade cryptocurrencies on in the first place. If the exchange is a fair and neutral exchange, they will withhold the name for the blockchain that has the most hashpower supporting it for the long term. That is the fairest way to decide. But unfortunately exchanges are run by people and some people may be unscrupulous, (especially on some of the non-regulated exchanges). Some may be taking 'personal donations' to give the BCH ticker symbol to one side summarily. This is very wrong as exchanges should not be in the practice of risking their customers funds, and if customers end up trading on a minority chain which can be erased due to hash attacks, then they will not be doing themselves or their reputation any favours.
2) Wallet providers choose: Again, this is a segment of the ecosystem which should really allow hashpower support to indicate which is the majority hashpower chain, and thus give that chain the BCH ticker. Doing otherwise shows political bias, and perhaps reliance on the falsity of basing the support of a blockchain on the 'Cult of Personality' fallacy that I defined in a previous post. Once again, the best bet is just to let the hashpower decide, as they are the only ones that are directly paid by the network, and thus have the most 'pure' incentives to support their vision of it.
3) The developers choose: By way of saying that the developer or group that created the client code that forked the coin should keep the ticker symbol of the coin they split. This method seems reasonable until you realize that this rule gets murky as development teams are dynamic and transient. What if the original team that created BCH has now fractured into several? Will each of the developers have a partial claim to the name? This is a problem legally.
4) The Coin with the highest price: This method relies on unscrupulous exchanges which wish to exploit the market looking to speculate on fork futures. They will claim that the coin future with the highest price should take the ticker name. This of course makes the least sense of all the choosing methods as it is the one with the most opportunity for manipulation via prices, especially in such as illiquid market as risky fork split futures.
5) Hashpower Chooses: this is the only real fair way of determining the chain with the most support, and thus, the chain that gets to keep the name. The only problem with this approach is that you will not be able to determine which one has the majority hashpower support until AFTER the fork occurs, making using the symbols troublesome before the fork.
6) Fork ID: This one is a pure technical way to determine which chain should inherit the ticker. Basically, when BCH split from BTC, in order to make the split clean, BCH developers added a fork ID to all transactions that they create. They also checked for the ID on txns and rejected any with the incorrect or missing ID. This was popularly named 'replay protection' because it prevented the 'replay' of a transaction on one chain, into the other. (BTC and BCH). This makes the split clean. In the case of a fork ID change, a new ticker was created for the one that changed the fork ID, and BCH was created. We can simply duplicated this logic this time around, the fork chain that uses the same Fork ID as the BCH chain did pre-Nov 15, can be called BCH, and any chain that changes the Fork ID, should be given a new ticker.
Great! Problem solved right? Well, not really because there actually potentially 2+ chains that will be using the original BCH fork ID, Bitcoin SV, Bitcoin ABC and what I will call Bitcoin Cash Classic. What is 'classic'? Well it is the hypothetical client which has the current clients built in Fork flag date of Nov 15th removed. Basically it is a modified client that WILL NOT FORK on Nov 15th. To understand how the hard fork works, you must understand that when the (present) ABC developers wanted to HF away from BTC, they embedded in the day (actually the block number, but don't worry about this, only geeks understand the difference) when the fork away from BTC will happen. But they went one step further. They embedded in the date when the NEXT hard fork would be scheduled. (May 2018) and on that HF, they embedded the next HF (Nov 15th) etc... No drama happened in May because there was not a splitting of the ideologies of the upgrade roadmap back then (or at least it was not as pronounced). But this time around, because of the debate, many have said that we should just put off the hard fork until some developer consensus can be reached. Therefore, it is possible that some miners out there have already done so, and want to promote the 'opt-out' no fork option. These nodes (if they do exist) will be using the original BCH fork ID, as well as SV and ABC.
So if you (as a business) wanted to use the method in which the least amount of people would be able to dispute, the you would use a combination of method #5 and #6, that is, give the BCH ticker to the chain which will be continuing to use the '0x40' fork ID, whichever of them has the most hashpower supporting it.


1 of 1 reviewers say it's worth paying for

0 of 1 reviewers say it's not worth paying for