Meet Bitcoin Unlimited Developer Andrew Stone

Bitcoin.com recently chatted with Bitcoin Unlimited (BU) developer Andrew Stone to discuss the alternative client and the current block size debate. Lately, the cryptocurrency community has been asking who the BU developers are, and what are their qualifications. This interview is meant to shed some light on development and Stone’s opinion of the goals BU is trying to accomplish.

Also read: ViaBTC Mines First Bitcoin Unlimited 2MB Block, Allocates Full Hashpower

An In-Depth Discussion With Bitcoin Unlimited Developer Andrew Stone

Bitcoin.com (BC): Can you describe to our readers a simple version of what Bitcoin Unlimited is and how it addresses scalability?

Andrew Stone (AS): Bitcoin Unlimited recognizes that Nakamoto Consensus (proof of work) is the only infallible consensus mechanism and that arbitrary agreements like Core’s 1MB block size are “social consensus.” Bitcoin Unlimited does not believe that it’s in its users’ interest to be on a minority fork unless the reason for the fork is to protect Bitcoin’s function as money.

Bitcoin Unlimited addresses scalability in the short term by allowing miners to mine blocks that are greater than 1MB.  In the medium to long term, Bitcoin Unlimited will support Lightning and other off-chain technologies. Let’s let the market decide which technology works best for an application!

BC: How did you get involved with the BU project and who else is on the team of developers?

AS: Many of the general ideas that became Bitcoin Unlimited were being discussed on the “Gold Collapsing Bitcoin Up” thread on the bitco.in forum. All of the people on that forum at that time deserve credit and thanks for coming up with ideas. I was part of that discussion and proposed the “emergent consensus” (we didn’t call it that back then) algorithm there. I then wrote the BU Articles of Federation (our bylaws) and made the initial client release.  At that point, I was essentially a benevolent dictator. I then ran the elections specified in the BU Articles and ceded authority to the winners.

Peter Tschipper and Andrea Suisani were early developers, and Peter Rizun deserves special mention for helping Bitcoin Unlimited’s early days with his insights and analytics.

With the adoption of BU by two mining pools, we have many new contributors and so I shall not enumerate everyone here.

BC: Why do you think Bitcoin Core developers are against alternative clients like BU?

AS: I cannot say why particular people are against alternative clients.  But I can provide some ideas about why someone might be against alternative clients in general.

First, you might wish for an earlier, simpler time. Like in 2012 when Bitcoin had a market cap of $50 million. Some things are easier in a single-client environment, especially if you are in charge of that client. However, that situation is gone.  The situation today is even worse.  We even have multiple protocols… the Satoshi client P2P protocol, the Fibre broadcast network, the Falcon network.  Hashing devices use their own custom protocol, “stratum.” But diversity is ultimately strength — a bug in “the” client won’t halt the entire network.

Second, if you can’t justify your real issue (larger blocks), you might grab at whatever argument is convenient.

Third, you haven’t really internalized the “FLP” result and think that all developers can just “get together” and come to a decision in a manner similar to the way protocols are specified in the industry. However, without strict control over the membership and participation, this is a fantasy. Protocols inevitably have competitors and incompatible extensions. A good example of this is the assignment of USB identifiers. To get a USB id, you need to join the USB consortium (membership costs many thousands of dollars). This model does not work in the open source hardware community where individuals are creating awesome but very-small-market devices. Ultimately people realized that information is free — legally the USB consortium cannot enforce this restriction unless you put the USB trademark on your product. So people just started picking random IDs.

In contrast, in mission critical software development, the “gold standard” is to create multiple completely separate implementations and run them simultaneously. This reduces the likelihood that implementation bugs will cause mission failure.

BC: When Adam Back and others make statements about BU being “semi-tested” and BU developers are unqualified, how do these opinions sit with you?

AS: It is pretty upsetting because these people are themselves unqualified to make these statements. And I don’t mean technically. I mean that they have never shown that they have examined the code that they are criticizing.  

