5 ms·
This is why the Bitcoin Core developers have been trying to factor out all of the code that affects consensus into a separate library. I think it's likely that
by pash 11y ago
This is why the Bitcoin Core developers have been trying to factor out all of the code that affects consensus into a separate library. I think it's likely that this library, libbitcoinconsensus, will be at the core of most clients in future, but its existence and maturation will also allow other clients to emerge and replace Bitcoin Core for some applications.
In your analogy, libbitcoinconsensus is like a minimal rendering engine that implements the standards and can be used by anybody to build a full web browser.
- chc 11y agoWasn't it Patrick's point that being compatible with the consensus checks is insufficient for being compatible with Bitcoin Core?
- pash 11y agoI'm not sure. His statement that all clients must be bug-for-bug compatible with Bitcoin Core is simply false. There is a big chunk of behavior that can differ from client to client without the network fragmenting and without bad consequence to the clients whose behavior diverges from the majority's. For example, clients have complete choice about which nodes to talk to and which received transactions to propagate. In fact, clients have complete choice about all functionality that depends on data that is not (or not yet) incorporated into the blockchain. That's why we have the notion of consensus-relevance. There is a lot of stuff in Bitcoin Core that simply is not consensus-relevant, and Bitcoin Core's developers intend to continue to segregate the consensus-relevant stuff from the stuff that any client is free to make its own choice about. Yes, in the future it might be true that there's a big kernel of code that every client needs to use, but that kernel will not be all of Bitcoin Core as we know it today.