Hacker News Reader

Comment by bengotow | Hacker News Reader

I haven't been following Bitcoin very closely. This looks great, but I'm confused why the authors went to so much trouble to duplicate the existing daemon down to every last bug. It sounds like their architecture improves on the design of the original implementation quite a bit, which is awesome. But if they don't want to cause a fork in the Bitcoin community (by adding features, fixing bugs, etc.), what's the point of having a well written one over the poorly written one? Isn't the thing more or less a "locked" piece of software?

* I don't participate in the Bitcoin community, so I'm sorry in advance if this is an ignorant question! Congratulations to the authors - I think this is a pretty significant accomplishment regardless.

View on HN

A "fork" of the blockchain is devastating. If you are unaware you have forked from the main chain you risk double spend attacks on all of your transactions (and mined block rewards become worthless). Thus any implementation needs to follow the exact same rules (including "bugs") for determining which transactions are valid.

That doesn't mean every bug needs to be implemented. It's possible there are DOS or remote code execution bugs in one implementation but not another. Diversity between clients is a good thing. If such a bug is discovered in one client it won't take down the entire network (except currently the vast majority of full nodes use the original bitcoind implementation)

Various different architectures may have benefits too (e.x. I like how btcd is splitting the blockchain and wallet pieces into separate processes)

The original announcement page lists some of what they claim to be the advantages of the port to Go:

https://blog.conformal.com/btcd-a-bitcoind-alternative-writt...

* integrated test infrastructure

* no active memory management

* standard formatting

* platform independent code

* simpler parallelism

* virtually crash-proof

* built-in profiling and documentation facilities

From a development standpoint, I appreciate it from the concept of a clean refactor implementing current bitcoind features (vs. layered on over time), seemingly well-written and commented code, and introducing a heterogeneity to the bitcoin daemon world - making it a bit more resilient (potentially) against future attacks against the infrastructure.

Bugs in the Bitcoin protocol cannot be fixed while remaining compatible; that's why they have to duplicate them. They're not trying to preserve implementation bugs.

it is worth considering that bitcoind itself, as a single project, has created a nasty fork and may very well do so again in the future.

better code that is actually readable and commented means a lower likelihood of a bitcoin daemon forking against itself. it also means that it is quicker to maintain existing code and extend it to add new features.

Forks are a pretty big deal especially if they require action on behalf of all the people mining.

Reply on news.ycombinator.com