Hacker News new | past | comments | ask | show | jobs | submit login

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.




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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: