Following my article yesterday, I asked myself why so many people reacted badly to it (some even smearing it), and why it is so difficult to come to a consensus (as usual) when we were trying to discuss about the potential issues related to the use of coin splitters.
I think it's because my business (and so my standpoint) is data oriented, since we at use BCH transactions to transport metadata (proofs of referral, interest, deal etc.) while many others see BCH transactions as payments.
In fact, if you are concern about payments you don't care if you are losing coins that will have never made their way to an exchange and never hold values.
It's not the same for those who are concern about data transported (written as OP_RETURN instruction) by a BCH transaction.

Why splitting can be dangerous for our metadata

Let's take an example and say that a user of (or a bitdb or memo user) is introducing two other users for a business opportunity, then a proof of referral transaction UTXOr is sent to the BCH network.
If is selecting one and only one fork to push UTXOr (let's say ABC).
Then if this fork ends up loosing in the conflict and is abandoned by the miners or its protocol development team, voluntarily or forced to do so (see this thread with btcfork, Vin Armany and I), UTXOr will be lost and the metadata with it, which is critical for our business.
As a business and app developer, my goal is to not lose ANY of my transactions.
So it's obvious and straight forward for my business and all other businesses who are transporting metadata on their transactions that our choices are:
  1. to not split our coins and not use any of the new features to be automatically on both forks ensuring that we avoid all blacklisting strategies and not treating any incoming ABC/SV specific/tainted UTXO (the exchanges will even not handle any UTXOs);
  2. to split our coins but ensuring by all means that our transactions are all duplicated on SV and ABC ... and even the current mainchain (NayBC) if some miners continue to mine it.

No-one can dispute this vision, because it is 100% valid in a metadata based business point of view.
That's why Ryan, Vin and I are in agreement here.
In fact, we are running businesses that are relying on metadata like a bunch of the new BCH services that have been launched recently and we must be careful how we are going to transact or handle our transactions.
It's the reason why we released in early October to anticipate this crisis and give a tool that businesses like us can use.

Fork outcome

During the numerous discussions I had this week, a point kept coming back in a recurrent manner: "why do you think [X] outcome might happen, it absolutely cannot".
It's my role as a CEO and a business/app developer to analyze all the potential outcomes for my company and evaluate the risks of taking one particular approach or another.
So I am always thinking about as many scenarios as possible to try to take the best decision I can for my business, and my personal preferences must not count.
Here is the list of the potential outcomes regardless their probability to happen (which btw is never 0 whatever some strongly convinced people may say):
  1. ABC wins and SV is abandoned (voluntarily or forced)
  2. ABC wins and SV is forking away to create BSV coin
  3. SV wins and ABC is abandoned (voluntarily or forced)
  4. SV wins and ABC is forking away to create BAC coin
  5. SV and ABC comes to an agreement and both fork away adding different replay protections, creating BSV and BAC coins (with maybe a BCH coin remaining as well)
  6. SV and ABC comes to an agreement to fusion the rulesets (DSV + MUL +...)
  7. None of the chains survives due to a violent war and a inconsistent or unacceptable reorg (double spend, coinbase rewards trust etc.) and a rollback of the chain pre-fork is acknowledged.
  8. ... there are certainly other potential outcomes that I didn't think about yet, if you think about one comment or anchor me on Twitter and Reddit.

In my previous article, I analyzed essentially for the outcomes #1 / #3 / #6 and #7 how transacting with UTXOs produced by a coin splitter could lead to the loss of transaction history (again containing critical metadata for our system).
I advice you to do the same to prepare and try to anticipate the situation your business may face.

Wallets tainting

In some of the discussions on Reddit and on Twitter, people were constantly talking about contentious UTXOs tainting their other clean UTXOs within their wallets.
I would like to take the opportunity to clarify that mechanism because people have a tendency to freak out lately (myself included).
Let's start by a fact that everyone should keep in mind (I will quote some of my comments on Reddit):
A wallet is just a view on a node data which has the blockchain state in memory compatible with the ruleset of the software it runs.
Bitcoin wallets are not purses where your store your UTXOs inside and then they can be contaminate by tainted ones.

When you "receive" a SV specific UTXO in your wallet, it means that a new UTXO was added to the SV blockchain. This UTXO does not exist on the ABC blockchain.
So your wallet that is connected to work with ABC ruleset, will never see this SV UTXO...
In other words, threats like "I will send you a tainted UTXO to your wallet" are not valid technically , false and misleading statements by people who don't understand how Bitcoin works or try to create FUD.
Those could be valid only if a multi-ruleset node is implemented and that your wallet is connected to it. Those kind of nodes don't exist.
If you want to craft a transaction with a UTXO SV and a legacy pre-fork UTXO as inputs you can but it will be accepted only by SV nodes, not ABC ones, so your legacy pre-fork UTXO will be still valid on the ABC chain.
No tainting is happening here ... #FUD for me until proven otherwise.

Bold moves

I think that one of the boldest move that I saw was decision to side with ABC since Roger Ver has faith in the ability of ABC to ensure a bright future for BCH. And I encourage you to listen to his latest video in which he gives a pretty good analysis of the situation we will all have to face.
I can only salute the boldness of the decision, because has a voice that can be heard and this is a strong support signal for others. It's politically extremely valid.
On the technical side of the things, I am sure Roger and his teams are running through the different outcome scenario as well and already figured out what they will do in each case.
For us, small startups and solo app developers, our voice does not really count. We are too small, without power or any way to voice our opinion together as a whole. We are focused on making our own business operate smoothly during and after the #war.
I would like here to take this opportunity to propose to app developers the creation of a worldwide organization, that we could call BCHappdev or so, that would voice our requirements and positions in order to help reaching a consensus and avoid contentious forks like this one in the future.
What do you think about this proposal?

Disclaimer: I might be proven wrong in my analysis in the future so do your own research and follow closely the comments on this article (which I hope will be numerous) to forge your own opinion. Also don't try to smear me online, I am not sensitive enough to care.
Say ...
🙅‍♀️#war🙅‍♂️🙅‍♀️#war🙅‍♂️ 🙅‍♀️#war🙅‍♂️ 🙅‍♀️#war🙅‍♂️🙅‍♀️#war🙅‍♂️🙅‍♀️#war🙅‍♂️
🙅‍♀️#war🙅‍♂️ 🙅‍♀️#war🙅‍♂️ 🙅‍♀️#war🙅‍♂️ 🙅‍♀️#war🙅‍♂️ 🙅‍♀️#war🙅‍♂️
🙅‍♀️#war🙅‍♂️ 🙅‍♀️#war🙅‍♂️ 🙅‍♀️#war🙅‍♂️ 🙅‍♀️#war🙅‍♂️ 🙅‍♀️#war🙅‍♂️
🙅‍♀️#war🙅‍♂️ 🙅‍♀️#war🙅‍♂️ 🙅‍♀️#war🙅‍♂️ 🙅‍♀️#war🙅‍♂️ 🙅‍♀️#war🙅‍♂️
🙅‍♀️#war🙅‍♂️ 🙅‍♀️#war🙅‍♂️ 🙅‍♀️#war🙅‍♂️ 🙅‍♀️#war🙅‍♂️ 🙅‍♀️#war🙅‍♂️
🙅‍♀️#war🙅‍♂️ 🙅‍♀️#war🙅‍♂️🙅‍♀️#war🙅‍♂️ 🙅‍♀️#war🙅‍♂️ 🙅‍♀️#war🙅‍♂️
🙅‍♀️#war🙅‍♂️ 🙅‍♀️#war🙅‍♂️🙅‍♀️#war🙅‍♂️ 🙅‍♀️#war🙅‍♂️🙅‍♀️#war🙅‍♂️🙅‍♀️#war🙅‍♂️
... to the #war and pass the message to your peers!


No one has reviewed this piece of content yet