Bitcoin Unlimited Creator: Only On-Chain Scaling Helps Real Life Use Cases
On-chain scaling and understanding how people use Bitcoin in reality are the most important issues to address, says Bitcoin Unlimited developer Andrew Stone. While solutions like SegWit and Lightning networks are good, he said, they’re not addressing the right problems the right way.
Stone (a.k.a. theZerg) wrote the original Bitcoin Unlimited client and the project’s articles of federation. He then handed the project to new leaders, though remains a leading contributor.
The Current Issues, From Unlimited’s Side
Bitsonline interviewed Stone for a “big picture” view on scaling and the state of the debate. He also addressed some concerns that have arisen in recent weeks, such as the quality of Unlimited’s team and the difficulty the community faces in finding information.
JS: Bitcoin Unlimited supporters remain confident their preferred scaling solution will prevail over others. What are the reasons for that?
AS: Increasing the block size is the single most pressing issue in Bitcoin today. It is stifling innovation, adoption and price appreciation. Yet the network’s capacity to handle the increase is uncontested. Even the Core team has tacitly acknowledged that 4MB blocks are possible because its SegWit block can be up to 4MB.
SegWit delivers a lot of other nice features but addresses the scalability issue poorly and inefficiently (although its block size is 4MB, only about 1.7MB of typical transactions fit in it). We can easily fix these other features after scalability is addressed! I like Lightning but it mostly solves the “starbucks card” use case. It does not solve how Bitcoin is used today, in remittance, investment, and occasional internet purchases. And Lightning does not work with innovative uses where a fractional Bitcoin token is used representationally.
Ironically, to get to a “fully-routed” Lightning Network we need Bitcoin to be used by orders of magnitude more people and companies and so without on-chain scaling Lightning will not succeed.
JS: There are rumors out there that certain Bitcoin projects are funding reporters to produce favorable articles, have you heard them too?
AS: I cannot comment on rumors of paid journalism. But certainly I have read some very biased articles and the censorship in certain forums is rampant and well documented. Look for logical inconsistencies, like “block size must remain 1MB” yet SegWit itself uses 4MB, and unproven assertions like “a larger block size will cause centralization”, yet a larger block size will invite many more participants promoting decentralization (and Lightning seems to be highly centralizing). Or “hard forks are dangerous”, yet altcoins have undergone many successful hard forks, and Bitcoin has had one.
JS: What signs of bias should skeptical readers watch out for?
AS: Ultimately, if an article is too negative you need to ask yourself why are 40% of the hash power, eight mining pools (vs. three for SegWit, as reported by coin.dance) and countless nodes signaling for it? This is a huge movement with very legitimate arguments. If an article does not at least report those arguments, it’s clearly biased.
JS: Some high-profile community members have suggested Unlimited’s main flaw is inadequate skill/experience in its dev team. How would you counter that?
AS: Our team has tremendous experience in C++ development, too much to describe here. But the Satoshi code base is messy, as I showed in a prior Medium post. Looking exclusively at the bugs in Bitcoin Unlimited ignores the long history of bugs in Core. Much of our work in the last year has been to clean it up.
The recent BU bugs were mostly “asserts”, introduced a year ago when Bitcoin Unlimited was two engineers working part time, unpaid. Traditionally, “assert” identifies an invalid state and causes the program to stop in debug builds only. However, in the Satoshi code base they were turned on in release builds. So in this case our prior experience and desire to armor the code against any strange result worked against us.
Yet the effect on the network was minimal — our miners actually produced several blocks during the exploit since their nodes are either set to automatically restart or are isolated from the network as a whole.
The reality is that all software will have bugs. A multi-client network is the most resistant to bugs in one client, and actually will allow each client to innovate faster (since the repercussions of a bug are smaller). Following this philosophy, I recently added an RPC call “validateblocktemplate” that will allow a miner to check that a block is valid before mining it. This and other new features will allow mining pools to run multiple clients in their network.
Ultimately, the growing Bitcoin Unlimited team size, experience with the Satoshi code, and maturing software process will minimize bugs in our code base.
Fundamental Differences on What Bitcoin Should Be
Like current US politics, it sometimes seems like the different sides are living in alternate realities. The passionate idealists block out all other arguments, leading to bubble-like thinking. It’s about more than just the Bitcoin codebase now; there are fundamental differences on what form a non-governmental, decentralized cryptocurrency should take. While there are plenty of altcoins to experiment with those forms, Bitcoin has the $19 billion USD market cap and 8-year history. There’s a lot at stake — not just money and reputation, but also visions. Does the world have only one shot to get this right, or multiple?
Do you agree or disagree with Stone’s arguments? We’d love to hear your thoughts.
Disclaimer: Bitsonline does not hold an editorial position favoring any Bitcoin scaling option. We are also interviewing several other participants and examining several angles in order to allow others in the community to make up their own minds.
Images via Bitcoin.com Pool,