Multiple versions of the bitcoin client began failing this week, after a rogue transaction stopped users from restarting the software.
The problems first surfaced early Monday morning US time, with a message on the Bitcoin Talk forum.
“Just opened my laptop and started Bitcoin QT and received the message blockchain corrupt, I clicked OK and now it appears “Reindexing blocks – 204 weeks,” said the poster. “Also, my Bitcoins are Unconfirmed. What happened, why the message?”
Others quickly reported the same error on multiple computers, running different versions of Bitcoin-QT, which is the standard graphical user interface (GUI)-enabled version of the bitcoin client. Reindexing the blocks using the bitcoin client failed to solve the problem. The same problem affected Bitcoind, which is the non-GUI-based version of the client.
The problem was a result of a bug originally introduced in version 0.8.0 of the bitcoin client, which was first released in February. That version was a major release, which switched the database used to store the block chain from Berkeley DB to LevelDB, to solve a security problem.
“It is a bug in our code that checks for LevelDB database inconsistencies introduced when we switched to LevelDB storage in the 0.8.0 release, combined with a bug that checks the version number in transactions,” said Gavin Andresen, chief developer. “A transaction with a bad version number triggered the problem.”
Gregory Maxwell, another member of the core developer team, posted a workaround for the problem yesterday morning. He explained to CoinDesk that since 0.8.0, the software has stored transactions with negative version numbers incorrectly in the local version of the block chain.
“This incorrect behaviour is, by itself, harmless and until yesterday there had not been any transactions with a negative version.”
However, on Monday, such a transaction was released, and stored in the client. Because the software enforces a rigorous database consistency check that runs whenever it is started, it refused to start after these transactions were included in the chain, he said.
Neither Andresen or Maxwell said that they had seen any evidence of significant network disruption. Andresen pointed out that it doesn’t affect the biggest, critical pieces of network infrastructure such as mining pools, merchants, or exchanges, because they tend to keep their bitcoin software running, usually with multiple nodes.
“Since the issue is easily worked around (once you find instructions) I suspect this means that it is likely a much bigger source of frustration than it is an actual disruption,” Maxwell said.
So, where did the transactions come from? Maxwell traced them to some reused addresses. He pointed to a bitcoin wallet developer, whose software was failing to initialize the version before sending a transaction. “This is a difficult mistake to make, especially in C code,” he said, adding that the wallet’s Github page is now offline. “Perhaps he took it offline due to this bug.”
The bug may have been merely frustrating, but it also shows how network attacks can be mounted – even inadvertently and non-maliciously – by simply serving up a transaction that confuses the system thanks to a long-standing bug. In this case, it was simply a malformed transaction, warping a piece of data that was not actively used by the bitcoin client.
“If the error had been in something that was used, it would have been a very serious fork-creating bug,” Maxwell said. This would require a corresponding vulnerability in the code, however.
The core development team is now working on a fix. “Once we’re confident we have a good fix and the problem can’t be triggered in some other way, we’ll release a 0.8.5 version,” Andresen concluded.