I understand that Bitcoin consensus rules are enforced by every single node individually. However, most people run the default version of Bitcoin Core, which makes the implementations done by Bitcoin devs uttermost important.

So my question is in the title: how do they guarantee the implementations do not affect the consensus rules or network protocol?

While I also understand that each Bitcoin version is released with extreme care and extensive testing, I keep wondering whether there exists a systematic practice for this. Any pointer would be highly appreciated.

2 Answers 2


"Best-effort". Formal proofs don't help. All one can do is to write tests, like any other well-written piece of software.

They also maintain forks of some dependencies such as LevelDB and don't update some of them such as BerkeleyDB.

See What Went Wrong. Especially the 2013 hardfork wouldn't have happened if they could ensure an unchanged consensus protocol.

  • But isn't that some behaviors of the consensus rules require interactions between clients, hence more complicated testing is required? I always think there must be some differences between maintaining the Bitcoin project versus non-blockchain projects but cannot pinpoint any.
    – Muoi Tran
    Commented Dec 17, 2020 at 12:51
  • 1
    The difference is, one does not change its P2P/consensus behavior without checking if the other client supports the newer features, while traditional server side-client side software can just breakingly update both and render older software unusable. The same thing is possible with the blockchain, however changes must be well coordinated. For example, when Bitcoin Cash was born, they launched multiple networks to check if implementations of the protocol on different bases worked together (I remember seeing a Google Sheets report about this)
    – MCCCS
    Commented Dec 17, 2020 at 13:04
  • 1
    @MuoiTran No, it doesn't really. The stuff received from the other node is input to this node. If this version of the client allows exactly the same input as the previous version did, it's compatible. Commented Dec 17, 2020 at 18:36

The long term Core contributors have a general understanding of what parts of the Core codebase touch or could potentially impact consensus between nodes on the network. However, consensus is "slippery" and there have been examples in the past where changes were made that weren't considered to be consensus critical at the time but turned out to be. MCCCS highlights some of these examples in the answer above.

Pieter Wuille discussed the challenges of defining what is consensus and what isn't on the Chaincode Labs podcast in January 2020.

One of the things I think learned from that is specifying what your consensus rules are is really hard. That doesn’t mean you can’t try but who would’ve thought that a configuration setting in the database layer you are using actually leaked semantically into Bitcoin’s implicitly defined consensus rules. You can attribute that to human failure of course. We should’ve read the documentation and been aware of that.

We can talk about the boundary in trying to abstract the part of the codebase that intentionally contributes to consensus but it is very hard to say clearly this code has no impact on consensus code because bugs can leak. I think one of the things to learn there is you really want software that is intended for use in a consensus system where not only you have the requirement that if everyone behaves correctly everybody accepts the right answer but also that everybody will agree about what is an invalid piece of data in lockstep.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.