It is clear that anyone who is a Core developer or whose company employs Core developers benefits dramatically from having Bitcoin Core remain the single majority client. Therefore these individuals have a massive unacknowledged conflict of interest. So I’d ask everyone who reads these statements to dismiss them as FUD until and unless actual data is provided.

I finally responded to Adam’s criticism by showing that the Core code has significant and ongoing (recently added) flaws. I did so reluctantly because developers make mistakes.  Bugs are an unfortunate part of software development today. However, by doing so, I showed that Bitcoin Unlimited has actually tested more situations than Core. And I needed to dispel the myth that the Bitcoin Core code and developers are somehow uniquely qualified to develop Bitcoin software needed to be dispelled. In fact, the code is worse than I see in many mission critical applications.

BC: Can you tell us your qualifications and why members of the team are qualified to work on Bitcoin’s protocol?  

AS: I cannot comment on the qualifications of the other members of the Bitcoin Unlimited team (since I do not know their history), other than to say that I’ve personally reviewed their work and find it generally excellent.

I have worked in high availability and mission critical applications for my entire career, so I am no stranger to the care required to develop this kind of code. My work with OpenClovis, Inc means that my software is running in almost every major telecom company worldwide, embedded in other telecom devices. We do not receive numbers of users depending on OpenClovis software, however, based on the numbers we DO receive, I’d guess it is in the hundreds of millions of people. If you have a cell phone in South Korea, you are using the software I wrote. If you have a Verizon cell phone, you are likely using my software.  If you have a cell phone home range extender, you are probably using it. If your company has SIP-based phones, or a redundant ethernet enterprise class switch, there’s a chance you are using us (it depends on the brand your company purchased).

BC: In a recent post called “A Short Tour of Bitcoin Core” you describe various bugs found within the core client. Do you think the community should take these bugs more seriously?

AS: Of course. The high availability industry has the concept of “5000-year” bugs. These are bugs that typically happen rarely. However, if you are running 5000 clients, or you hit an abnormal operating condition, these rare bugs can suddenly start happening more frequently.  In the telecom industry, EVERY SINGLE crash or core dump is traced to a probable root cause even if that means manually examining code for hours and adding conditional “forcing” statements to trigger a specific code flow that is not normally possible to trigger using external input. We need similar care taken in the Bitcoin code.

Part of the purpose of that exercise was to let individuals show their merits. Posting denials without actual investigation and excuses like “this only runs in debug mode” is a big problem.  Frankly, the responses by certain individuals to my post should have made you more worried about the Core development methodology than my critique itself. Because every piece of software has bugs, my pointing out three of them should have simply proven to you that Bitcoin Unlimited is, in fact, competent at development, knowledgeable in the code base and testing well. It should not really reflect that poorly on Core.

But if the contributors deny them without checking, that is a problem. What other bugs have been similarly denied? And one of the worst denials is “A can’t happen because of (seemingly unrelated) X, Y, and Z.” The problem is that if that philosophy pervades the code base, you end up with code with a lot of implicit dependencies which can only be developed and maintained by the original authors or by people who have been involved in the project for a long time.

And defending running code that produced undefined behavior in debug mode is a real problem. Because developers run in debug mode. If you have a bug that is causing a problem in debug mode, developers may “fix” that problem, resulting in bugs in production code. For example, the lack of locks around the node cleanup code is a probable example of this happening. These locks may have been removed because in debug mode, the dd_mutex may be already cleaned up, resulting in an assert within boost (invalid mutex). But the effect of removing the locks (which we saw in our testing) is that you can get a core dump, in the extremely rare situation where a peer drops the connection at the exact moment you are shutting down.

BC: What has BU done to improve upon Core’s programming mistakes?

AS: Find ‘em, fix ‘em!  And of course, we have our own development methodology to discourage the introduction of these errors, and are restructuring (to some degree, we also want to be able to rebase) the code to solve entire classes of issues.

BC: BU has removed the block size hard limit and allows people to choose what the block size will be, is this assumption correct? How does that work?

AS: Yes, Peter Rizun has produced an excellent document describing this — the “emergent consensus” algorithm. It really needs an entire article, so let me just refer you to it.

