A responsible disclosure is not fun. Especially if the stakes are high and the timeline tight.
Full Disclosure of the full details of Tuesday’s Releases https://t.co/MZmxrs36J3
— Matt Corallo (@TheBlueMatt) September 21, 2018
On 17th of September a vulnerability was found that could, in the very worst case, have led to a real on-chain double spend. I will not go into the nature of the bug, how it was found and who resolved it (although that story is great and an amazing example of efficiency). Instead, I will focus on what it would take (or rather have taken) for an attacker to actually exploit the vulnerability and what he would stand to gain from it. There is a lot of misinformation about this in the media right now.
The attacker has to be a miner and he would have to create a block that includes a specially crafted transaction that spends the same input twice in the same transaction. This transaction cannot be one that he picked up from the network, where such a transaction would not propagate. Think of it as handing over the same twenty Swiss Francs bill twice in one payment at the grocery store. The grocery store actually received forty Swiss Francs even though you only spent one twenty Swiss Francs bill. The total monetary supply just increased by twenty Swiss Francs. This is why the bug is often dubbed as an ‘inflation bug’. The bug originated in the bitcoin core node software – this is run by companies dealing with or accepting bitcoin as well as individuals or developers in order to independently verify the information that they get from the blockchain. Since version 0.15.0 (September 2017) it no longer recognized such transactions as invalid.
After the bug was found, only few hours passed before version 0.16.3 was released and as of now already 19% of publicly visible nodes run on that version[i].
A miner running such an attack however runs the risk that despite many nodes not noticing the creation of money, other players will. He runs the risk that the betrayal of the network rules is picked up by humans instead of nodes. If this happens quickly enough, the operators of nodes, especially of economically relevant ones at exchanges will manually override and ignore this block. All it takes for this is one input in the bitcoin core node terminal. All preparations for such a step are taken. This would subsequently lead to a split in the blockchain, where nodes with observant operators follow a different chain than those nodes that do not. However, there is still a risk that the attacker can get his unjustly gained coins to an exchange, sell them there and withdraw the proceeds in fiat or a different cryptocurrency before the exchange notices the split and freezes operation. Given the mentioned efficiency and careful observation of certain individuals, the risk of such an attack, especially in economically damaging amounts, is very low.
It all comes down to two things. Firstly, what does the attack cost the attacker and secondly, how fast is the network likely to notice the anomaly and work around the culprit before he can take his profit.
Since the attacker has to be a miner and put his inflating transaction into a block which would otherwise have been valid, he is losing out on the reward for the block, yet still has to cover the production cost of that block. If the attack is unsuccessful, he just lost 12.5 BTC (plus fees), or at current rates roughly CHF 80k. This represents his investment.
To the second point, for the likelihood of discovery, that very much depends on the level of automation. Above, I only mentioned the manual, human means of discovery, but this is certainly not all. Projects like Statoshi or Bitcoin Optech continually monitor all possible network parameters. Fork monitors run different node software to determine any deviations. Developers do that to notice deviations between their software to bitcoin core and actually any bitcoin node will notify its operator if it determines that it is running on a minority chain, i.e. if there is a chain that is at least six blocks longer, but the node determines that chain to be invalid.
There are mechanisms in place to monitor the network for inconsistencies. In that context, the fact that the commit that enabled this bug only happened last September is very good news. Older versions are therefore not affected.
As of right now, 64% of nodes are secure, only 31% are vulnerable and 5% of publicly visible nodes do not send a standard version identifier, which means that it is unknown if they are affected or not. Those numbers obviously come after 19% of nodes have already updated to 0.16.3, but even if we assume that all of those have previously been on an affected version 0.15.0 to 0.16.2, this means that in the worst case scenario, there are still 31% of nodes that have not been vulnerable at the time of disclosure.
This rather high number, together with tools that monitor anomalies in the network, make it very unlikely that an attacker would be able to successfully spend his unjustly gained coins before the community notices and self-adjusts.
As a corollary to this: We do know that this exploit has not been executed in the past. For the very simple reason that pre-vulnerability nodes, running lower versions are purposely still up, running and in sync with the vulnerable ones.
Above considerations are valid for BTC. Smaller networks skew the numbers significantly. If it is cheaper to create a block, or rather if the opportunity cost of missing out on one, is smaller, the investment for the attacker goes down. Moreover, if there are fewer nodes and fewer developers monitoring the network, the likelihood of success goes up massively.
[i] For this and the further number of nodes, I source the information from https://coin.dance/nodes. This gives an indication about the network. Getting exact numbers is impossible though, since many nodes do not publicly advertise their existence.