Comment by iso8859-1 | Hacker News Reader

Comment by iso8859-1 | Hacker News Reader

Parent Full thread

It would be disingenuous to claim that the Bitcoin protocol is only defined by the consensus layer.

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...

> Then, if you require P2P protocol compatibility, I would say this issue shows that nobody really cares about alternate implementations

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.

> Why would anybody take the risk of trusting that an alternate implementation when it doesn't decide what bitcoin is, in the end?

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.

Reply on news.ycombinator.com