<blockquote>
<p>Although the devil is of course in the details, how could such an upgrade process look like? and What are the different upgrade mechanism for the major [v1 - v16] and minor [v1.0 - v1.127] version changes?</p>
</blockquote>
<p>As Pieter Wuille mentioned in the comments, &quot;There isn't even a proposal. Discussion about activation and all its implications is something to be had after there is a worked-out idea, implementation, and clear buy-in from the community. You could formulate the question generically as &quot;What activation methods are available for future softforks?&quot;, but nobody can answer this question for something that doesn't exist&quot;</p>
<blockquote>
<p>How is the soft fork signaled?</p>
</blockquote>
<p>Initially, soft forks used to be signalled with the block version number, but due to its many limitations BIP-9 (read full documentation <a href="https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki" rel="nofollow noreferrer">here</a>) is used. In BIP-9, the block version number is interpreted as bit field instead of an integer (we currently have 29 bits where we can signal this). BIP-9 also sets a maximum time for signaling and activation. This way miners don’t need to signal forever. If a proposal is not activated within the TIMEOUT period (defined in the proposal), the proposal is considered rejected. The proposal may be resubmitted for signaling with a different bit, renewing the activation period.</p>
<blockquote>
<p>How is the consensus change enforced?</p>
</blockquote>
<p>BIP-9 counts activation signaling in whole intervals based on the difficulty retarget period of 2016 blocks. For every retarget period, if the sum of blocks signaling for a proposal exceeds 95% (1916 of 2016), the proposal will be activated one retarget period later. Proposals start in the DEFINED state, once their parameters are known (defined) in the bitcoin software. For blocks with Median Time Past (MTP) after the start time, the proposal state transitions to STARTED. If the voting threshold is exceeded within a retarget period and the timeout has not been exceeded, the proposal state transitions to LOCKED_IN. One retarget period later, the proposal becomes ACTIVE. Proposals remain in the ACTIVE state perpetually once they reach that state. If the timeout elapses before the voting threshold has been reached, the proposal state changes to FAILED, indicating a rejected proposal. FAILED proposals remain in that state perpetually. Below is a diagram from Mastering Bitcoin book.
<a href="https://i.sstatic.net/4MDJD.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/4MDJD.png" alt="BIP-9 State Transition Diagram" /></a></p>
<blockquote>
<p>Is the v1 change as &quot;contentious&quot; and time consuming as v0 was?</p>
</blockquote>
<p>Again, there isn't even a proper proposal out there.</p>
<blockquote>
<p>What are the tasks of node operators and miners?</p>
</blockquote>
<p>Miners cast their voting power on the different proposals by mining the block with the particular bit in the block version number. Full nodes, will decide whether they want to treat these blocks as valid or not and whether they should propagate those blocks to the entire network.</p>

CC BY-SA 4.0
2019-03-03T13:41:03.173Z
2020-10-11T13:15:08.207Z
2020-10-11T13:15:08.207Z
Ugam Kamat
<p>The segregated witness soft fork of August 2017 included a versioning field which would allow for future incrementation. Anthony Towns has recently posted an early draft of the proposal for the SegWit v1 upgrade to the <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-December/016556.html" rel="nofollow noreferrer">mailing list</a>.</p>

<ul>
<li><p>Although the devil is of course in the details, what activation methods are available for future softforks?</p></li>
<li><p>What are the different upgrade mechanism for the major [v1 - v16] and
minor [v1.0 - v1.127] version changes?</p></li>
<li><p>How is the soft fork signaled, taking the overt ASIC Boost with version bits into account?</p></li>
<li><p>How is the consensus change enforced?</p></li>
<li><p>Is the v1 change as "contentious" and time consuming as v0 was?</p></li>
<li><p>What are the tasks of node operators and miners?</p></li>
</ul>

<p>Thank you in advance for the answer!</p>

CC BY-SA 4.0
2019-03-02T20:44:36.867Z
There isn't even a proposal. Discussion about activation and all its implications is something to be had after there is a worked-out idea, implementation, and clear buy-in from the community. You could formulate the question generically as "What activation methods are available for future softforks?", but nobody can answer this question for something that doesn't exist.
Pieter Wuille
<segregated-witness><consensus><soft-fork><taproot><activation-mechanism>
Activation of SegWit v1
Max Hillebrand
# Activation of SegWit v1

(Asked by: username_0 on 2019-03-02)

The segregated witness soft fork of August 2017 included a versioning field which would allow for future incrementation. Anthony Towns has recently posted an early draft of the proposal for the SegWit v1 upgrade to the [mailing list](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-December/016556.html).

* Although the devil is of course in the details, what activation methods are available for future softforks?
* What are the different upgrade mechanism for the major [v1 - v16] and
  minor [v1.0 - v1.127] version changes?
* How is the soft fork signaled, taking the overt ASIC Boost with version bits into account?
* How is the consensus change enforced?
* Is the v1 change as "contentious" and time consuming as v0 was?
* What are the tasks of node operators and miners?

Thank you in advance for the answer!

**Tags:** segregated-witness, consensus, soft-fork, taproot, activation-mechanism

> **Comments:**
> **username_1**: There isn't even a proposal. Discussion about activation and all its implications is something to be had after there is a worked-out idea, implementation, and clear buy-in from the community. You could formulate the question generically as "What activation methods are available for future softforks?", but nobody can answer this question for something that doesn't exist.  

---

## 1 answers

### Answer by username_2 on 2019-03-03. Score: 1

> Although the devil is of course in the details, how could such an upgrade process look like? and What are the different upgrade mechanism for the major [v1 - v16] and minor [v1.0 - v1.127] version changes?

As username_1 username_1 mentioned in the comments, "There isn't even a proposal. Discussion about activation and all its implications is something to be had after there is a worked-out idea, implementation, and clear buy-in from the community. You could formulate the question generically as "What activation methods are available for future softforks?", but nobody can answer this question for something that doesn't exist"

> How is the soft fork signaled?

Initially, soft forks used to be signalled with the block version number, but due to its many limitations BIP-9 (read full documentation [here](https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki)) is used. In BIP-9, the block version number is interpreted as bit field instead of an integer (we currently have 29 bits where we can signal this). BIP-9 also sets a maximum time for signaling and activation. This way miners don’t need to signal forever. If a proposal is not activated within the TIMEOUT period (defined in the proposal), the proposal is considered rejected. The proposal may be resubmitted for signaling with a different bit, renewing the activation period.

> How is the consensus change enforced?

BIP-9 counts activation signaling in whole intervals based on the difficulty retarget period of 2016 blocks. For every retarget period, if the sum of blocks signaling for a proposal exceeds 95% (1916 of 2016), the proposal will be activated one retarget period later. Proposals start in the DEFINED state, once their parameters are known (defined) in the bitcoin software. For blocks with Median Time Past (MTP) after the start time, the proposal state transitions to STARTED. If the voting threshold is exceeded within a retarget period and the timeout has not been exceeded, the proposal state transitions to LOCKED\_IN. One retarget period later, the proposal becomes ACTIVE. Proposals remain in the ACTIVE state perpetually once they reach that state. If the timeout elapses before the voting threshold has been reached, the proposal state changes to FAILED, indicating a rejected proposal. FAILED proposals remain in that state perpetually. Below is a diagram from Mastering Bitcoin book.
[![BIP-9 State Transition Diagram](https://i.sstatic.net/4MDJD.png)](https://i.sstatic.net/4MDJD.png)

> Is the v1 change as "contentious" and time consuming as v0 was?

Again, there isn't even a proper proposal out there.

> What are the tasks of node operators and miners?

Miners cast their voting power on the different proposals by mining the block with the particular bit in the block version number. Full nodes, will decide whether they want to treat these blocks as valid or not and whether they should propagate those blocks to the entire network.


---

