Interview with Bitcoin Unlimited developer Andrew Stone

Interview with Bitcoin Unlimited developer Andrew Stone

By Jamie Redman – November 25, 2016

Recently, Bitcoin.com spoke with Bitcoin Unlimited (BU) developer Andrew Stone about the competition for Bitcoin clients and the current block size debate. The cryptocurrency community has been asking who the developers of BU are and what the qualifications are to become a developer. This interview is to let people know about the development of BU and that the BU team will do its best to achieve the goals of the development team.

An In-depth Discussion with Bitcoin Unlimited Developer Andrew Stone

Bitcoin.com: Can you briefly introduce BU to our readers and how BU solves scalability?

Andrew Stone (AS): BU recognizes that Nakamoto consensus (proof of work) is the only reliable consensus mechanism, and the block size of Core, such as 1MB, is just a "social consensus". BU believes that if Bitcoin forks, users will not be interested in the small branch chain unless the branch guarantees the currency function of Bitcoin.

“ In the short term, BU solves scalability by allowing miners to mine blocks larger than 1MB . In the medium and long term, BU will support the Lightning Network and other off-chain technologies. Let the market decide which technology is best for the development of Bitcoin!”

BC: How did you get involved in the BU project? Who else are the developers on the BU team?

AS: Many ideas for BU came from discussions on the Bitcoin forum under a thread called "Gold Collapses, Bitcoin Rises". During that time, everyone who put forward their ideas on the forum deserves credit and should be thanked. I was also a member of the discussion at that time and proposed the "emergent consensus" algorithm on the forum (we didn't call it that at the time). After that, I wrote the BU Joint Charter (our charter) and released the initial version of the client. At that moment, I was essentially a benevolent dictator. Later, I participated in the election stipulated in the BU charter and was given the power that the winner should have.

Peter Tschipper and Andrea Suisani were early developers, and special mention goes to Peter Rizun, who helped BU a lot with his insight and analytical skills in the early stages of BU's development.

With BU being adopted by two mining pools, we have a lot of new contributors, and I won’t list them all here.

BC: Why do you think the Bitcorn Core developers would oppose competing clients like BU ?

AS: I don't know why any particular person is against competing clients. But I can give you the reasons why most people are against competing clients.

First, you may wish for an earlier, simpler time. For example, in 2012 when Bitcoin was worth $50 million. In a single client environment, especially when you are in charge of that client, some things are simpler. However, those days are gone. Now the situation is even worse. We have multiple protocols, such as: the P2P protocol of the Satoshi client, the Fibre network broadcast protocol, and the Falcon network. Mining equipment uses their own custom protocol "stratum". Diversity makes the Bitcoin network more robust, and the error of a single client will not endanger the entire network.

Second point, if you can’t legitimize your real needs (bigger blocks), criticizing your competitors is more beneficial to them.

Third point: People didn’t really understand the “FLP” outcome and thought it was just all the developers “getting together” to make a decision and reach a consensus on a protocol for an industry. However, without strict control over membership and participation, this is just an illusion. Protocols inevitably have competitors and imperfections. The allocation of USB IDs is a good example. In order to get a USB ID, you need to join the USB Alliance (membership costs tens of thousands of dollars). This model does not work for the open source hardware community, where individuals are very creative, but the device market is very small. Eventually people realized that information is free, and the USB Alliance could not legitimize such restrictions unless you can put the USB logo on your product, so people started using arbitrarily selected IDs.

Instead, in critical software development tasks, the "golden rule" is to create multiple complete parts and run them simultaneously. This reduces the chances of errors causing the overall task to fail.

BC: What do you think when Adam Back and others say that BU is a semi-beta and that the BU developers are not qualified?

  AS: It frustrates me because these people are not qualified to make these comments. I don't mean to say that. I mean these people have never reviewed the code they are criticizing.

It is obvious that anyone who works as a Core developer or a company that hires a Core developer would benefit from Bitcorn Core remaining the only major customer. Therefore, there is a huge potential conflict of interest for individuals. So I ask people who read these reports, unless they provide real and reliable data, you can only accuse them of being suspicious, fearful, and providing false information.

I finally responded to Adam’s criticism that Core’s code had significant and persistent (recently added) bugs. I was so reluctant to respond because it was the developer’s fault. Bugs are still an unfortunate part of software development today. However, by doing so, I was able to demonstrate that Bitcoin Unlimited has been far more tested than Core. The myth that Bitcoin Core’s code and developers are somehow uniquely qualified to develop Bitcoin software is no longer true. In fact, the Bitcoin code quality is worse than I’ve seen in many mission-critical applications.

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

  AS: I can't comment on the other members of the BU team (not knowing their pasts), I can only say that I have personally reviewed their work and found them to be very good.

I've worked on high reliability and mission critical applications my entire career, so I'm no stranger to this kind of code. I work with OpenClovis, which means my software is used by most of the telecom companies in the world and is embedded in a lot of telecom equipment. We count users not just based on OpenClovis software, but based on the actual users we receive, which I would guess is in the hundreds of millions. If you have a cell phone in Korea, you're using software I wrote. If you have a Verizon brand phone, there's a good chance you're using software I wrote. If you have an extension for your home phone, you're probably using software I wrote. If your company has SIP-based phones or a plethora of Ethernet enterprise switches, there's a chance you're using our software (depending on the brand your company purchased).

BC: In a recent article titled “A Brief History of Bitcoin Core ,” you described various vulnerabilities discovered in the Core client. Do you think the community should take these vulnerabilities more seriously?

  AS: Absolutely. In the high availability industry there is a concept of a “5000-year” bug. These are bugs that normally happen very rarely. But if you are running 5000 clients, or you encounter unusual operating conditions, these rare bugs can suddenly start happening more often. In the telecom industry, every crash or core dump is tracked down to find the possible root cause, even if that means spending hours manually reviewing the code, or adding conditional “force” commands to trigger specific code flows that would normally be impossible to trigger with external input. We need something similar in the Bitcoin code.

Part of the purpose of this exercise is also to allow individuals to demonstrate their merit. Coming up with rejections of investigations with no actual evidence and excuses like "this only happens in debug mode" is a very big problem. Frankly, the responses of some people to my post should make you more worried about the development methods of Core than my criticisms. Because every piece of software has bugs, me pointing out three of them should already prove that BU is responsible with its codebase and testing. Not really saying how bad Core is anymore.

But if contributors deny my bugs without checking them, that's a problem. What other bugs have been similarly denied? One of the worst denials is "A can't happen because of (seemingly unrelated) X, Y, and Z." The problem is that if this philosophy permeates the codebase, you end up with a lot of hidden dependencies that can only be developed and maintained by the original author or someone who has been involved in the project for a long time.

Running code that produces undefined behavior in protected debug mode is a real problem. That's because developers are running in debug mode. If a bug in debug mode causes problems, the developer may "fix" it, causing a bug in production code. For example, missing locks around the node cleanup code is a possible example of this. Those locks may have been removed in debug mode, and the dd_mutex may have been cleaned up, causing the program to break (invalid mutex). But the effect of removing the locks is (what we saw in testing) that you can get a core dump, and in rare cases a peer will drop the connection at the exact moment you shut down.

BC: What will BU do to improve the Core program errors ?

AS: Find the problem, fix it. Of course, we have our own development methods to prevent the introduction of these bugs, and are restructuring (and hopefully changing the base to some extent) the code to address these types of issues.

BC: Is it true that BU has removed the hard limit on block size and allows people to choose the block size? How does the system work in this case?

AS: Yes, Peter Rizun has written a very detailed paper describing it — the “Emergent Consensus” algorithm. It really would take a whole article to explain it, so I’ll just refer you to the paper.

We also did theoretical and analytical work to demonstrate this idea, which can be found in Peter’s “Fee Markets” paper and my “Single Transaction (Empty) Blocks” paper. Our work can be summarized in one sentence: “Network propagation and block validation delays create non-zero transaction costs and limit the average block size to the average capacity of the underlying physical network.

BC: What is the difference between the BU client and Bitcoin Classic and XT ?

AS: BU believes that “consensus of stakeholders”, an algorithm on top of Nakamoto consensus, is actually impossible. For example, a major criticism of Classic and XT is “if miners mistakenly signal a large block, then when do they reject them? BU recognizes the impossibility of this higher-layer consensus (or more precisely, Nakamoto consensus is the only known algorithm that achieves it – which, by the way, from a theoretical point of view avoids the FLP result because it has never actually reached consensus – if an alien with super-powerful technology rewrites the blockchain from the genesis block, Nakamoto consensus will switch to that chain), so there is no coordination algorithm that can automatically change the consensus.

In contrast, BU removes most non-monetary functional protection parameters from the consensus layer. So if bigger blocks suddenly appear in the network, you'll pay attention. But if someone spends other people's money or gives himself a big block as a reward, you'll reject it.

And it requires the operator to actually participate in producing the first big block. This allows miners to quickly back off if other miners mistakenly signal (called a "faulty process" in FLP terminology).

BC: Recently, the Bitcoin community announced a $ 1.2 million donation for protocol development. What do you think of this donation and its stated principles?

AS: It’s a very good thing that people are willing to set up a development fund for Bitcoin development. It’s absolutely the right thing to do. The “Blockstream model” of a for-profit commercial company leading development doesn’t seem to be in the best interest of Bitcoin as a currency and Bitcoin currency holders.

BC: What is the BU team’s opinion on Segregated Witness?

AS: I cannot speak for the team, and more importantly, I cannot speak for the BU team members. My personal opinion is as follows:

For blockchain, Segregated Witness just adds unnecessary complexity to the blockchain.

The scale that SegWit can achieve is not enough for any company to be interested in building products or services on top of Bitcoin, and the scale it brings is not even enough to meet the needs of off-chain scaling methods.

The final size of SegWit is 1.7MB transaction block size, but requires a 4MB block size (does this mean that a simple hard fork to add 2MB will bring the total block size to 8MB? Because in today's network, 2MB is very easy, but 8MB may be "barely"). SegWit will not solve all existing problems (such as scalability) because old transactions will always be generated, and old transactions will create a lot of "technical debt" that will make Bitcoin difficult to maintain and expand in the future.

But SegWit will solve some existing problems, provided that SegWit transactions are used. But many other known problems are not solved. (In fact, other problems and features were promised, but were not ultimately included in the SegWit implementation.) A completely new transaction format can solve the problems that SegWit was supposed to solve more simply and elegantly.

Segregated Witness will require every wallet to modify its code.

“It looks like politics – a large signature space seems to encourage certain groups of people as much as it dissuades others, and it confirms developers as stewards of the network and arbiters of some ‘magic number’.

BC: In order to gain community trust in the Bitcoin protocol proposed by your team, what would you like to say to the community?

AS: No. You don’t need to trust anyone. BU encourages and supports multiple client implementations, and we will also provide you with a way to rely on the Nakamoto consensus.

At the same time, we are Bitcoin holders and are not employed by blockchain companies that compete with Bitcoin for profit.

BC: Do you think the block size issue can be resolved soon?

AS: Of course, I hope so. I think individual and corporate support for BU, both publicly and privately to many miners, will have a big impact on BU. Let's tell miners that the economic and commercial majority wants bigger blocks!

Thank you, Andrew, for keeping our readers informed about what's going on at BU.