Double Spending Risk Remains After July 4th Bitcoin Fork

The delayed implementation of a Bitcoin Core update by a small number of the network's miners resulted in the addition of invalid transaction blocks to the bitcoin blockchain this weekend.

The result was a fork in the network that created two versions of the bitcoin blockchain, which continued for six blocks on 4th July. An additional three invalid blocks were added to the blockchain in a repeat of the issue the following day.

As a result, Core developers issued a warning on Bitcoin.org requesting that wallet providers place increased scrutiny on incoming transactions due to the risk that funds could be double spent as a result of the discrepancy between chains.

The post, which is still live on the website, is advising these entities wait an additional 30 confirmations before considering transactions valid.

Root of the problem

At the heart of the issue is arguably the decentralized nature of the bitcoin blockchain and the degree of control over which its participants have in how they contribute to the verification of transactions on the digital currency's distributed ledger.

This ability for users to have some control over how they interact with the network, for example, results in miners being able to neglect software changes and for the network to carry on even if they do.

As a precaution, Core developers have taken to waiting for a majority of the miners to implement changes. In this case, BIP66 – a bitcoin soft fork designed to make the network less dependent on OpenSSL's signature parsing – stated that certain transaction blocks created without this update would be considered invalid once the majority – 950 out of 1,000 blocks – were mined with the latest version.

In theory, the risk of an issue was low, with only 5% of the network running the outdated version of BIP66. However, in practice, three pools running light versions of software elements were able to process six consecutive blocks that should have been invalid, creating two versions of the bitcoin blockchain, the longest of which was operating on an older software.

In this case, certain mining pools were SPV mining, meaning that they were not validating the full version of the bitcoin blockchain. In turn, these invalid blocks were being considered valid by bitcoin wallet providers and block explorers running SPV versions of software as opposed to full nodes with the entire history of the ledger.

Fabio Federici, CEO of blockchain intelligence provider Coinalytics, explained to CoinDesk:

"SPV clients were claiming they would follow the BIP66 rules, but they were not actually enforcing them. A big part of the mining network is not running on full nodes, which would validate every transaction."

Though initiated by F2Pool, should the other mining pools have been running a full node to process the entirety of the bitcoin blockchain, invalid blocks should have been more quickly detected.

Common consensus

Though not unusual with software updates, the situation was noteworthy as the invalid block was subsequently built upon by the larger mining network.

Peter Gray, founder of bitcoin developer API Coinkite, noted that issues with software updates are common, resulting from the continual upgrades being made to the payment network.

"I think it's useful to remind people that forks happen every week on bitcoin. Typically only a single block gets orphaned in a typical week, and it's not a bug or attack or anything; just the way bitcoin works," Gray said.

Mining firms that solved invalid blocks lost income as a result of the need to correct the issue, with Bitcoin.org estimating that $50,000 in revenue was effectively withheld from F2Pool, AntPool and BTC Nuggets, the three mining pools that effectively created and briefly propagated the invalid chain.

Rewards were ultimately never paid as the 25 BTC winnings per block was sent to a bitcoin wallet that invalidated the blocks after syncing with the valid chain.

After effects

In its warning, Bitcoin.org, said customers whose bitcoin transactions were confirmed before midnight (UTC) on 6th July have not been affected by the glitch, though transactions carried out after this time are believed to have "significantly less reliable" confirmation scores.

Bitcoin.org explained the confirmation of invalid blocks is due to software clients not upgrading to Bitcoin Core 0.9.5 or later and warned that lightweight wallets using SPV and web wallets were particularly vulnerable to the bug.

Warning the issue remained unresolved, Bitcoin.org urged users to "wait 30 more confirmations" than usual before accepting a transaction as valid. It also recommended that miners switch to a pool that validates transaction blocks using a full node and that individual miners use Bitcoin Core 0.10.2.

As for larger takeaways, those who provided comment suggested the event should be used as a reminder of the need for key bitcoin network participants to run full nodes.

"The key takeaway is the distribution of full nodes versus SPV nodes. Everyone should run a full node, and maybe it doesn't make sense economically or there are other benefits of an SPV client, but that comes with the risk," Federici continued.

Yessi Bello-Perez contributed reporting.

Fork in road image via Shutterstock