Bitcoin Cash Developer Reveals How He Found One of The Most Serious Bug in Bitcoin – Trustnodes

Bitcoin Cash Developer Reveals How He Found One of The Most Serious Bug in Bitcoin


A pseudonymous developer of Bitcoin Unlimited, one of Bitcoin Cash’s main client, has come out to reveal how he found the most serious bug in bitcoin for the past eight years.

As evidence to prove he found the bug, Awemany time stamped the hash (pictured) and has further signed with the PGP key used in the responsible disclosure to Bitcoin Core and other projects. We quote below the relevant part at some length:

“I was working on getting the new CHECKDATASIG/-VERIFY opcodes that are about to activate for Bitcoin (Cash) in November implemented on the Bitcoin Unlimited client. I have been looking at a potentially neat use case for those and am motivated to get this done.

Around noon [on Monday, September 17th], I noticed that there is a lot of divergence in the way that signature operations counting was done in ABC vs. how it was done in Bitcoin Unlimited (BU). I agreed earlier with the BU team that I would go and port most of the CDS/-V stuff over from ABC, but I felt overwhelmed. My thoughts were that: Ok, this is doable, but this needs a lot more analysis and also many more eyeballs for review. And will take a lot longer. Sigh. While doing so, I stumbled upon this comment in the ABC code base:

// Check for duplicate inputs — note that this check is slow so we skip it in CheckBlock

My initial reaction was a slight ‘Eh, WTF is going on with that comment?’. And then I looked up uses of CheckRegularTransaction in ABC, which is the renamed variant of CheckTransaction in Core (but I didn’t know at that time). I dug through the code to try to understand the logic.

I noticed that block validation skips this test as it is assumed to have already happen during mempool ingress. My next thought was a bit of a sinking feeling and a ‘Uh-oh, I really hope the folks from ABC have thought about the difference between the mempool and block transmission and that those are distinct ways into the system. There might be a problem here!’. And then I went and thought about a way to test this. I patched an ABC node to not relay transactions even when asked and connected one unpatched and one patched node together in -regtest mode and created a transaction with a duplicate input (which the above test was skipping).

Wham! assert(), Aborted…

Opening up a disclosure email to deadalnix [BitcoinABC maintainer], I started to have a thought of: ‘Ok, actually, where is this stuff coming from, when and where did they introduce it into the code, might we be lucky and this is not in a release yet?’

And then I noticed that this stuff was coming from Core. Already having written a disclosure report, I rechecked whether Core was vulnerable as well.

And, once again: Wham! assert(), Aborted…

Being a responsible citizen in this space, I then wrote the encrypted disclosure email to Wladimir [Bitcoin Core maintainer], sickpig [Bitcoin Unlimited dev] and some others, attaching a variant of the ABC and the Core patch to exploit this problem to my disclosure.”

According to the above, the bug was found by just having a glance at the code, with the BU dev seemingly going from having a look at ~12PM to emailing other devs at 14:47PM on September 17th 2018.

As such, the series of events told seem to suggest it was obvious, pretty much instantly, that the removal of checks for double spending was a pretty big deal.

Something which even as a non-coder you’d expect, raising the question of just what exactly were the five Bitcoin Core devs thinking of when they approved this bug.

That’s because the bug wasn’t subtle or complex, but so basic that it was obvious at just a glance, according to the above, that the removal of checks for double spending was a pretty big problem.

That raises questions as to how exactly this bug, which could have effectively printed bitcoin out of thin air for a miner, made its way to the code.

It also raises questions on potential conflict of interest as Blockstream, as far as we are aware, mines. The dev who proposed this obvious bug was at the time working for Blockstream, as were two devs who approved it.

Further questions need to be raised on whether Bitcoin Core’s code is undergoing sufficient review. That’s because if a bug is at-a-glance obvious to a non Bitcoin Core dev, and yet still made its way in, then clearly the review process has failed and quite badly.

Thankfully now there is some competition, with Cory Fields of Bitcoin Core previously revealing a bug in ABC, which was serious, but far less serious than this as it didn’t allow for “valid” double spending.

During the height of the blocksize debate some from Bitcoin Core were less kind, engaging in very irresponsible behavior which led to the exploit of a bug in Bitcoin Unlimited.

Awemany has not returned the favor, engaging instead in very responsible disclosure which had led to a quick upgrade of much of the bitcoin ecosystem.

Miners and businesses have by now probably upgraded, but there are still thousands of nodes which remain vulnerable to the inflation bug at the time of writing.

In situations like this, an alert would have been sent to the nodes asking them to quickly upgrade. Such alert system was removed even though it did nothing more than say at the corner of the node screen something like you should upgrade as a bug has been found, read more at some link.

The alert itself would have not in any way interfered with the code nodes run, and if a wrong alert was sent, other devs could have just overwritten it. All the alert did was to inform node operators, who then could make their own decision.

Now, node operators have to check crypto media or crypto twitter, and if they’re on holiday during the news period, then they might think there is nothing wrong with their bugy node.

A bugy node that is now more secure for those that have upgraded thanks to Awemany’s disclosure. For that, he was rewarded with 0.03BTC in donations at the time of writing, worth $200. Bitcoin Cashers have been a lot more generous, sending him nearly 36 BCH in donations, worth $17,000.

Such devs, however, shouldn’t be relying on the good will of others as there should be bug bounties considering just how much money is at stake. Yet it appears neither Bitcoin Core nor Bitcoin Cash clients have such bug bounty, which may suggest devs don’t really have much of an incentive to reveal such bugs, hence perhaps why it has remained in live code for two years.



Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>