<p>I think you have a sense of the general idea, but I want to first address a few misunderstandings point by point first.</p>
<blockquote>
<ul>
<li>Anyone can submit a BIP that aims to change Bitcoin Core</li>
</ul>
</blockquote>
<p>Bitcoin Improvement Proposals (BIPs) are used to provide globally relevant information or propose changes to the Bitcoin protocol. Changes to single implementations such as Bitcoin Core are made via that project's repository.</p>
<blockquote>
<ul>
<li>The BIP must be approved by an editor</li>
</ul>
</blockquote>
<p>The BIP editors only ensure that a BIP fulfills certain minimum criteria, like being viable, on-topic, and complete.</p>
<blockquote>
<ul>
<li>The BIP must be voted in with 95% confidence from the miners</li>
<li>The community must upgrade to the new software version</li>
</ul>
</blockquote>
<p>BIPs that propose consensus changes must define an activation mechanism. For example Taproot used the Speedy Trial activation, which included miners signaling for readiness. Miners do not vote on proposed changes, they are asked to gauge whether they perceive the network to be supportive of the change and signal readiness to enforce a consensus change. Full nodes upgrade to signal support and to enforce the consensus change once it is activated. If there is serious disagreement among developers, community, and miners  whether something should be activated, this should be sufficiently visible in the public debate, so that a Speedy Trial activation attempt would fail.</p>
<blockquote>
<p>What should I consider or be aware of when updating to the latest software version?</p>
</blockquote>
<p>Node operators define what they consider to be Bitcoin per the software they run. If you want to support adoption of a consensus change, you should run software that facilitates the new rules. If you disagree with a consensus change, you should run software that expresses this disagreement either passively by not supporting the change or actively by counteracting it in some manner. If it's all the same, you should probably run somewhat recent software, to get access to the latest bug fixes, features and improvements. For example, Bitcoin Core's <a href="https://bitcoincore.org/en/lifecycle/" rel="nofollow noreferrer">life cycle</a> provides maintenance for the current and previous major version, older versions receive critical security fixes a bit longer, but are considered end-of-life shortly after that. Other projects have their own modus operandi.</p>
<blockquote>
<p>What are the criteria for the Bitcoin protocol to consolidate at community/network level in comparison to TCP/IP protocol for example?</p>
</blockquote>
<p>TCP/IP is maintained by the <a href="https://en.wikipedia.org/wiki/Internet_Engineering_Task_Force" rel="nofollow noreferrer">IETF</a>, an open standards organization. From what I understand the IETF standards track's RFCs  inspired the BIP process. I assume that slight divergence in adoption of protocol changes in TCP/IP would mostly cause participants to downgrade to shared mechanisms for compatibility. On Bitcoin however, consensus changes must be broadly adopted by the network to come into effect, so there is an emergent property to the process on the network level. If e.g. users run node software enforcing rules conflicting with rules enforced by other nodes, it may cause the network to split for good which can lead to the spin-off of a fork-coin.</p>
<blockquote>
<p>Are there any kind of changes which require additional caution from the network participants (full nodes)?</p>
</blockquote>
<p>Unless a new version introduces consensus changes, not usually. If you're a power user, you should glance at the release notes to see if there were any changes to RPCs you use. If any existing features get removed, this usually happens in steps over multiple major releases.</p>

CC BY-SA 4.0
2022-03-07T18:52:29.850Z
2022-03-09T01:54:56.073Z
2022-03-09T01:54:56.073Z
Murch
<p>In the Bitcoin development process, there exists the following high-level structure of control:</p>
<ul>
<li>Anyone can submit a BIP that aims to change Bitcoin Core</li>
<li>The BIP must be approved by an editor</li>
<li>The BIP must be voted in with 95% confidence from the miners</li>
<li>The <strong>community</strong> must upgrade to the new software version</li>
</ul>
<p>As a full node <strong>community member</strong>, I have always updated my node to the latest version of Bitcoin Core. A good answer would make me dispel my doubts regarding the next questions:</p>
<ol>
<li>What should I consider or be aware of when updating to the latest software version?</li>
<li>What are the criteria for the Bitcoin protocol to consolidate at community/network level in comparison to TCP/IP protocol for example?</li>
<li>Are there any kind of changes which require additional caution from the network participants (full nodes)?</li>
</ol>
<p>Thank you.</p>

