<p>People wishing to submit BIPs, first should propose their idea or document to the bitcoin-dev@lists.linuxfoundation.org mailing list. After discussion it will be published <a href="https://github.com/bitcoin/bips/blob/master/README.mediawiki" rel="nofollow noreferrer">Here</a></p>

CC BY-SA 4.0
2020-07-16T20:16:31.777Z
So miner can now, at this very moment , mine a block and vote for some of the BIPs from this list?
ddavi031
CC BY-SA 4.0
2020-07-16T20:14:43.630Z
2020-07-16T20:14:43.630Z
Hamita
<p>This question is based on a misconception. Miners do not vote on proposals. Consensus changes to Bitcoin are made by the entire ecosystem transitioning to new rules that they choose, by running node software that enforces these rules.</p>
<p>Miners are a part of that ecosystem, and their enforcing of new rules is part of what makes them safe. But if miners refuse to adopt a rule change that the rest of the ecosystem demands, they have no choice. If a rule is implemented and enforced by the network's full nodes, then miners who produce blocks that do not follow those rules will simply be ignored.</p>
<p>Everything works better however, if miners and the rest of the ecosystem do not diverge on what rules they're demanding and enforcing. For that purpose, several past backward-compatible consensus changes (&quot;softforks&quot;), have used a mechanism where miners can signal that they're ready to enforce a particular rule, and once a certain threshold is reached, all of them (including non-miners) start enforcing those rules in lockstep.</p>
<p>So in reality, such a signalling mechanism is for <em>coordination</em>, not for voting. Proposals may go through even without miners' consent, but it's better for everyone if things are synchronized.</p>
<p>Previous softforks that have employed such a coordination mechanism are:</p>
<ul>
<li><a href="https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki" rel="nofollow noreferrer">BIP34</a> Height in coinbase (2012)</li>
<li><a href="https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki" rel="nofollow noreferrer">BIP65</a> OP_CHECKLOCKTIMEVERIFY (2014)</li>
<li><a href="https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki" rel="nofollow noreferrer">BIP66</a> Strict DER signatures (2015)</li>
<li><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> OP_CHECKSEQUENCEVERIFY and associated relative locktime semantics (2016)</li>
<li><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">BIP143</a>/<a href="https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki" rel="nofollow noreferrer">144</a> Segregated witness (2016)</li>
<li><a href="https://github.com/bitcoin/bips/blob/master/bip-0147.mediawiki" rel="nofollow noreferrer">BIP147</a> Dealing with dummy stack element malleability (packaged together with BIP141/BIP143/BIP144) (2016)</li>
<li><a href="https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki" rel="nofollow noreferrer">BIP91</a> Reduced threshold Segwit MASF (2017)</li>
<li><a href="https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki" rel="nofollow noreferrer">BIP341</a>/<a href="https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki" rel="nofollow noreferrer">BIP342</a> Taproot (2021).</li>
</ul>
<p>The specific rules used by each of these differ (see my answer <a href="https://bitcoin.stackexchange.com/a/97047/208">here</a> for details). Some used a simple threshold of 750 or 950 blocks over the past 1000; some used BIP9.</p>
<p>Earlier softforks (BIP16, BIP30) were coordinated at the human layer. BIP16 did use signalling in blocks as well, but only to inform changes made to the software. The actual activation was time based (as soon as enough support was signalled, node software was modified to start enforcing new rules after a certain date). As BIP16 did have a competing proposal (BIP17), it was easy to misinterpret support for one or the other as a vote. Perhaps that is where the misconception originates.</p>
<p>Right now (as of October 2021), there are <strong>no unactivated consensus changes implemented in node software</strong>, so there is nothing to signal for.</p>
<p>Disclaimer: I am a (co-)author of some of the BIP documents listed in this answer (BIP30, BIP66, BIP141/143/144, BIP340/341/342).</p>

CC BY-SA 4.0
2020-07-17T11:10:32.840Z
But this part "the rest of the ecosystem demands" got me confused. Who is demanding the change? When BIP needs considering, who considers it? Who is the one that says: This BIPX is good, and this BIPY is bad? Is that the group of programmers who are currently controlling bitcoin github? Doesn't system that way seems a bit centralized? If you think I should move this to a new question, please tell me, but I commented because this questions are based on your answer.
ddavi031
CC BY-SA 4.0
2020-07-17T16:21:27.783Z
@ddavi031 Well, that's venturing into politics. But I wouldn't confuse coordination with centralization. Just because some developers (myself included) release software that includes a certain change does not imply people will run it. For example, Bitcoin Core only implemented BIP141/143/144, which miners weren't really signalling for. Other people proposed BIP148 and BIP91 to get it to activate, which were never included in Bitcoin Core, and yet many started running software that did - and miners followed.
Pieter Wuille
CC BY-SA 4.0
2020-07-16T20:44:04.973Z
2021-10-12T15:39:17.640Z
2021-10-12T15:39:17.640Z
Pieter Wuille
<p>How can a miner know from which two (or more) BIPs they can choose when they are about to vote? Is there a list of currently active BIPs for voting?<br/>
Thanks!</p>

