Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Bitcoin Bug IT

Bitcoin Blockchain Forked By Backward-Compatibility Issue 351

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.
This discussion has been archived. No new comments can be posted.

Bitcoin Blockchain Forked By Backward-Compatibility Issue

Comments Filter:
  • Old news. (Score:5, Funny)

    by NettiWelho ( 1147351 ) on Tuesday March 12, 2013 @08:06AM (#43147519)
    640K would have been enough for everyone.
    • Re:Old news. (Score:5, Insightful)

      by Anonymous Coward on Tuesday March 12, 2013 @12:00PM (#43149645)

      You laugh, but some of the developers, the lead developer Gavin, and another core developer Mike Hearn, are pushing really hard to get the current 1MB limit (7 transactions/second) on blocks lifted so Bitcoin can directly scale to VISA-like volumes.

      Never mind that Bitcoin is inherently an unscalable O(n^2) network - every transaction has to be broadcast to every node - and the issue they ran into was also a problem scaling. Mike's solution is to just throw thousands of dollars worth of hardware [bitcoin.it] at the problem. Never mind that for Bitcoin *any* issue the means that some nodes can process a large block, and some can't, turns into the same hard-fork we just saw. Never mind that it will make Bitcoin centralized, and lead to perverse incentives [bitcointalk.org] for large miners to attack smaller ones.

      You'd think they'd say "OK, hold on, how about we just use ways to transfer funds that don't have to go into this shared state ball of mess?" but no, they're desperate to take the easy way out at any cost.

      I really wonder if my Bitcoins will be worth anything in a few years.

      • Re:Old news. (Score:4, Insightful)

        by DamnStupidElf ( 649844 ) <Fingolfin@linuxmail.org> on Tuesday March 12, 2013 @03:17PM (#43151795)

        Never mind that Bitcoin is inherently an unscalable O(n^2) network - every transaction has to be broadcast to every node

        It may be possible to store the block chain as a distributed hash tree such that each node is responsible for maintaining its own transactions and a portion of the block chain. This would reduce the storage requirement to O(n*m) where n is the total number of transactions and m is the average number of addresses that appear in a transaction. Communication would also be reduced to O(n*m) because only nodes responsible for the addresses in a transaction would be responsible for checking and approving the transaction. The block chain itself would just be a merkle-tree of hashes of nodes' own block chains. Double-spending would be prevented by transactions incorporating the last hash of each responsible node's block chain so that an individual block chain exhibiting double spending would not be signed into the merkle tree. It would be possible for the history of particular coins to be lost but the overall hash tree would guarantee that at the time of a transaction all balances (including historically lost ones) were valid. Still, not being able to validate the entire economy could be a fairly large weakness. There wouldn't be a hard requirement that nodes could only store certain addresses, so it's entirely possible that some nodes would still try to collect and maintain the entire history. That would only add O(n*p) communication and storage where p is the number of full "archive" nodes. Of course then it wouldn't really be bitcoin anymore, but it might be possible to rebuild the existing block chain into such a structure while retaining the current mining payouts and total number of coins.

        I really wonder if my Bitcoins will be worth anything in a few years.

        Something, because there will always be some core of crazy people running miners and keeping the difficulty just high enough that it's not worth it to mine as many bitcoins as you want in the original chain. That value will probably be the cost of the electricity to run whatever the last ASIC miner produced is, at least before general purpose GPUs become more powerful than ASICs.

      • Re:Old news. (Score:5, Interesting)

        by IamTheRealMike ( 537420 ) on Tuesday March 12, 2013 @03:46PM (#43152059)

        Is that you Peter? :) I don't know anyone else who would describe the system like that.

        Bitcoin is not an O(n^2) network. The total work done by the core nodes is "number of nodes multipled by number of transactions" - that is two very different quantities. It doesn't help the argument to abuse formal notation like that.

        Pieter reported today that his optimized secp256k1 implementation can reach 20,000 signature checks per second on a single core. That is a lot better than the generic OpenSSL code was able to manage. Bear in mind that although it sounds scary, all of VISA is only about 10,000 transactions per second. So even if we're generous about our assumptions on number of inputs, CPU load would barely stress a single core. Today. With existing hardware. Disk IO will be the bottleneck for the forseeable future, but we're talking about a working set of a few hundred megabytes today. Even with an order of magnitude growth the entire thing fits in RAM on my puny laptop. And with two orders of magnitude growth it still fits on a pretty average dedicated server.

        But Bitcoin will not reach VISA traffic loads today, or this year, or even this decade. By the time it does, dedicating one single computer to being a node will seem a completely trivial investment in order to have full security on the worlds financial system, because let's face it, if Bitcoin is processing tens of thousands of transactions per second then it's well on its way to being exactly that.

        Ultimately, Bitcoin is growing fast and will scale up. That is what Satoshi wanted it to be, that is what most of the people actually creating businesses and writing lots of code also want - so if you think that'll make your coins worthless in a few years, I will happily buy them off you.

        -Mike Hearn

  • by fuzzyfuzzyfungus ( 1223518 ) on Tuesday March 12, 2013 @08:08AM (#43147525) Journal

    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!

    • Re:Ooh, exciting! (Score:5, Informative)

      by 0100010001010011 ( 652467 ) on Tuesday March 12, 2013 @08:19AM (#43147593)

      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?

      • How much electricity was spent 'mining' ~$150 worth of BTC?
        At a guess, around $20.
      • Bitcoin cash: $150

        Electricity spent mining cash: $20

        Breaking everyone's favorite geek currency: Priceless

    • by eldavojohn ( 898314 ) * <eldavojohn@noSpAM.gmail.com> on Tuesday March 12, 2013 @08:21AM (#43147609) Journal

      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 [arstechnica.com]*

    • by DrXym ( 126579 ) on Tuesday March 12, 2013 @09:52AM (#43148253)
      Just to get the ball rolling...

      Post 0.8 users - if you fuck over the people on the earlier bitcoin format, the value of your bitcoins effectively DOUBLES!

      0.8 and prior users - if you fuck over the people on the later bitcoin format, the value of your bitcoins effectively DOUBLES!

      Just ask yourself what Ayn Rand would do in the same situation.

      • Re:Ooh, exciting! (Score:5, Insightful)

        by julesh ( 229690 ) on Tuesday March 12, 2013 @10:30AM (#43148651)

        Just ask yourself what Ayn Rand would do in the same situation.

        Die in penniless poverty while dependent on the state to provide basic income and medical facilities that are necessary to maintain her life, all while maintaining that such a system is inherently evil? It's what I like to think of Ayn Rand doing in *any* situation.

        • Re:Ooh, exciting! (Score:4, Insightful)

          by sjames ( 1099 ) on Tuesday March 12, 2013 @03:12PM (#43151755) Homepage Journal

          Just what would happen if the great and powerful architect decides to go it alone? Well, the bricklayer, the carpenter, the plumber, and the electrician build some houses following the well developed rules of thumb and then go have some beers while laughing at the architect as he tries to figure out how to rivet....

      • by RMingin ( 985478 )

        Actually, you didn't RTFA. Only one block is in dispute, all other blocks remain valid for both groups. Also, 0.8 is post behaviour, not pre.

        So;

        0.8 and later users - If you fuck over the people on the earlier bitcoin format, the value of your bitcoins effectively remains exactly the same!

        Pre 0.8 users - if you fuck over the people on the later bitcoin format, the value of your bitcoins effectively increases by a very small amount, less than 1 percent!

        Far less exciting. Sorry to burst your rant bubble.

    • by bondsbw ( 888959 )

      I don't see a problem with multiple virtual currencies. In fact, if virtual currencies ever come to dominate traditional currencies, I would not want a single virtual currency to exist.

      Like anything that deals with economy, diversity brings strength. Relying completely on a currency that is a major exploit away from bringing down the global economy would be a disaster waiting to happen.

  • by Anonymous Coward

    OTOH, it was a really big bug

  • by Chrisq ( 894406 ) on Tuesday March 12, 2013 @08:14AM (#43147563)

    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"

  • You need to stop buying stuff until the "currency" (and I use that term very loosely when talking about bitcoin) is valid again? Good thing it isn't used exclusively by anyone, else they'd now be starving.

    • 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?

      • Re:So what now? (Score:4, Informative)

        by gox ( 1595435 ) on Tuesday March 12, 2013 @11:51AM (#43149541)

        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.

    • by qubezz ( 520511 ) on Tuesday March 12, 2013 @08:34AM (#43147673)

      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.

      • 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)

        • "A few hours" outage fails the most basic test of a currency - ability to spend it. For a few hours, no merchant could accept bitcoins as payment.
        • "Incompatible fork[s]" causes bitcoin to fail yet another basic test of currency. The population should never be able to fork their currency into "new dollars", "old dollars" and "something which is most likely, in almost all cases, a mixture of both".
        • A technical error should not introduce "little opportunity" for malfeasance. When my bank has
        • 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 compan

        • 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?

  • It seems that good ol' Bitcoin is having problems scaling up to meet the new demand for cryptocurrency. Perhaps we should start looking into alternate cryptocurrencies like Litecoin instead?

    • Actually it doesn't have a problem, since it's already solved.

      Now, please tell me how some users switching to a completely different cryptocurrency would solve your perceived problem with forked bitcoins?

  • So the currency that is supposedly based on crypto winds up forking into two different currencies because of a database update? Nice job guys.
    • Re: (Score:3, Informative)

      by h4rr4r ( 612664 )

      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?

      • by IamTheRealMike ( 537420 ) on Tuesday March 12, 2013 @09:21AM (#43148011)

        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.

        • 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?

      • They knew about the flaw and fixed it a long ass time ago. They just didn't realize the old clients wouldn't work 100% with the new database style, although it seems really obvious to me.
      • by betterunixthanunix ( 980855 ) on Tuesday March 12, 2013 @10:35AM (#43148717)
        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.
    • What the hell does this rambling even mean? Do you even know what "crypto" means? How is that in any way related to the database chosen in the implementation? Did you know that it's possible to base a program on both "crypto" and a database?
      • by betterunixthanunix ( 980855 ) on Tuesday March 12, 2013 @10:23AM (#43148581)

        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?

        • by Urza9814 ( 883915 ) on Tuesday March 12, 2013 @10:32AM (#43148683)

          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.

          • 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.

          • by makomk ( 752139 )

            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.

            • 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?

    • It's not even 1.0; they're very clear that it is still _experimental_; and the only reason there was a problem was because people weren't bothering to update their clients.

      In other words, if people run an outdated version of still alpha/beta-stage software as though it is production-ready...well, who's fault is that _really_?

      It's not a currency; it's not advertised as a currency; it's an experiment in how to create a currency.

  • Stonehenge (Score:4, Funny)

    by PopeRatzo ( 965947 ) on Tuesday March 12, 2013 @09:08AM (#43147877) Journal

    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.

    Someday, someone in some future generation will read that sentence and think, "No wonder they almost caused the extinction of the species".

  • Just wait until countries start pulling out of the EU.

    Then we'll have a real currency backwards-compatibility problem!

  • BDB (Score:4, Funny)

    by Richy_T ( 111409 ) on Tuesday March 12, 2013 @10:20AM (#43148539) Homepage

    Oh Berkley DB, is there any application you can't screw up?

  • by ilsaloving ( 1534307 ) on Tuesday March 12, 2013 @10:22AM (#43148557)

    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.

    • by gox ( 1595435 ) on Tuesday March 12, 2013 @12:18PM (#43149839)

      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.

  • by Coward Anonymous ( 110649 ) on Tuesday March 12, 2013 @11:25AM (#43149257)

    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.

It is easier to write an incorrect program than understand a correct one.

Working...