<full-node><consensus><bip>
Criteria for Bitcoin protocol consolidation/freezing at the network level (full nodes)
Tao
# Criteria for Bitcoin protocol consolidation/freezing at the network level (full nodes)

(Asked by: username_0 on 2022-03-07)

In the Bitcoin development process, there exists the following high-level structure of control:

* Anyone can submit a BIP that aims to change Bitcoin Core
* The BIP must be approved by an editor
* The BIP must be voted in with 95% confidence from the miners
* The **community** must upgrade to the new software version

As a full node **community member**, I have always updated my node to the latest version of Bitcoin Core. A good answer would make me dispel my doubts regarding the next questions:

1. What should I consider or be aware of when updating to the latest software version?
2. What are the criteria for the Bitcoin protocol to consolidate at community/network level in comparison to TCP/IP protocol for example?
3. Are there any kind of changes which require additional caution from the network participants (full nodes)?

Thank you.

**Tags:** full-node, consensus, bip


---

## 1 answers

### Answer by username_1 on 2022-03-07. Score: 5 | Accepted answer

I think you have a sense of the general idea, but I want to first address a few misunderstandings point by point first.

> * Anyone can submit a BIP that aims to change Bitcoin Core

Bitcoin Improvement Proposals (BIPs) are used to provide globally relevant information or propose changes to the Bitcoin protocol. Changes to single implementations such as Bitcoin Core are made via that project's repository.

> * The BIP must be approved by an editor

The BIP editors only ensure that a BIP fulfills certain minimum criteria, like being viable, on-topic, and complete.

> * The BIP must be voted in with 95% confidence from the miners
> * The community must upgrade to the new software version

BIPs that propose consensus changes must define an activation mechanism. For example Taproot used the Speedy Trial activation, which included miners signaling for readiness. Miners do not vote on proposed changes, they are asked to gauge whether they perceive the network to be supportive of the change and signal readiness to enforce a consensus change. Full nodes upgrade to signal support and to enforce the consensus change once it is activated. If there is serious disagreement among developers, community, and miners whether something should be activated, this should be sufficiently visible in the public debate, so that a Speedy Trial activation attempt would fail.

> What should I consider or be aware of when updating to the latest software version?

Node operators define what they consider to be Bitcoin per the software they run. If you want to support adoption of a consensus change, you should run software that facilitates the new rules. If you disagree with a consensus change, you should run software that expresses this disagreement either passively by not supporting the change or actively by counteracting it in some manner. If it's all the same, you should probably run somewhat recent software, to get access to the latest bug fixes, features and improvements. For example, Bitcoin Core's [life cycle](https://bitcoincore.org/en/lifecycle/) provides maintenance for the current and previous major version, older versions receive critical security fixes a bit longer, but are considered end-of-life shortly after that. Other projects have their own modus operandi.

> What are the criteria for the Bitcoin protocol to consolidate at community/network level in comparison to TCP/IP protocol for example?

TCP/IP is maintained by the [IETF](https://en.wikipedia.org/wiki/Internet_Engineering_Task_Force), an open standards organization. From what I understand the IETF standards track's RFCs inspired the BIP process. I assume that slight divergence in adoption of protocol changes in TCP/IP would mostly cause participants to downgrade to shared mechanisms for compatibility. On Bitcoin however, consensus changes must be broadly adopted by the network to come into effect, so there is an emergent property to the process on the network level. If e.g. users run node software enforcing rules conflicting with rules enforced by other nodes, it may cause the network to split for good which can lead to the spin-off of a fork-coin.

> Are there any kind of changes which require additional caution from the network participants (full nodes)?

Unless a new version introduces consensus changes, not usually. If you're a power user, you should glance at the release notes to see if there were any changes to RPCs you use. If any existing features get removed, this usually happens in steps over multiple major releases.


---

