<p>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 &quot;slippery&quot; 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.</p>
<p>Pieter Wuille discussed the challenges of defining what is consensus and what isn't on the Chaincode Labs <a href="https://diyhpl.us/wiki/transcripts/chaincode-labs/2020-01-28-pieter-wuille/" rel="nofollow noreferrer">podcast</a> in January 2020.</p>
<blockquote>
<p>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.</p>
</blockquote>
<blockquote>
<p>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.</p>
</blockquote>

CC BY-SA 4.0
2020-12-17T14:17:33.473Z
2020-12-17T14:23:48.107Z
2020-12-17T14:23:48.107Z
Michael Folkson
<p>&quot;Best-effort&quot;. Formal proofs don't help. All one can do is to write tests, like any other well-written piece of software.</p>
<p>They also maintain forks of some dependencies such as LevelDB and don't update some of them such as <a href="https://bitcoin.stackexchange.com/questions/75142/why-was-bitcoin-core-in-need-of-a-fork-of-leveldb">BerkeleyDB</a>.</p>
<p>See <a href="https://en.wikipedia.org/wiki/List_of_bitcoin_forks#Unintended_hard_forks" rel="noreferrer">What Went Wrong</a>. Especially the 2013 hardfork wouldn't have happened if they could ensure an unchanged consensus protocol.</p>

CC BY-SA 4.0
2020-12-17T12:51:43.590Z
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
CC BY-SA 4.0
2020-12-17T13:04:11.627Z
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
CC BY-SA 4.0
2020-12-17T09:49:11.517Z
2020-12-17T09:49:11.517Z
MCCCS
<p>I understand that Bitcoin consensus rules are <a href="https://bitcoin.stackexchange.com/a/61782/88390">enforced by every single node individually</a>.
However, most people run the default version of Bitcoin Core, which makes the implementations done by Bitcoin devs uttermost important.</p>
<p>So my question is in the title: how do they guarantee the implementations do not affect the consensus rules or network protocol?</p>
<p>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.</p>

<bitcoin-core-development><consensus>
How do Bitcoin devs make sure that their modifications do not affect the consensus rules or the running network protocol?
Muoi Tran
# How do Bitcoin devs make sure that their modifications do not affect the consensus rules or the running network protocol?

(Asked by: username_0 on 2020-12-17)

I understand that Bitcoin consensus rules are [enforced by every single node individually](https://bitcoin.stackexchange.com/a/61782/88390).
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.

**Tags:** bitcoin-core-development, consensus


---

## 2 answers

### Answer by username_2 on 2020-12-17. Score: 9 | Accepted answer

"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](https://bitcoin.stackexchange.com/questions/75142/why-was-bitcoin-core-in-need-of-a-fork-of-leveldb).

See [What Went Wrong](https://en.wikipedia.org/wiki/List_of_bitcoin_forks#Unintended_hard_forks). Especially the 2013 hardfork wouldn't have happened if they could ensure an unchanged consensus protocol.

> **Comments:**
> **username_0**: 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.  
> **username_2**: 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)  

---

### Answer by username_1 on 2020-12-17. Score: 5

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. username_2 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](https://diyhpl.us/wiki/transcripts/chaincode-labs/2020-01-28-pieter-wuille/) 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.


---

