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.
640K would have been enough for everyone.
Why achieve 'consensus' when we could let the fork fester, and have two virtual currencies floating wildly against one another as well as USD?
In fact, why not introduce Bitcoin-0 through Bitcoint-Aleph and let them fight it out? I'll bring popcorn!
Nobody said that anyone involved in Bitcoin actually knew what they were doing.
Finally had enough. Come see us over at https://soylentnews.org/
Why achieve 'consensus' when we could let the fork fester, and have two virtual currencies floating wildly against one another as well as USD?
In fact, why not introduce Bitcoin-0 through Bitcoint-Aleph and let them fight it out? I'll bring popcorn!
BitCoin Bailey: No, no, no, everybody remain calm. We'll get through this together. You're thinking of this virtual currency all wrong. As if I had the BitCoins back in a safe. The money's not here. Your money's on Bill's computer, and Fred's computer ...
Angry BitCoin User: Hey Fred, what the hell you doin' with my BitCoins?!
*a run on MtGox ensues*
My work here is dung.
Bitcoin is a virtual currency that works by "doing work" (a complicated mathematical "puzzle") on your computer. It becomes a currency by the difficulty of the puzzle, and that when you have solved it you tell other BitCoin users about your success and it goes into a "chain".
That chain is the history of EVERY transaction performed on the BitCoin network and the integrity of the system is given by every user relying on the same chain - so trying to create some extra BitCoins or a fake transaction requires compromising a lot of machines around the globe to believe it happened.
Because of a stupid bug that nobody knew about related to the size of a transaction in this chain, a transaction that's too big for older clients to handle was (legitimately) created. Older clients can't handle it, so they have no idea what to do when it comes into their chain updates. Newer clients can handle it, but can't synchronise their chains with older clients because of it (they can accept the transaction whereas older clients don't).
Because the chain is now effectively split into two chains, and that all the integrity of the system comes from the fact that everyone is using, verifying and updating the same chain, BitCoin is now in an "emergency" (quoted from the forum post in the summary) situation. New clients are generating coins that old clients can't see and vice-versa, so BitCoins are being generated and lost or transacted and forgotten about.
The fix is to go back to the old code, ignore the over-size transaction, and hope to fix the code in a more backward-compatible way. Unfortunately, that requires some people on newer clients to lose coins, revert transactions, and for exchanges to shut down (temporarily) until the issue is resolved.
Basically, someone really messed up by not checking that the database could handle transactions that could pop up in the real-world.
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.
Nice explanation. Now can you explain why exactly is the preferred solution to revert to the old, flawed, code rather than updating everything to the newer code that can properly handle the larger transactions?
--- Most topics have many sides worth arguing, allow me to take one opposite you.
It's not the preferred solution.
The value of the currency is in the people who use it and most major exchanges have already reverted to 0.7, hence 0.7 blockchains are the de-facto standard at the moment. There was a bit of back-and-forth when the problem was discovered but all the large exchanges have settled on 0.7 as the standard for now.
It's like saying we're going to upgrade the dollar, and yet nobody moves to the "new dollar". The new dollar ends up valueless and everyone just stays on the old one.
The client fix is to accept large transactions but not create them - there's already code in a lot of BitCoin software to do that, but not all clients are running it - someone now has to force them to upgrade to a good version in order to stay compatible, and a lot of people might be generating coins that will later fail without knowing it.
> most major exchanges have already reverted to 0.7
Yet 0.7 is the version with the database bug.
These bitcoins certainly aren't a replacement for gold - they're far too irony.
Also FatPhil on SoylentNews, id 863
Someday, someone in some future generation will read that sentence and think, "No wonder they almost caused the extinction of the species".
You are welcome on my lawn.
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.
"except for miners who lost their reward for mined blocks on the abandoned (v 0.8) chain."
Which currently amounts to about $25,000 of BitCoins, last I heard. That's $25,000 of BitCoins that might have been spent, sent, transferred, etc. but never existed in the chosen chain and the knock-on effects on your own wallet if you're dealt with someone who dealt with someone who dealt with someone.... (ad infinitum) ... who dealt with one of those mined blocks.
Sure, it'll "catch up", but saying nobody lost out is plainly false. And isn't the point of BitCoin that everyone is a miner in some small way?
Yes. At some point everyone will have to upgrade to 0.8 and people who don't will effectively be disconnected from the system. However that needs some kind of co-ordination. The fact that there was a chain split is not the emergency, the fact that it came unexpectedly was the problem.
It's worth noting, that Berkeley DB (the one with the weird limits) was already replaced. The problem is that not enough users have upgraded to the replacement yet, and it's better to match their brokenness than diverge unexpectedly. They'll have to upgrade sooner or later though.
Miners don't have access to their reward for 120 blocks, so they never had them in the first place. The rewards will instead go to the miners in the new chain. Again, no coins are lost.
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".
It's a new fiat currency (ie. it exists because someone says it exists).
There's no reason why you, I and a bunch of our friends can't get together and say "Right, we'll use this new currency called DollarPounds, we'll use a spreadsheet to keep track of who has how many and they're exchangeable for US$ at a rate of US$1 = $£1" but the only way a fiat currency can possibly work is if you have enough people who will use it.
The idea of Bitcoin is it's a currency that doesn't require a central bank to produce more money. Instead, Bitcoins are "mined" (ie. brought into existence) through means of a mathematical algorithm that generates a verifiable block of numbers. The algorithm is designed to get harder as more bitcoins are mined. Meaning that the rate at which Bitcoins can be mined slows down eventually reaching the point where no more can be mined.
On the one hand, this resolves the "Leaves as currency" inflation problem in the Restaurant at the End of the Universe by creating artificial scarcity. On the other, they've done too good a job - as soon as it becomes impossible - or even impractical - to mine further bitcoins, the currency is likely to become subject to massive deflation. We know what happens when a currency undergoes massive deflation - Germany in the 1930's or, more recently, Zimbabwe happens.
FWIW, my view is it's probably best viewed from a distance with an air of morbid curiosity.
The very first words on their website state quite clearly that Bitcoin is an _experimental_ currency. If people choose to use it as more than that, that's their fault. Finding issues like this is exactly what Bitcoin's current purpose is.
Oh Berkley DB, is there any application you can't screw up?
Do you even know what "crypto" means? How is that in any way related to the database chosen in the implementation?
Usually, cryptosystems do not rely on things like the maximum size of atomic transactions in a database to work or to be secure in the abstract sense; it seems that in the case of Bitcoin, that is exactly what happened. This bug is not some kind of side channel attack (e.g. as you saw with Skype, where the cryptosystem was theoretically secure but where the implementation had an easily exploited side channel), it is not an implementation that leaves a secret key in some publicly accessible place, it is not a failure to properly implement the abstract cryptosystem. This is a cryptosystem whose security depends on specific implementation details.
To put it another way, imagine if instead of the database implementation, it was the CPU architecture that determined the security of the system. As long as everyone uses x86, it is fine, but if a few people start using ARM or PowerPC the system "forks." Would you trust such a system? What differentiates that hypothetical scenario from the database issue?
Palm trees and 8
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.
I see a bigger issue: the fact that the abstract security of this system is dependent on specific implementation details like which database is used or what its maximum atomic update size is. A cryptographic currency system needs to be secure regardless of how it is implemented, how many implementations there are, or what underlying technologies are chosen for those implementations. Anything less renders the system insecure and open to attack.
Palm trees and 8
Now can you explain why exactly is the preferred solution to revert to the old, flawed, code rather than updating everything to the newer code that can properly handle the larger transactions?
Because updating everything is likely to be impossible. The system relies on a distributed network of data processors that perform very large numbers of difficult cryptographic operations in the hope of randomly hitting the right answer for a cash reward (this is what is referred to as 'mining' in the summary). Because of the high rewards offered, a lot of people have invested large amounts of money into these operations, with many of the larger players using hardware built around custom ICs (if you do google searches for 'bitcoin' and then 'asic' you'll start seeing adverts for them, even if you leave it months between the two searches...). These likely cannot be upgraded to the new version trivially, as it would rely on the developers of the chips providing updates to their support software -- that is, if it is even possible at all (they may have hard-coded that 512KB block size limit directly into their design).
The Weimar republic and Zimbabwe suffered massive inflation, not deflation.
A cryptographic currency system needs to be secure regardless of how it is implemented
That's kind of an impossible standard, don't you think?
I don't care if it's 90,000 hectares. That lake was not my doing.
So if I want to buy a chewing gum with BC, every BC user would neet to create a record of that transaction?
No, every user who wants to be able to check that transactions are valid needs to create a record of it. In the event of the network becoming too large, scaling would likely happen by service providers offering to validate transactions on behalf of customers for a small fee, thus relieving customers of the need to keep a copy of the transaction list. Anyone who wants to set up such a service provider could do so with relative ease.
If this becomes too hard to manage, a further simplification can be made: it would be entirely possible to use a system that summarises the block history list, so that you only have to hold (e.g.) the last few months worth of transactions. Of course, you'd have to trust your source of summaries, but at the moment we have to trust our banks and the credit card processing companies, so we're used to trusting people like this.
What makes bitcoin not scalable on the level of a real currency is the fact that the system is designed so that there can never be more than 21 million of them. OK, they can be subdivided, but even assuming you subdivide them to their technical limit, if the amount of money represented by BTC ever reaches the scale of the amount of USD that was in circulation as of 2008, that would be equivalent to the smallest possible unit of exchange being around 30c. Over time, this figure would increase. And as bitcoin can be lost (e.g. by data loss without backup, owners dying without a record of their passphrases, or simply by people forgetting they own them) and once lost can never be recovered (except by very expensive cryptographic key cracking exercises), the number in circulation is doomed to drop over time. This will merely exacerbate the problem.
Imagine your employer operated on a scheme were instead of paying all of their employees every month they randomly picked an employee and gave them the entire month's pool every time. Now imagine the result of that random selection was ambiguous due to, say, nobody having noticed that two people had picked the same lottery numbers. They then decide arbitrarily in favour of one employee over the other. Does it sound as much like they've lost now?
Also: miners should be well aware that they aren't guaranteed to receive the bitcoins even if they do successfully produce a signed block. The system is designed to cope with the fact that such chain forks may occur and to resolve them automatically by checking which chain is longest. It's part of the protocol that they signed up for from the very beginning, so it's hard to argue they were in some way cheated.
You misunderstand the parent post. There was no outage -- transactions were processed as normal during the event. Only miners (i.e. people running the network for the random chance of being rewarded as recipient of newly created coins) may have lost out due to the error. Events like this were anticipated in the design, and the system has an automatic method of resolving it, which unfortunately leaves some miners out of pocket, but has no effect on general users.
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.
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.
Not even close.
You can send money now without a trusted 3rd party ... look, I'm transferring you a bajizzillion dollars right this instant in this message! Since you don't need anyone else to verify it, it must be true! Whats that? Bitcoin does require others to verify, it just doesn't have any way to confirm that those others should be trusted either ... my bad.
Email is in no way decentralized. Neither is anything else on the Internet that actually works.
Email DEPENDS on DNS, DNS is most certainly centralized. Both are then delegated to individual organizations to control, but they are in no way decentralized. You fail to understand how things you speak of work.
Email can not replace the post office either. Email can not provide me with a certified legal proof that the recipient received the message. Email'd scans of most objects aren't accepted, though we are getting to the point where we can scan checks and email them if you want to wait extra days for the bank to verify you aren't scamming them. You utterly fail to take into account all the services the USPS offers.
BitCoin solves no problem that were actual problems before BitCoin existed and introduces ones that everyone else in the world resolved via common sense thousands of years ago. You can't makeup a currency without anything backing it of value. Fiat currencies have governments. BitCoin's entire point as you put it is to not have anyone who can back it, brilliant plan.
You BitCoin guys live in a fantasy world. BitCoin is as likely to work properly as pure communism or socialism.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager