Case and point as to why there shouldn’t be multiple competing implementations for a protocol that is extremely sensitive to consensus divergence. You don’t want civilizational money to grind to a halt due to consensus differences between competing implementations.
Discussion
Someone should package all these consensus rules into a library. 🤔
omg rekt, why no lightning address nostr:npub1ryfdh0pyjyp4kx3hdv9v73algvw4pr49unkw5ez0lfunzxzflfws79rg5z?
omg you are the charlatan. Senpai noticed me!
I was being facetious. =P On behalf of all bitcoiners thank you for the work you do. 🧡
gross. it's written in Go. should have written it in Rust...
also, why does it seem like the Go impl's of things break more? (LND...)
As a person who literally doesn’t understand anything that’s written in this link.
I read chain split, lightning nodes down, people sending fake bitcoin from different chains to each other and I shat my pants. 😅
I now need wiser Bitcoiners to tell me nice things. 🤣
Bitcoin core has felt out of consensus with itself a couple of times. I guess we should use one single version of core for everything and never update.
If the consensus rules cannot be cleanly separated from the Bitcoin Core implementation, and "the code is the spec", then that is a design flaw. Appealing to the consequences of consensus failure in order to justify this flaw is backwards. I don't blame other teams for at least trying.
BGP is a networking protocol which is also consensus-driven (the global routing table for IP networks) and it has had major issues, which required upgrades and config fixes, but it works okay and has multiple production ready implementations. This is despite the first draft literally being written on napkins. We should learn from BGP and other protocols to inform Bitcoin network development rather than spurn the ideas of specifications and standards entirely. I'm not saying technical specifications are always amazing or that a project without one is awful, but any spec is better than no spec.