<bip><voting><bip9-version-bits>
Is there an active list of BIPs currently open for voting?
ddavi031
# Is there an active list of BIPs currently open for voting?

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

How can a miner know from which two (or more) BIPs they can choose when they are about to vote? Is there a list of currently active BIPs for voting?  
Thanks!

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


---

## 2 answers

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

This question is based on a misconception. Miners do not vote on proposals. Consensus changes to Bitcoin are made by the entire ecosystem transitioning to new rules that they choose, by running node software that enforces these rules.

Miners are a part of that ecosystem, and their enforcing of new rules is part of what makes them safe. But if miners refuse to adopt a rule change that the rest of the ecosystem demands, they have no choice. If a rule is implemented and enforced by the network's full nodes, then miners who produce blocks that do not follow those rules will simply be ignored.

Everything works better however, if miners and the rest of the ecosystem do not diverge on what rules they're demanding and enforcing. For that purpose, several past backward-compatible consensus changes ("softforks"), have used a mechanism where miners can signal that they're ready to enforce a particular rule, and once a certain threshold is reached, all of them (including non-miners) start enforcing those rules in lockstep.

So in reality, such a signalling mechanism is for *coordination*, not for voting. Proposals may go through even without miners' consent, but it's better for everyone if things are synchronized.

Previous softforks that have employed such a coordination mechanism are:

* [BIP34](https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki) Height in coinbase (2012)
* [BIP65](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki) OP\_CHECKLOCKTIMEVERIFY (2014)
* [BIP66](https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki) Strict DER signatures (2015)
* [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) OP\_CHECKSEQUENCEVERIFY and associated relative locktime semantics (2016)
* [BIP141](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki)/[BIP143](https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki)/[144](https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki) Segregated witness (2016)
* [BIP147](https://github.com/bitcoin/bips/blob/master/bip-0147.mediawiki) Dealing with dummy stack element malleability (packaged together with BIP141/BIP143/BIP144) (2016)
* [BIP91](https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki) Reduced threshold Segwit MASF (2017)
* [BIP341](https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki)/[BIP342](https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki) Taproot (2021).

The specific rules used by each of these differ (see my answer [here](https://bitcoin.stackexchange.com/a/97047/208) for details). Some used a simple threshold of 750 or 950 blocks over the past 1000; some used BIP9.

Earlier softforks (BIP16, BIP30) were coordinated at the human layer. BIP16 did use signalling in blocks as well, but only to inform changes made to the software. The actual activation was time based (as soon as enough support was signalled, node software was modified to start enforcing new rules after a certain date). As BIP16 did have a competing proposal (BIP17), it was easy to misinterpret support for one or the other as a vote. Perhaps that is where the misconception originates.

Right now (as of October 2021), there are **no unactivated consensus changes implemented in node software**, so there is nothing to signal for.

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

> **Comments:**
> **username_0**: But this part "the rest of the ecosystem demands" got me confused. Who is demanding the change? When BIP needs considering, who considers it? Who is the one that says: This BIPX is good, and this BIPY is bad? Is that the group of programmers who are currently controlling bitcoin github? Doesn't system that way seems a bit centralized? If you think I should move this to a new question, please tell me, but I commented because this questions are based on your answer.  
> **username_2**: @username_0 Well, that's venturing into politics. But I wouldn't confuse coordination with centralization. Just because some developers (myself included) release software that includes a certain change does not imply people will run it. For example, Bitcoin Core only implemented BIP141/143/144, which miners weren't really signalling for. Other people proposed BIP148 and BIP91 to get it to activate, which were never included in Bitcoin Core, and yet many started running software that did - and miners followed.  

---

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

People wishing to submit BIPs, first should propose their idea or document to the bitcoin-dev@lists.linuxfoundation.org mailing list. After discussion it will be published [Here](https://github.com/bitcoin/bips/blob/master/README.mediawiki)

> **Comments:**
> **username_0**: So miner can now, at this very moment , mine a block and vote for some of the BIPs from this list?  

---

