4 ms·

Which for something that's meant to be maintaining consensus is a fairly stupid move.

• aaron-lebo 12y ago
  What you mean by this? Why would having multiple implementations, each having some input by core devs, be a bad thing?
  • b1db77d2 12y ago
    In a decentralized consensus every single node must have the same behavior, handle errors the same way, make the same decisions based on the same core rules. Experience with Bitcoin has taught us that nobody is currently capable of duplicating the Bitcoin behavior perfectly. Many have tried such as bitcoin-ruby (ruby) and btcd (go), but they are plagued by almost constant issues of them having different states and getting forked off the network. Starting with three different languages, three different codebases is absolute madness.
    • obscuren 12y ago
      Madness? Tackling problems (consensus, protocol, etc) early on a "stupid move"? You believe that copying bugs (as something you'll have to do if you want to create a new btc node from scratch) is something we should strive for? Having another client to fall back to if there's a bug in one of the others is, again, "a stupid move"? "Many have tried such as bitcoin-ruby (ruby) and btcd (go), but they are plagued by almost constant issues of them having different states and getting forked off the network." This is _exactly_ why you should have multiple, clean room implementation from the start. Oh btw, we've already got consensus with 3 full nodes for quite a while.
      • b1db77d2 12y ago
        Getting consensus with 3 nodes is easy. Keeping it is the hard part. You'll no doubt find that your daemons don't behave the way you'd expect cross platform, cross architecture. Come back to this post when you fork, and tell me again that I'm talking nonsense.