To read in Chinese click here.
When Bitcoin split into two chains in August of 2017, it did so because the original roadmap for Bitcoin was hijacked, and there existed an economic pressure to see the fulfilment of the original vision. This economic pressure not only resulted in the rebirth of Bitcoin in BCH but was also the cause of the sudden increase in value among numerous cryptocurrencies, which we have collectively come to refer as “alt-coins.” The fact that BTC’s congested chain ‘helped’ the market cap of many of these alt-coins is rather difficult to dispute. Certainly, the timed correlation of events between BTC blocks ‘becoming full’ (therefore limiting BTC usage), and having transactional utility (and market cap) grow in alts cannot be overlooked.
Original Bitcoin doesn’t mean that we need to strip back a hundred thousand lines of code to go back to the original three thousand lines Satoshi had in his first release. It is the design concept. That is—simple, electronic cash.
I say simple because simplicity is a fundamental key to a secure, stable system. Every hardened software engineer with years of experience under their belt knows precisely what this means. Certainly, the vast majority of security researchers understand this. Complexity is no friend to security.
ABC’s controversial ordering change CTO, and subsequently, CoinGeek and nChain’s move to create a competing client designed to continue in the restoration of the original Satoshi implementation, have caused the Bitcoin BCH ecosystem to become divided.
Such division within a decentralized system is not only possible but bound to happen. And almost certainly, there will be many repeats of divisions of this nature.
Roger Ver, CEO of Bitcoin.com, recently pointed out this very fact during a live debate with Bitcoin Core’s Jimmy Song. The division within BCH is evidence that teams have to fight and invest to have their preferred client decide the rules of consensus. There is no leadership, and this is why the struggle is real. Amusingly in this very debate, we did see a very confident Jimmy Song who started out his debate by reading from a script, slowly become relegated into a mumbling mess by the end of it. I digress.
No matter what outcome in November, one team will get their way, and the other team, sadly, will not. But BCH development will continue. And assuredly, another challenge will come from another competing client at some point. There is a reason we call these “competing” clients. At some point, they intend to mount some challenge over the code.
Locking down the protocol
CoinGeek and friends have already stated that they wish to “lock down the protocol.” This has received some mixed, some positive, and some violent opposition. I want to address the meaning behind this statement, and the motivation.
Firstly, let’s do away with the rumours. Locking down the protocol translates to a desire for a stable protocol that does not change at the whim of every developer. It does not in any way, mean that the protocol must not change under any circumstance. Such a move would be very foolish.
So what changes are welcome?
Two words: risks & opportunities. Over time, coders, testers, and well-meaning individuals may very well find and disclose vulnerabilities. Depending on the criticality of an issue, a change may be executed rather quickly.
Opportunities on the other hand need to be evaluated more critically. Unlike risks, opportunities do not present a ‘ticking time-bomb,’ and can afford the luxury of considerable time, research and testing.
Stability of code is mightily important when dealing with security. In fact, numerous studies have already confirmed the long-suspected correlation between complexity and security reduction.
CoinGeek is not closed to protocol improving opportunities. But CoinGeek does believe in employing stringent measures on any change that is not deemed a fix to an underlying vulnerability. These stringent measures involve questions such as:
- Can the current suite of opcodes achieve the same desired output?
- Does the function proposed affect the cash use case in any way?
- Does the function affect the network topology?
- Does the function affect the inbuilt incentives of the system?
- Can we achieve a similar function safely in any other way?
These are some of the questions that CoinGeek would like to see sufficiently addressed before considering opportune changes to protocol. Further, there needs to be a substantial benefit without introducing any risk.
Why these measures?
nChain’s Dr. Wright, stating that the protocol needs to be stable isn’t some misplaced comment. It is a sound, research-backed position that a vast majority of security researchers agree with.
Bruce Schneier, a respected cryptographer and security researcher, who’s written volumes of information on the subject, concludes: “complexity is the worst enemy of security.”
The bigger a program, the bigger the attack surface. At least, that’s how the correlated graph goes. There are a number of reasons for this. A research paper from McCabe titled “More Complex = Less Secure: Miss a Test Path and You Could Get Hacked” lists the following points as key reasons:
- Complex systems have more lines of code and therefore security bugs.
- Complex systems have more interactions and therefore more security bugs.
- Complex systems are harder to test and therefore, more likely to have untested portions.
- Complex systems are harder to design securely, implement securely, configure securely and use securely.
- Complex systems are harder for users to understand.
This is actually a key reason why Ethereum has suffered so many hacks, from the DAO hack (which resulted in the theft of 15% of all Ether in circulation at the time) to the parity freeze which saw half a million Eth frozen. Ethereum sure is powerful… It is Turing complete, enables us to create practically any application on-chain, but also has drawbacks in scalability, usability, and importantly, security.
Bitcoin has over 100,000 lines of code. Ethereum on the other hand has well over a million lines of code. Given the complex architecture of, not just Ethereum itself, but of the smart contracts built on top of it, it is no wonder that Ethereum’s strength, is also its weakness.
In a post titled ‘A Plea for Simplicity’ Schneier once wrote:
“We’ve seen security bugs in almost everything: operating systems, applications programs, network hardware and software, and security products themselves. This is a direct result of the complexity of these systems. The more complex a system is–the more options it has, the more functionality it has, the more interfaces it has, the more interactions it has–the harder it is to analyse. Everything is more complicated: the specification, the design, the implementation, the use. And everything is relevant to security analysis.”
Many developers overlook the significant importance of testing. Many will test various functions, and run simulations across a range of inputs. Rarely is every path tested. And rarely do some testers ever even look at binary analysis.
Every opcode we add over time results in an increased complexity. This in no way shutting down future opportunities for improvement. And CoinGeek may choose to welcome profoundly opportune changes that can catapult BCH utility. But CoinGeek and friends choose to err on the side of caution.
Let it be re-stated that locking down the protocol does not equate to never touching the protocol again. Moreover, in a decentralized environment where at any point a new miner can take the lead, consensus over the protocol can change at any point.
It’s easy to become excited and consumed by the latest gadget or idea that we often lose sight of the forest for the trees. Bitcoin is the only Proof of Work based cryptocurrency that can scale to global adoption, and it has the community and the drive to do so. The killer-app is money, and CoinGeek seeks to propel BCH to become not only the most dominant crypto-currency in the market but also become world-wide global cash.
CoinGeek’s position on seeking a stable protocol may upset some people, but the position is backed by studies and by some of the most well-respected security researchers. Bitcoin Satoshi Vision intends to resurrect original Bitcoin, uncapped, with all opcodes enabled. This move isn’t scary, nor is it dangerous. It is in fact, the original value proposition of Bitcoin. CoinGeek supports the roadmap that first seeks to restore the original implementation first and foremost, before making considerations for other changes.
We believe that in order to become global money and see BCH reach global adoption, we need to prove that the platform is indeed stable and that businesses can ‘trust’ that protocol development will not impede their actions. BTC has a history of tampering with the code in a manner that kills business. Consistency is important, stability is important, and the electronic cash use case comes first.