Hacker News Reader

Comment by mriou | Hacker News Reader

All great changes, especially BIP 70 and the fixes on transaction malleability and relaying. I'm unconvinced the efforts to make bitcoind (now Bitcoin Core Server) a "border router" are well-spent however. Software that's optimized for server deployment and larger clusters is fundamentally different from what you would run on your desktop. I personally think that Bitcoin Core should focus on the protocol and extensions to be a good reference implementation, easy to deploy in all environments.

But regardless, great job guys.

View on HN

The router functionality is very important, because bitcoin-core is the only bitcoin implementation capable of verifying transactions & blocks. The reason for this is that the bitcoin protocol, in practice, is whatever bitcoin-core implements, including any and all bugs. All attempts to fully implement bitcoin-core have all had chain splitting bugs (btcd, bitcoinj experimental full verification mode) so they are not yet trusted in production.

Unfortunately the wallet handling capabilities of bitcoin-core don't scale to high numbers of wallets. Thus as an org running a service handling many wallets, it is useful to program against a lightweight client API such as bitcoinj, and then have your client peer with "trusted" bitcoin-core nodes.

I've heard that argument many times and all it does is reinforce the idea that no other implementation can work. And how you end-up with an implementation mono-culture. Forks of a single block happen regularly, it can be dealt with. A production system can detect a fork and check the reference implementation's behavior, preventing any longer fork.

The *coin ecosystem need more than one implementation, a single codebase can't cater to all uses. I should know, I'm an Apache member.

Forks of a single block ("orphans") are expected due to block propagation taking a nonzero amount of time.

That's very different than the case where say 50% of the network is running bitcoind, and the other 50% is running btcd, and some transaction triggers an edge case in either implementation that causes one implementation to accept the transaction and another to reject it.

I think multiple compatible implementations would be great to have, but we don't have them at the moment, and in the meantime companies handling huge numbers of bitcoin transactions need a solution that works today. So I applaud the bitcoin-core team for catering to the increasingly common use case of using bitcoind only for consensus.

And it happened even only with bitcoin-core. Anyhow the 50/50% scenario across implementations is unlikely to happen if everyone seeing a new one cries forking wolf.

I do empathize with the need of solutions for today though. I was just thinking about tomorrow.

alternative implementations would mean you need consensus between different groups of developers holding the keys to the software. unlikely to be a good idea.

What chain-splitting bug did btcd have?

Here's a recent commit fixing one.

https://github.com/conformal/btcscript/commit/299dcc2fad071d...

Chain splitting bugs in btcd get fixed all the time, that's why its considered alpha quality software.

Reply on news.ycombinator.com