I have the opposite reaction for the same reason. This helps formalizing the behavior of the original client and is an excellent thing for the network in the long run.

Being uncomfortable about alternate implementations makes me uncomfortable.

It's a system completely designed around gaining a consensus. Any slightly differentiation in behaviour means a fork in the chain with catastrophic network-wide consequences. Both the original creator and the current developers are typically against re-implementations, with good reason.

> Both the original creator and the current developers are typically against re-implementations, with good reason.

That is not true. Gavin Andressen supports alternate implementations. Take the following quote [1]:

"Diversity is a good thing. Diverse, inter-operating implementations of the Bitcoin protocol make the network more robust against software bugs, denial-of-service attacks, and vulnerabilities. There are several projects re-implementing Bitcoin; if you are a Java or Go or Python or C programmer who wants to see Bitcoin succeed, you should consider helping them out by reviewing, testing, or contributing patches."

He then goes on to list several alternatives, including btcd.

[1] https://bitcoinfoundation.org/blog/?p=204

Alright, it's at odds with the developers I've spoken to about it. GMaxwell cautions most developers when they attempt it, for example.

The trouble is, because the exact behaviour isn't documented and depends on subtle implementation quirks, the original implementation already has enough differences in behaviour between different versions to fork the chain with catastrophic network-wide consequences.

Exactly. In the case of the most recent fork, it was a completely unexpected implementation bug that meant that the underlying database ran out of locks, different to the more recent builds that didn't. That was caused just by differences in underlying databases, let alone a whole new verification system as we see here.

Obviously this is not a desirable property of the system. If it's going to be robust against malicious attacks, it must be robust against well-meaning reimplementations.

Malicious attacks are not the same as consensus failure.

Consensus requires agreement, malicious attacks are orthogonal, unless you're hypothesizing a malicious party introducing an intentionally incompatible node and a significant fraction of users switching to it.

What does it even mean for Bitcoin to be robust against malicious attacks? Bitcoin has no security definition, just a vague notion of what its users should not be able to do.

Yea, this is one of those things where that argument gets tricky.

On the flip side one could argue that diversification of implementations is key to the long-term success of Bitcoin. If, let's say, there is a serious issue with bitcoind that shows up somewhere down the road that causes a fork and it is the only implementation everyone is using, there will be a network-wide problem. If there are a number of implementations in the wild, the fork would be contained to a smaller subset of users, and managed accordingly.

Getting to this point of diversification safely is difficult, however, which is why I imagine some of the core devs might be against it. I remember Amir Taaki got a lot of flack when he came out with libbitcoin.

Both implementations should run in parallel, differences in behavior will show bugs in either implementation.

you can detect bugs with one running alone as well. but so what.

if i run one without the bug and accept a payment, you and millions with the bug will just say "meh. this one does not match. will just drop it" and my transaction goes out of the main block.

Some poorly-defined edge cases can only be found with alternative implementations. These are the edge cases that will cause trouble in a network with only one implementation.

I had the same reaction, but it's pretty cool that the "official" bitcoind regression test suite works on this implementation.