I remember Satoshi's old posts where he claimed that Bitcoin Core was the only viable full implementation of the Bitcoin protocol since it had too many quirks to be efficiently standardized and reimplemented. I wonder if that's still true.
Then, if you require P2P protocol compatibility, I would say this issue shows that nobody really cares about alternate implementations: https://github.com/btcsuite/btcd/issues/1661
When Btcd was first released, it was pretty capable, and had lots of development. But it has fallen behind, which makes sense. Why would anybody take the risk of trusting that an alternate implementation when it doesn't decide what bitcoin is, in the end? You may have to patch bitcoind a bit to get your desired interface, but that is much less work than maintaining a full P2P and consensus layer.
It is also dangerous to use you a non-standard crypto library. Check this vulnerability, which was caused by LND relying on the btcd project's library: https://lists.linuxfoundation.org/pipermail/lightning-dev/20...
Does that? What I see here is bitcoind adding a new feature that isn't yet implemented in btcd. The new feature uses a different extension mechanism in the p2p protocol (a new message to signal knowledge of a new feature vs using the existing version message bits in the main p2p handshake). That new version of bitcoind also hasn't yet been released, but I'd imagine that btcd will land a fix sooner to permit unknown message types being sent from its PoV.
> Check this vulnerability, which was caused by LND relying on the btcd project's library
Incorrect. The btcsuite libraries we use weren't related to the bug at all. Instead, the bug was introduced by _new_ code which attempted to convert between the fixed 64-byte signature encoding used in the LN Protocol, and the variable sized encoding used in the base Bitcoin protocol. The resulting signatures _were_ valid ECDSA signatures, but didn't adhere to an additional constraint that the Bitcoin system places on this signatures from a mempool policy standpoint. The signatures themselves were still valid from the PoV of Bitcoin consensus, in that they would be included in blocks.
bitcoind doesn't decide what Bitcoin is either: a recent consensus issue introduced for a period of times in _newer_ versions caused it to potentially fork off the "actual" chain. In this instance, btcd was unaffected along with many other implementations and earlier versions of bitcoind.
If there is any way in which different implementations of consensus-critical code behave differently for the same inputs, it can be used to split the network. If you are running a node implementation other than the majority hash-rate reference client, you open yourself up to be potentially vulnerable during the fork. This remains just as true, if not more so with staking instead of proof-of-work.
You can do things to protect yourself like run ALL implementations and shut down if a fork is detected, although properly setting that up is nontrivial and in the end what value is gained? It very, very, VERY rarely makes sense to have multiple reference implementations of consensus code.