<p>For 100 blocks, a miner will include its yes or no, number of votes is proportional to the percentage of the hashing power of the network. If you have 20%, you’ll likely be able to vote approx 20 times. Developers make a proposal and miners vote on it. If the majority vote yes, the miners implement the code. Majority in this case is when over 55% of the miners vote for a specific change.</p>
<p>BIPs and this kind of infrastructure for cryptocurrencies in general, has sparked some interesting debates within the community. Some developers fear miners will vote based on vested interest rather than the good of the network.</p>
<p>Additionally there is a growing fear in the community towards the concentration of hashpower (which translates into voting power) as mining pools and big scale mining operations continue to grow. This system is still relatively new, so it will be interesting to see how BIPs progress and ultimately how they affect the development of other cryptos as a result of its successes and failures.</p>

CC BY-SA 4.0
2020-07-16T18:08:13.717Z
Thank you for your answer, but I edited the question and added "technically" word. I'm interesting in how do they technically vote? Where they add their "yes" or "no"?
ddavi031
CC BY-SA 4.0
2020-07-16T18:26:44.700Z
They put yes or no (a piece of code) inside the `coinbase transaction`
Hamita
CC BY-SA 4.0
2020-07-16T18:29:04.443Z
As part of the scriptSig?
ddavi031
CC BY-SA 4.0
2020-07-16T18:45:55.833Z
take a look at the third point of this site and it wil explain it for you [https://medium.com/@dongha.sohn/bitcoin-7-coinbase-and-priority-f5e9f47f1c9b]
Hamita
CC BY-SA 4.0
2020-07-16T18:51:33.693Z
Sorry but link is 404
ddavi031
CC BY-SA 4.0
2020-07-16T18:58:50.740Z
It works fine, use a VPN, and if it will not work, let me know and  i will hyperlink a screenshot of the site
Hamita
CC BY-SA 4.0
2020-07-16T19:09:36.837Z
I downvoted. I think this answer misses the point: what miners do in typical softforks is not voting, it is *signalling readiness*. If the community wants proposal to happen, they can demand it from miners (see BIP148 for example), but things go smoother if miners deploy faster rather than later. See BIP8, BIP9, for modern activation mechanisms.
Pieter Wuille
CC BY-SA 4.0
2020-07-16T19:12:35.663Z
@PieterWuille i Upvoted your comment beacuse it will help the community, thank you
Hamita
CC BY-SA 4.0
2020-07-16T18:04:45.297Z
2020-07-16T18:04:45.297Z
Hamita
<p>See my answer <a href="https://bitcoin.stackexchange.com/a/97046/208">here</a> to address some of your misconceptions. TL;DR: miners signal support in blocks for certain rule changes in order to coordinate activation, not to determine whether it is accepted or not.</p>
<p>As for the actual mechanism used to signal, a number have been used in the past:</p>
<p><strong>Time based: <a href="https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki" rel="nofollow noreferrer">BIP16</a>, <a href="https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki" rel="nofollow noreferrer">BIP30</a></strong></p>
<p>Early softforks (up to mid 2012) used a simple time based activation mechanism: node software that implements these proposals enforced the new rules on all blocks with a timestamp after a certain date. In the case of BIP16, this date was determined (and modified) in response to miner signalling, but this signalling was just for human interpretation; nodes took no automatic actions in response to it.</p>
<p>Specifically, the signalling used here was to put a string with a support message in the coinbase transaction's <code>scriptSig</code> field, which is otherwise free for miners to put anything in.</p>
<p><strong>Block-version signalling: <a href="https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki" rel="nofollow noreferrer">BIP34</a>, <a href="https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki" rel="nofollow noreferrer">BIP65</a>, <a href="https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki" rel="nofollow noreferrer">BIP66</a></strong></p>
<p>A later generation of softforks used the block header's <code>nVersion</code> field for signalling (up to the year 2015). Each of those used a subsequent version numbers (BIP34 used version 2; BIP66 used version 3; BIP65 used version 4).</p>
<p>Whenever 750 out blocks number N-1000..N-1 (so 75%) had the proposal's version number or higher, block N would be subject to the proposal's rules. Whenever 950 out of blocks number N-1000..N-1 (so 95%) did, the next block would be required to also signal for it - resulting in a final lock-in.</p>
<p><strong>Versionbits-based signalling: <a href="https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki" rel="nofollow noreferrer">BIP68</a>/<a href="https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki" rel="nofollow noreferrer">112</a>/<a href="https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki" rel="nofollow noreferrer">113</a>, <a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki" rel="nofollow noreferrer">BIP141</a>/<a href="https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki" rel="nofollow noreferrer">143</a>/<a href="https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki" rel="nofollow noreferrer">144</a>, <a href="https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki" rel="nofollow noreferrer">BIP91</a>, <a href="https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki" rel="nofollow noreferrer">BIP341</a>/<a href="https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki" rel="nofollow noreferrer">342</a></strong></p>
<p>The rollout of relative locktimes (BIP68/112/113) and Segregated Witness (BIP141/143/144) used a different mechanism, which had its own document, <a href="https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki" rel="nofollow noreferrer">BIP9</a>. It specifies using one specific bit of the block header's <code>nVersion</code> field for each proposal, and a finite state machine to determine when to signal and when to activate. Its purpose is/was to permit multiple concurrent proposals to activate, without needing to have one completed before the next one can roll out. This was a downside of the previous mechanism, as it would be impossible to activate the proposal with version 4 without also signalling for activation of the proposal with version 3.</p>
<p>Due to various reasons, segwit was not entirely uncontroversial, and eventual activation happened through a meta-proposal, BIP91. BIP91 itself used BIP9 to activate, which then on its turn made signalling for BIP141/143/144 mandatory, resulting in its activation in August 2017.</p>
<p>BIP341/342 activated in November 2021, using a modified versionbits-based activation mechanism with lower activation threshold, and minimum activation height, in what has been called the &quot;speedy trial&quot; approach.</p>
<p>Disclaimer: I am a (co-)author of several of the listed documents in this post (BIP9, BIP30, BIP66, BIP141/143/144, BIP340/341/342).</p>

CC BY-SA 4.0
2020-07-17T10:50:30.817Z
Thank you for your answer. Good luck in your future work on BIPs
ddavi031
CC BY-SA 4.0
2020-07-16T21:20:16.650Z
2022-11-28T20:35:05.200Z
2022-11-28T20:35:05.200Z
Pieter Wuille
<p>I understand that a miner is the only one who can vote for a certain BIP, but I'm wondering, how do they technically do that? How do they submit their vote? I found out that they  are doing it through the <code>coinbase</code> transaction, but I couldn't find any details on it. <br/>
Thanks!</p>

<bip><voting><bip9-version-bits><activation-mechanism>
How does a miner put his vote for certain BIP?
ddavi031
# How does a miner put his vote for certain BIP?

(Asked by: username_0 on 2020-07-16)

I understand that a miner is the only one who can vote for a certain BIP, but I'm wondering, how do they technically do that? How do they submit their vote? I found out that they are doing it through the `coinbase` transaction, but I couldn't find any details on it.   
Thanks!

**Tags:** bip, voting, bip9-version-bits, activation-mechanism


---

## 2 answers

### Answer by username_2 on 2020-07-16. Score: 8 | Accepted answer

See my answer [here](https://bitcoin.stackexchange.com/a/97046/208) to address some of your misconceptions. TL;DR: miners signal support in blocks for certain rule changes in order to coordinate activation, not to determine whether it is accepted or not.

As for the actual mechanism used to signal, a number have been used in the past:

**Time based: [BIP16](https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki), [BIP30](https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki)**

Early softforks (up to mid 2012) used a simple time based activation mechanism: node software that implements these proposals enforced the new rules on all blocks with a timestamp after a certain date. In the case of BIP16, this date was determined (and modified) in response to miner signalling, but this signalling was just for human interpretation; nodes took no automatic actions in response to it.

Specifically, the signalling used here was to put a string with a support message in the coinbase transaction's `scriptSig` field, which is otherwise free for miners to put anything in.

**Block-version signalling: [BIP34](https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki), [BIP65](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki), [BIP66](https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki)**

A later generation of softforks used the block header's `nVersion` field for signalling (up to the year 2015). Each of those used a subsequent version numbers (BIP34 used version 2; BIP66 used version 3; BIP65 used version 4).

Whenever 750 out blocks number N-1000..N-1 (so 75%) had the proposal's version number or higher, block N would be subject to the proposal's rules. Whenever 950 out of blocks number N-1000..N-1 (so 95%) did, the next block would be required to also signal for it - resulting in a final lock-in.

**Versionbits-based signalling: [BIP68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki)/[112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki)/[113](https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki), [BIP141](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki)/[143](https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki)/[144](https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki), [BIP91](https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki), [BIP341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki)/[342](https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki)**

The rollout of relative locktimes (BIP68/112/113) and Segregated Witness (BIP141/143/144) used a different mechanism, which had its own document, [BIP9](https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki). It specifies using one specific bit of the block header's `nVersion` field for each proposal, and a finite state machine to determine when to signal and when to activate. Its purpose is/was to permit multiple concurrent proposals to activate, without needing to have one completed before the next one can roll out. This was a downside of the previous mechanism, as it would be impossible to activate the proposal with version 4 without also signalling for activation of the proposal with version 3.

Due to various reasons, segwit was not entirely uncontroversial, and eventual activation happened through a meta-proposal, BIP91. BIP91 itself used BIP9 to activate, which then on its turn made signalling for BIP141/143/144 mandatory, resulting in its activation in August 2017.

BIP341/342 activated in November 2021, using a modified versionbits-based activation mechanism with lower activation threshold, and minimum activation height, in what has been called the "speedy trial" approach.

Disclaimer: I am a (co-)author of several of the listed documents in this post (BIP9, BIP30, BIP66, BIP141/143/144, BIP340/341/342).

> **Comments:**
> **username_0**: Thank you for your answer. Good luck in your future work on BIPs  

---

### Answer by username_1 on 2020-07-16. Score: -2

For 100 blocks, a miner will include its yes or no, number of votes is proportional to the percentage of the hashing power of the network. If you have 20%, you’ll likely be able to vote approx 20 times. Developers make a proposal and miners vote on it. If the majority vote yes, the miners implement the code. Majority in this case is when over 55% of the miners vote for a specific change.

BIPs and this kind of infrastructure for cryptocurrencies in general, has sparked some interesting debates within the community. Some developers fear miners will vote based on vested interest rather than the good of the network.

Additionally there is a growing fear in the community towards the concentration of hashpower (which translates into voting power) as mining pools and big scale mining operations continue to grow. This system is still relatively new, so it will be interesting to see how BIPs progress and ultimately how they affect the development of other cryptos as a result of its successes and failures.

> **Comments:**
> **username_0**: Thank you for your answer, but I edited the question and added "technically" word. I'm interesting in how do they technically vote? Where they add their "yes" or "no"?  
> **username_1**: They put yes or no (a piece of code) inside the `coinbase transaction`  
> **username_0**: As part of the scriptSig?  
> **username_1**: take a look at the third point of this site and it wil explain it for you [https://medium.com/@dongha.sohn/bitcoin-7-coinbase-and-priority-f5e9f47f1c9b]  
> **username_0**: Sorry but link is 404  
> **username_1**: It works fine, use a VPN, and if it will not work, let me know and  i will hyperlink a screenshot of the site  
> **username_2**: I downvoted. I think this answer misses the point: what miners do in typical softforks is not voting, it is *signalling readiness*. If the community wants proposal to happen, they can demand it from miners (see BIP148 for example), but things go smoother if miners deploy faster rather than later. See BIP8, BIP9, for modern activation mechanisms.  
> **username_1**: @username_2 i Upvoted your comment beacuse it will help the community, thank you  

---

