The Astounding Incompetence, Negligence, and Dishonesty of the Bitcoin Unlimited Developers
On August 26, 2016 someone noticed that their Classic node had been forked off of the “Big Blocks Testnet” that Bitcoin Classic and Bitcoin Unlimited were running. Neither implementation was testing their consensus code on any other testnets; this was effectively the only testnet being used to test either codebase. The issue was due to a block on the testnet that was mined on July 30, almost a full month prior to anyone noticing the fork at all, which was in violation of the BIP109 specification that Classic miners were purportedly adhering to at the time. Gregory Maxwell observed:
That was a month ago, but it’s only being noticed now. I guess this is demonstrating that you are releasing Bitcoin Classic without much testing and that almost no one else is either? :-/
The transaction in question doesn’t look at all unusual, other than being large. It was, incidentally, mined by pool.bitcoin.com, which was signaling support for BIP109 in the same block it mined that BIP 109 violating transaction.
Later that day, Maxwell asked Roger Ver to clarify whether he was actually running Bitcoin Classic on the bitcoin.com mining pool, who dodged the question and responded with a vacuous reply that attempted to inexplicably change the subject to “censorship” instead.
Andrew Stone (the lead developer of Bitcoin Unlimited) voiced confusion about BIP109 and how Bitcoin Unlimited violated the specification for it (while falsely signaling support for it). He later argued that Bitcoin Unlimited didn’t need to bother adhering to specifications that it signaled support for, and that doing so would violate the philosophy of the implementation. Peter Rizun shared this view. Neither developer was able to answer Maxwell’s direct question about the violation of BIP109 §4/5, which had resulted in the consensus divergence (fork).
Despite Maxwell having provided a direct link to the transaction violating BIP109 that caused the chain split, and explaining in detail what the results of this were, later Andrew Stone said:
I haven’t even bothered to find out the exact cause. We have had BUIP016 passed to adhere to strict BIP109 compatibility (at least in what we generate) by merging Classic code, but BIP109 is DOA — so no-one bothered to do it.
I think that the only value to be had from this episode is to realise that consensus rules should be kept to an absolute, money-function-protecting minimum. If this was on mainnet, I’ll be the Classic users would be unhappy to be forked onto a minority branch because of some arbitrary limit that is yet another thing would have needed to be fought over as machine performance improves but the limit stays the same.
Incredibly, when a confused user expressed disbelief regarding the fork, Andrew Stone responded:
Really? There was no classic fork? As i said i didnt bother to investigate. Can you give me a link to more info? Its important to combat this fud.
Of course, the proof of the fork (and the BIP109-violating block/transaction) had already been provided to Stone by Maxwell. Andrew Stone was willing to believe that the entire fork was imaginary, in the face of verifiable proof of the incident. He admits that he didn’t investigate the subject at all, even though that was the only testnet that Unlimited could have possibly been performing any meaningful tests on at the time, and even though this fork forced Classic to abandon BIP109 entirely, leaving it vulnerable to the types of attacks that Gavin Andresen described in his Guided Tour of the 2mb Fork:
“Accurate sigop/sighash accounting and limits” is important, because without it, increasing the block size limit might be dangerous… It is set to 1.3 gigabytes, which is big enough so none of the blocks currently in the block chain would hit it, but small enough to make it impossible to create poison blocks that take minutes to validate.
As a result of this fork (which Stone was clueless enough to doubt had even happened), Bitcoin Classic and Bitcoin Unlimited were both left vulnerable to such attacks. Fascinatingly, this fact did not seem to bother the developers of Bitcoin Unlimited at all.
On November 17, 2016 Andrew Stone decided to post an article titled A Short Tour of Bitcoin Core wherein he claimed:
Bitcoin Unlimited is building the highest quality, most stable, Bitcoin client available. We have a strong commitment to quality and testing as you will see in the rest of this document.
The irony of this claim should soon become very apparent.
In the rest of the article, Stone wrote with venomous and overtly hostile rhetoric:
As we mine the garbage in the Bitcoin Core code together… I want you to realise that these issues are systemic to Core
He went on to describe what he believed to be multiple bugs that had gone unnoticed by the Core developers, and concluded his article with the following paragraph:
I hope when reading these issues, you will realise that the Bitcoin Unlimited team might actually be the most careful committers and testers, with a very broad and dedicated test infrastructure. And I hope that you will see these Bitcoin Core commits — bugs that are not tricky and esoteric, but simple issues that well known to average software engineers — and commits of “Very Ugly Hack” code that do not reflect the care required for an important financial network. I hope that you will realise that, contrary to statements from Adam Back and others, the Core team does not have unique skills and abilities that qualify them to administer this network.
As soon as the article was published, it was immediately and thoroughly debunked. The “bugs” didn’t exist in the current Core codebase; some were results of how Andrew had “mucked with wallet code enough to break” it, and “many of issues were actually caused by changes they made to code they didn’t understand”, or had been fixed years ago in Core, and thus only affected obsolete clients (ironically including Bitcoin Unlimited itself).
As Gregory Maxwell said:
Perhaps the biggest and most concerning danger here isn’t that they don’t know what they’re doing — but that they don’t know what they don’t know… to the point where this is their best attempt at criticism.
Amusingly enough, in the “Let’s Lose Some Money” section of the article, Stone disparages an unnamed developer for leaving poor comments in a portion of the code, unwittingly making fun of Satoshi himself in the process.
To summarize: Stone set out to criticize the Core developer team, and in the process revealed that he did not understand the codebase he was working on, had in fact personally introduced the majority of the bugs that he was criticizing, and was actually completely unable to identify any bugs that existed in current versions Core. Worst of all, even after receiving feedback on his article, he did not appear to comprehend (much less appreciate) any of these facts.
On January 27, 2017, Bitcoin Unlimited excitedly released v1.0 of their software, announcing:
The third official BU client release reflects our opinion that Bitcoin full-node software has reached a milestone of functionality, stability and scalability. Hence, completion of the alpha/beta phase throughout 2009–16 can be marked in our release version.
A mere 2 days later, on January 29, their code accidentally attempted to hard-fork the network. Despite there being a very clear and straightforward comment in Bitcoin Core explaining the space reservation for coinbase transactions in the code, Bitcoin Unlimited obliviously merged a bug into their client which resulted in an invalid block (23 bytes larger than 1MB) being mined by Roger Ver’s Bitcoin.com mining pool on January 29, 2017, costing the pool a minimum of 13.2 bitcoins. A large portion of Bitcoin Unlimited nodes and miners (which naively accepted this block as valid) were temporarily banned from the network as a result, as well.
The code change in question revealed that the Bitcoin Unlimited developers were not only “commenting out and replacing code without understanding what it’s for” as well as bypassing multiple safety-checks that should have prevented such issues from occurring, but that they were not performing any peer review or testing whatsoever of many of the code changes they were making. This particular bug was pushed directly to the master branch of Bitcoin Unlimited (by Andrew Stone), without any associated pull requests to handle the merge or any reviewers involved to double-check the update. This once again exposed the unprofessionalism and negligence of the development team and process of Bitcoin Unlimited, and in this case, irrefutably had a negative effect in the real world by costing Bitcoin.com thousands of dollars worth of coins.
In effect, this was the first public mainnet fork attempt by Bitcoin Unlimited. Unsurprisingly, the attempt failed, costing the would-be forkers real bitcoins as a result. It is possible that the costs of this bug are much larger than the lost rewards and fees from this block alone, as other Bitcoin Unlimited miners may have been expending hash power in the effort to mine slightly-oversized (invalid) blocks prior to this incident, inadvertently wasting resources in the doomed pursuit of invalid coins.
On March 14, 2017, a remote exploit vulnerability discovered in Bitcoin Unlimited crashed 75% of the BU nodes on the network in a matter of minutes.
In order to downplay the incident, Andrew Stone rapidly published an article which attempted to imply that the remote-exploit bug also affected Core nodes by claiming that:
approximately 5% of the “Satoshi” Bitcoin clients (Core, Unlimited, XT) temporarily dropped off of the network
In reddit comments, he lied even more explicitly, describing it as “a bug whose effects you can see as approximate 5% drop in Core node counts” as well as a “network-wide Bitcoin client failure”. He went so far as to claim:
the Bitcoin Unlimited team found the issue, identified it as an attack and fixed the problem before the Core team chose to ignore it
The vulnerability in question was in thinblock.cpp, which has never been part of Bitcoin Core; in other words, this vulnerability only affected Bitcoin Classic and Bitcoin Unlimited nodes.
In the same Medium article, Andrew Stone appears to have doctored images to further deceive readers. In the reddit thread discussing this deception, Andrew Stone denied that he had maliciously edited the images in question, but when questioned in-depth on the subject, he resorted to citing his own doctored images as sources and refused to respond to further requests for clarification or replication steps.
Beyond that, the same incident report (and images) conspicuously omitted the fact that the alleged “5% drop” on the screenshotted (and photoshopped) node-graph was actually due to the node crawler having been rebooted, rather than any problems with Core nodes. This fact was plainly displayed on the 21 website that the graph originated from, but no mention of it was made in Stone’s article or report, even after he was made aware of it and asked to revise or retract his deceptive statements.
There were actually 3 (fundamentally identical) Xthin-assert exploits that Unlimited developers unwittingly publicized during this episode, which caused problems for Bitcoin Classic, which was also vulnerable.
On top of all of the above, the vulnerable code in question had gone unnoticed for 10 months, and despite the Unlimited developers (including Andrew Stone) claiming to have (eventually) discovered the bug themselves, it later came out that this was another lie; an external security researcher had actually discovered it and disclosed it privately to them. This researcher provided the following quotes regarding Bitcoin Unlimited:
I am quite beside myself at how a project that aims to power a $20 billion network can make beginner’s mistakes like this.
I am rather dismayed at the poor level of code quality in Bitcoin Unlimited and I suspect there [is] a raft of other issues
The problem is, the bugs are so glaringly obvious that when fixing it, it will be easy to notice for anyone watching their development process,
it doesn’t help if the software project is not discreet about fixing critical issues like this.
In this case, the vulnerabilities are so glaringly obvious, it is clear no one has audited their code because these stick out like a sore thumb
In what appeared to be a desperate attempt to distract from the fundamental ineptitude that this vulnerability exposed, Bitcoin Unlimited supporters (including Andrew Stone himself) attempted to change the focus to a tweet that Peter Todd made about the vulnerability, blaming him for exposing it and prompting attackers to exploit it… but other Unlimited developers revealed that the attacks had actually begun well before Todd had tweeted about the vulnerability. This was pointed out many times, even by Todd himself, but Stone ignored these facts a week later, and shamelessly lied about the timeline in a propagandistic effort at distraction and misdirection.
