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!
OTOH, it was a really big bug
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;
Either this should be put into the bitcoin specification or not accepting any size should be seen as a bug. There should not just be an unofficial consensus that "this is what should be done"
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.
I was wondering that - if there is now a fork in the blockchain, with some groups going in one direction and some in another, does that mean that if this isn't resolved very quickly then bitcoin holders now have twice the number of bitcoins, an initially identical set on each fork?
I guess one fork would become the accepted fork, and hte other one would wither - but until that point, people could conceivably spend both forks with whomever accepts either one?
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.
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?
> 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.
The dollar has one significant difference: the government requires that you use it to pay taxes. This forces nearly everybody to value the new dollar, which forces everybody to move to it.
Go green: turn off your refrigerator.
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.
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.
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".
1 our synching time. With hardly anyone using it. And the number of transactions won't grow liear when the user base does so.
Sorry, but this system has severe scaling issues.
bickerdyke
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 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.
(Emphasis mine)
Good thing that bitcoin isn't actually a currency; if it was anything other than a mere item of barter, the consequences of people suddenly not knowing which cash is good and which is not would indeed be severe.
I'm a minority race. Save your vitriol for white people.
Thanks for the explanation. Now, how about you ask your employer to pay me your last month's salary? It's OK, no money is lost.
If you were blocking sigs, you wouldn't have to read this.
At some point miners will need to switch to 0.8 too.
I don't think it's feasible to get everyone to upgrade at once and miners switching to 0.8 gradually would just cause a repeat of the problem we are having now.
What i'd think needs to happen is a new version be put out that says "big blocks are only valid after block x" and then all exchanges and a sufficient proportion of miners need to be persuaded to upgrade to that new version before block x hits.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
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?
This sort of thing was solved a long time ago, but because it's "old", people just dismiss it out of hand.
It's called versioning the protocol and having compatibility lists. When two clients connect, they exchange version numbers and if one is too old then the newer one performs additional checks to verify compatibility. If the issue is reconcilable then it aborts the connection with an error. Or programatically enforce that the older version is discontinued and that anyone who is using it can no longer participate in the chain.
I apologize if I sound exasperated and holier than thou... actually, no, I don't. How the hell do people design a system that they intend to be the backbone of a major financial system but fail to accommodate for such things? It is nothing short of stupidity and incompetence.
If a major bank tried to pull this sort of nonsense, they'd be bankrupt so fast that the stockholders would have whiplash.
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 problem is that not enough users have upgraded to the replacement yet
This sounds like a horribly broken cryptosystem: your security depends on how many other users of the system have upgraded to a new version of some database?
They'll have to upgrade sooner or later though.
According to whom?
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 security was never broken
If the system "forked" the security against double spending is broken. Can I spend money I accumulated prior to the fork on both networks? If money is generated in one network, can I use it on both networks simultaneously?
In general, a digital cash system should not permit one unit of value to be spent by more than one party simultaneously.
Palm trees and 8
The Weimar republic and Zimbabwe suffered massive inflation, not deflation.
The problem is that there's no way to get 100% of the userbase to either upgrade to 0.8 or downgrade to 0.7 instantly. However, since the new version accepts everything that the old version does it was possible to mend the fork merely by getting enough people to move over to 0.7 and start mining on that fork. Eventually the 0.7 side of the fork became longer than the 0.8 side at which point all the clients running Bitcoin 0.8 recognised it as the correct version of the blockchain and everyone was working from the same version of history again, so it didn't matter if a few people were still using the wrong version of the client. Doing this the other way around wasn't possible because the 0.7 clients couldn't ever switch to the other side of the fork no matter what happened.
The security was broken. Suddenly, an attacker had the ability to easily spend the exact same set of coins twice, violating one of the key security properties Bitcoin was meant to have.
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.
People would merely convert to EuroDollars as necessary. Kind of like how the US Dollar was far more useful in many markets than the local currencies. I think for a while there in East Europe (it may have been the Soviet Union at the time) it was preferable to do transactions in USD rather than, say, the Rouble. That doesn't mean that the Rouble didn't exist, but no one wanted to use it. It'd be the same situation: people would use EUR only when necessary, and keep the rest of their money in the preferred currency.
Rawr
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.
Sounds like a currency fork. You could conceivably end up with two currencies. Which raises the question: what is to stop groups of people (say China) from creating parallel systems?
If the answer is nothing, BTC is wide open for undermining by fragmentation.
A technical error should not introduce "little opportunity" for malfeasance. When my bank has a glitch, the cash in my wallet does not turn worthless for "a few hours".
Yeah but when your bank is the largest in the country and goes down for an entire week, you run out of money in your wallet way before the glitch has passed. But apparently that isn't enough to sink the government owning the bank (wasn't their fault anyway) or the currency.
In the real world, with banks with buggy software, credit card companies and paypal with dubious and opaque policies, in practice a short outage of bitcoin doesn't really register as a world ending thing.
Oh and, of course, you're forgetting about forged currency. Real hard to spot when you've been given it, until the next merchant won't accept it.
SJW n. One who posts facts.
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.
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
How is it experimental when anyone anywhere can use it? FOr that matter what's the experiment? What are the metrics being collected? Whats the control? How will you know if the experiment is a success? If it is a success do you go back and start the non experiment on its own with the lessons learned? I would say that when people are trying to convince everyone to embrace it it is no longer an experiment when it is being used outside of a controlled environment.
If it was named Google Coins Beta (TM) you never would have posted that.
Wait, so Bitcoin is decentralized and distributed but requires all clients to remain in lockstep with each other? Nope, can't foresee any problems with that model...
Chelloveck
I give up on debugging. From now on, SIGSEGV is a feature.
If I have already completed a transaction, with cash in hand, that transaction must not be "most likely" legitimate. It must be legitimate from the very moment that I verify the currency that I received as legitimate. It must not pass verification, then "most likely" have to pass verification again.
I guess you've never deposited a check into a bank, only to have it come back on you for insufficient funds?
'The tyrant will always find pretext for his tyranny.' - Aesop's Fables
The security was broken. Suddenly, an attacker had the ability to easily spend the exact same set of coins twice, violating one of the key security properties Bitcoin was meant to have.
How would an attacker do that and still have both chains validated?
'The tyrant will always find pretext for his tyranny.' - Aesop's Fables
That depends on whether there is a managed or unmanaged breakup of the euro. "Your euros don't actually exist anymore" may not be that far from what happens in some scenarios.