Slashdot Mirror
Bitcoin Blockchain Forked By Backward-Compatibility Issue
New submitter jhantin writes "The Bitcoin blockchain has forked due to a lurking backward-compatibility issue: versions older than 0.8 do not properly handle blocks larger than about 500k, and Slush's pool mined a 974k block today. The problem is that not all mining operations are on 0.8; blocks are being generated by a mix of several different versions of the daemon, each making its own decision as to which of the two forks is preferable to extend, and older versions refuse to honor or extend from a block of this size. The consensus on #bitcoin-dev is damage control: miners need to mine on pre-0.8 code so the backward-compatible fork will outgrow and thus dominate the compatibility-breaking one; merchants need to stop accepting transactions until the network re-converges on the backward-compatible fork of the chain; and average users can ignore the warning that they are out of sync and need to upgrade."
Turns out there's an approximately 512K limit to atomic updates in Berkeley DB which were used by versions prior to 0.8. 0.8 uses a new database, allowing blockchains that old versions won't accept to be created.
Three words in and you lost 99% of your readership. Can't you be arsed to make a proper summary??
The nice thing about standards is there are so many to choose from.
How much time did this take? How much electricity was spent 'mining' ~$150 worth of BTC?
I meant to mod this as "funny" but I clicked "overrated" by accident so I'm posting a reply to negate my mod.
The forking was fixed within a few hours. Mining pools were notified of the issue and alerted to the recommendation to revert mining activity back to 0.7.x, which was a simple fix to grow a blockchain compatible with all mining pool Bitcoin versions. The majority of miners ignoring the incompatible fork (which caused a "Lock table is out of available lock entries" database error on Bitcoins compiled against certain BerkeleyDB libraries), let the new fork grow longer and all is fixed.
Almost all transactions are expected to be included in the new chain, so there is little opportunity for malfeasance. If you sent someone money for goods, your transaction sending money will likely be in both the new chain and the old.
No because the morons who created it did not understand what they were doing. If you don't know the limits of the DB you use why would I trust you to create a digital currency?
Well, I read the article and still don't understand Bitcoin, the concept or the need for it. Just seems like a product without a real need other than the idea of being subversive. But perhaps I don't understand it at all. Of course that's why I come here.... So if any /.ers can explain this, I'm sure others would appreciate it as much as I would.
It's a decentralized, trustless value storage and transfer protocol that allows you to send or receive value to anyone on the internet without the need of a third party. It has the potential to do to banking what email did to the post office.
You can still get robbed when the money transmission service has no central authority, it just works in the other direction. PayPal has the ability to reverse charges that it shouldn't reverse, whereas BitCoin does not have the ability to reverse charges that it should reverse.
Customers like the ability to reverse charges under appropriate circumstances.
I think its fair to say that while forking code may be a good idea most of the time - when its code running a virtual currency its a very BAD idea.
This isn't a code fork, it's a block chain fork" caused by an incompatible version update. That said, I agree with your assessment that it is not suitable for storing wealth unless you are prepared to take risks. To be fair bitcoin describes itself as ".. an experimental, decentralized digital currency".
No, Steam never accepted BitCoin; I don't know where you got that from.
There was some reseller that would sell Steam codes for BitCoin; you would pay him and he would buy a Steam game with dollars and then gift it to your account. I don't really know what the point of that was supposed to be, or if it's still a thing.
If a large enough percentage of people stopped accepting the Euro tomorrow, it would be just as dead.
Tell that to governments that use firearms to compel payment of tax in euros in the days between when "a large enough percentage of people stopped accepting the Euro" and when the people have a chance to elect legislators who will amend the tax statutes to reflect this. See fuzzyfuzzyfungus's post about the "lead standard".
The security was never broken and does not rely on the database specifics. Compatibility was broken. Security was not.
A better analogy would be like having a system that uses SHA-1 to hash passwords using a hardware chip....then they make a new version whose chip only does SHA-512. Everything is still as secure as it was, but you would no longer be able to transfer the output between devices.
Dont use Bill Gate's lines
He didn't. Bill Gates never said that.
Yes.
Branches are a part of the protocol, they are mostly natural. That's why it's recommended to wait for confirmations for higher value transactions. However long branches should be very improbable and this software glitch broke this condition. Even so, since the protocol is built on this, all transactions from the orphaned chain are carried to to the one selected by the highest hashing power. Valid transactions are not lost and double spends are invalidated. However, as you said, a careful attacker can do a double spend far more easily during such a long fork.
If you'd like to live in a ditch and swap dead squirrels with other people, you're free to do so.
If you do so in the USA, then the US government will still require that taxes be paid in US dollars on the transactions.
I am TheRaven on Soylent News
I can't claim that the bug is not a stupid one, but I don't think your solution would have saved it. It was really an unknown problem at the database layer and it would be decided as reconcilable anyway. And it's at a specific level in the network architecture; clients were never incompatible and transactions were being relayed just fine.
Furthermore, you don't want any method to top-down enforce anything on a network like Bitcoin. Actually a wider variance of software increases network's resilience.
If a major bank tried to pull this sort of nonsense, they'd be bankrupt so fast that the stockholders would have whiplash.
Well, Bitcoin is not a major bank though. Bitcoin's market cap is probably much lower than a major bank's janitorial costs.
My wife is the manager of an operations branch of a major bank, and snickered at your comment though. What I gather is, this sort of nonsense happens all the time in major banks too, but they have several layers that keep it going even if some part is broken. Bitcoin, as a greater structure, isn't quite there yet.
You obviously don't hang out on IRC with the developers. DHT's come up so often and are such a bad idea that the term coming up at all in a conversation is considered an inside joke. "Oh I know, lets add a DHT to it!"
Long story short, if you share the set of unspent transaction outputs in a DHT you have to trust every other computer in the network to actually return the DHT data when requested, or you suddenly you can't validate a block. This opens Bitcoin up to dangerous DoS attacks against miners, as well as network forks and other problems.
It's a total non-starter, although a common "newbie" idea.