I'd be interested to know about these supposed btcd mainnet forks that have occurred due to a consensus failure since it came out of alpha. I'll go ahead and save you some research time - there hasn't been one. I'm not claiming there will never be one as that would be just as foolish as claiming Bitcoin Core won't have any more either. As you alluded to, there was a _potential_ instance found due to fuzzing which prompted a thorough audit of the code base. It was fixed before any problems occurred and resulted in improved test coverage in Bitcoin Core as well. On the other hand, Bitcoin Core has had actual forks on mainnet during the same period. I'm not casting stones at Bitcoin Core here, because as I've said many times, none of us are perfect. No matter how careful everyone is, it is bound to happen from time to time. Until this community decides to get serious about facing the reality that an infrastructure built on a single implementation with no real disaster prevention measures for unintentional incompatibilities between different versions of that implementation is incredibly fragile, there will continue to be more unintentional hard forks regardless of the existence of alternative implementations. It has not ended poorly by any means. It has already led to several improvements such as improved test coverage and more robust and modular code. On 9/1/2015 6:11 AM, Monarch via bitcoin-dev wrote: > That would be incredibly foolish given the history, where even heroic > attempts at making consensus compatible re-implementations have ended > rather poorly. bitcoin-ruby and btcd have collectively had numerous > consensus failures, some only recently found by fuzzing the scripting > environment. There are more failures than publicly disclosed, and > almost any failure can be leveraged to split the network and steal > money. Ethereum attempted to create four clients, written to a > defined specification, and even with all the money in the world has > managed to have numerous consensus failures due to misunderstanding or > implementation.