We have also done theoretical and analytical work justifying the proposal, which you can find in Peter’s “fee market” paper and my “single transaction (empty) block” paper. To sum that work up in a single sentence:  “Network propagation and block validation delays will create a non-zero cost for transactions, and limit the average block size to the average capacity of the underlying physical network.”

BC: How does BU differ from clients such as Bitcoin Classic and XT?

AS: BU recognizes that an algorithmic “stakeholder consensus” above Nakamoto Consensus is not actually possible. For example, one significant criticism of Classic and XT was “what if miners falsely signal for large blocks but then when the time comes reject them?” BU recognizes the impossibility of this higher layer consensus (or more accurately, that Nakamoto Consensus is the only known algorithm to implement it — and by the way, from a theoretical perspective it avoids the FLP result because it never actually achieves consensus — if an alien with awesome tech recomputed the blockchain from the genesis block, Nakamoto Consensus would switch to that chain), and so does not have any coordination algorithm that automatically changes consensus parameters.

Instead, BU removes most non-money-function-protecting parameters from the consensus layer.  So if the rest of the network suddenly goes to bigger blocks, you’ll follow. But if someone spends someone else’s money or gives himself an overly large block reward, you will not.   

And it requires operator involvement to actually generate the first large block. This allows a miner to quickly back down if it turns out that other miners are falsely signaling (“one false process” in the FLP terminology).

BC: The Bitcoin community has recently announced a $1.2 million grant towards protocol development. What is your opinion of the overall message of the principles tethered to this new grant?

AS: Its great that people are willing to fund development of Bitcoin! The message is completely on target. The “Blockstream model” where a for-profit commercial company heads up development seems to not be in the best interest of bitcoin as a currency and holders of the bitcoin currency.

BC: What is the BU team’s opinion of segregated witness?

AS: I cannot speak for the team, or more importantly I cannot speak for the BU members.  My opinion is that:

It is needless complexity added to the blockchain.

It does not scale enough to interest any companies in creating Bitcoin products or services, it does not even scale enough to significantly deploy off-chain scaling solutions.

It has an ~1.7MB eventual size but a 4MB spam liability (does this mean that a simple hard fork increase to 2MB results in an 8MB total block?  Because emotionally 2MB is easy on today’s network, but 8MB is perhaps “pushing it”)   

It does not remove existing issues (like malleability) because you can always generate old-style transactions, this creates a lot of “technical debt” that will make Bitcoin much harder to maintain and extend in the future

It does solve some existing issues if SegWit-style transactions are used. But many other known issues did not make the “cut” (the fact that other issues were promised but weren’t included hints at the development complexity of SegWit — the feature is a half-year late and missing features).  A completely new transaction format can solve many more problems, more simply and elegantly.

It forces every wallet to change their code.

It seems to be political — a large signature space seems to encourage certain use cases and discourage others, and it confirms developers as the stewards of the network and the arbiter of certain “magic numbers”

BC: What would you like to say to the community in regards to trusting you guys with the Bitcoin protocol?

AS: You don’t need to. You should not trust anyone. BU supports and encourages multiple client implementations, and we give you the tools to rely on Nakamoto Consensus.

At the same time, we bitcoin holders and are not employed by for-profit companies with competing blockchains…

BC: Do you see the block size situation resolving anytime soon?

AS: Yes, I hope so. I think that individual and corporate support of Bitcoin Unlimited, either publicly, or by speaking privately to large miners will make a big difference.  Let us show the miners that the economic and business majority wants larger blocks!

Thank you, Andrew, for giving our readers insight into the Bitcoin Unlimited environment.

What do you think about the BU and its development process? Do you think Core developers should be more open to embracing different types of experimentation? Let us know in the comments below.

Images courtesy of Shutterstock, and Bitcoin Unlimited.

Do you want to talk about bitcoin in a comfortable (and censorship-free) environment? Check out the Bitcoin.com Forums — all the big players in Bitcoin have posted there, and we welcome all opinions.

The post Meet Bitcoin Unlimited Developer Andrew Stone appeared first on Bitcoin News.