Slashdot Mirror

← Back to Stories (view on slashdot.org)

Btcd - a Bitcoind Alternative Written In Go!

Posted by timothy on from the bang-for-the-buck dept.

An anonymous reader writes "The folks at Conformal have announced btcd, an alternative full-node implementation to bitcoind, written in Go! They have released the first of their core packages, btcwire, available for download at GitHub. As a bitcoin user myself, I love the idea of a full alternative. It will only make bitcoin stronger and more independent. This will be great for the Go community, too!"

6 of 150 comments (clear)

  1. Re:This is good for Bitcoin by Joce640k · · Score: 5, Insightful

    Yep. What the world really needs right now is a new currency whose value fluctuates like a share price.

    (Because it's based on the same premise - that it's only worth what people are willing to pay for it).

    --
    No sig today...
  2. Go! or Go? by c0lo · · Score: 5, Informative

    TFS mixes the two: written in Go! and great for the Go community
    TFA says: it's Go not Go!

    --
    Questions raise, answers kill. Raise questions to stay alive.
  3. Re:This is good for Bitcoin by Anonymous Coward · · Score: 5, Insightful

    While technically true, have you seen any major currency fluctuate over >1000% within a month lately? Ignoring what actually happens in real life does not help your argument.

  4. It's not a full node by Anonymous Coward · · Score: 5, Informative

    All they have released is a handler for the network protocol. This doesn't verify blocks, send transactions or anything else. Are the other parts closed source or do they just not exist?

    1. Re:It's not a full node by IamTheRealMike · · Score: 5, Informative

      A full node is a really, really large amount of work. I feel that lots of people don't realise this, get enthusiastic and think, "I love Bitcoin! I love Go! I'll write Bitcoin in Go" where for Go you can substitute basically any language that's fun or popular. Then they write the easy bits (like wire marshalling) and eventually the project dies around the time that it's time to implement the wallet or Bloom filtering or robust test suites. Possibly Conformal is different, we'll have to wait and see, but the feature set they advertised in their blog is very much what has been seen many times before. In particular there's no handling of the block chain, re-orgs, no wallet and they haven't got any infrastructure to test edge cases.

      One reason implementing Bitcoin properly is not fun is an entire class of bugs that doesn't exist in normal software - chain splitting bugs - which can be summed up as "Your software behaves how you thought it's supposed to work rather than how the original bitcoind actually does work". Bitcoin is highly unusual in that it implements group consensus - lots of nodes have to perform extremely complicated calculations and arrive at exactly the same result in lockstep, to a far far higher degree of accuracy than other network protocols. This means that you have to replicate the same set of bugs bitcoind has. Failure to do so can lead to opening up security holes via consensus failure which can in turn lead to double spending (and thus your users lose money!).

      Being compatible with the way bitcoind is written (bugs and all) may require you to break whatever abstractions you have introduced to make the code cleaner or more elegant or whatever reason you have for reimplementing Bitcoin. Here's a trivial example - signatures in Bitcoin have an additional byte that basically selects between one of a few different modes. It's actually one of three modes plus a flag. So a natural way to implement this is as an enum representing the three modes plus a boolean for the flag. But that won't work. There is a transaction in the block chain which has a sighash flag that doesn't fit any of the pre-defined values (it's zero) and because Satoshi's code uses bit testing it still works. But if you turn the flag into an enum, when you re-serialise the mode flags you'll re-serialise it wrong and arrive at an incorrect result. So you have to pass these flags around as integers and select via bit testing as well.

      Bitcoin is full of these kinds of weird edge cases. Eventually you come to realise that reimplementing it is dangerous and probably whatever benefits you thought it had, it probably doesn't. Some people believe there should be independent reimplementations anyway and I can understand and respect that, but doing it safely is an absolutely massive piece of work. You have to really, really, really believe in diversity to do it - the features of language-of-the-day aren't good enough to justify the effort.

  5. Re:Better than fiat currencies by fuzzyfuzzyfungus · · Score: 5, Insightful

    Given the (currently tiny) market for goods buyable with bitcoins, their 'value' is heavily dependent on the health of the exchanges where you can cash out into some other currency.

    Incidentally, those exchanges appear to get hacked and/or DDsSed every couple of months...

    With the GPU, FPGA, and ASIC miners either online or coming-real-soon-now, bot-herding in order to outcompete honest nodes is a substantial computational challenge, CPU miners are just too pitiful; but it would seem that the real weakness to exploit is the (much softer) underbelly of conventional web infrastructure and the price swings that attacks on that part of the bitcoin economy can create.

    The trade between bitcoins and USD looks sort of like the buying and selling of stock, in a world where it's totally normal for the NYSE to be firebombed multiple times per year...