The Principle of Simplicity Has Many Applications

In the Bitcoin Cash community, we have a simple goal that unites us: we want to create peer-to-peer electronic cash for the world. We also have a simple yardstick to measure the efficacy of the system: does it offer fast, cheap, and reliable transactions?

In the software world, it’s especially important to keep things simple whenever possible. Software development is a deceivingly difficult endeavor. Projects being over budget and past deadline is the norm.

Simple Blocksize Increase vs. Lightning Network

The perfect example of the power of simplicity is Bitcoin Cash’s approach to scaling the network. The Bitcoin BTC approach (SegWit plus Lightning Network) is extremely complicated and isn’t even ready 5 years later. It has a ton of issues — some solvable, and some apparently unsolvable.

Bitcoin Cash decided the simplest solution was best — increase the maximum blocksize limit, and it’s worked out great. Of course, there are a lot more technical changes that are required for global scale electronic cash, and we cannot blindly apply the principle of simplicity all the time, in all situations.

Case Study: Simple Ledger Protocol

It is not an accident that SLP has been adopted in Bitcoin Cash, rather than any of the 10 other token systems that were competing in 2018. Its raison d’etre was that the other proposals were overcomplicated.

SLP didn’t change the base BCH protocol because that would’ve added complications to BCH. It avoids fancy commitment schemes that would attempt to route around the requirement of full DAG validation. It has a minimal number of transaction types and rules.

It was made simple enough so that a team of coders was able to build a prototype wallet in 3 weeks, and also simple enough so that other developers could build an ecosystem around it.

Unified Mining Policies and 0-Conf

The unified policy isn’t just a “major factor” in 0-conf reliability. It is the very reason it works. It’s the simple solution that’s been working for years. Why? Because when you broadcast your transaction to the network, the goal is to have any node or miner accept it. Assuming your wallet follows the unified policy, you therefore know that every node and miner will accept it.

For those that wonder what motivates miners to all agree on the same policy, the answer is that it helps the coin, which helps the price, and helps mining profitability.

Maybe someday we’ll have something more sophisticated that might allow non-unified policies AND reliable 0-conf (Avalanche pre-consensus anyone?). But for now, in the absence of advanced technical solutions like that, traditional means of routing around the problem fall short.

For example, one developer proposed a policy of allowing transaction chains that are longer than the existing policy of 25, so long as the transactions that are greater than 25 only use a single input. The idea is to prevent double spending since you couldn’t combine those UTXO with a short-chain UTXO, which is the one you’d need to double spend in this case.

And it’s true — this indeed does prevent double spending. However, it doesn’t solve the unspendable coins issue and in fact makes it especially bad. In addition to users on a different policy having unspendable coins, even the users connecting to an “upgraded policy” node can’t spend their coins normally, and forces them to only spend a single UTXO at a time, which is a major hinderance.

So you end up with a complicated thing, and it doesn’t even solve the original problem it was setting out to solve, which was to spend coins freely without worrying about the limit. It’s like a game of whack-a-mole. You push the problem down in one area, it just pops back up in another.

All this complication just to get an inferior “solution”… because the obvious, simple, real, and proven solution of unified policies isn’t appealing or acceptable to certain people.