This query is predicated on a false impression. Miners don’t vote on proposals. Consensus modifications to Bitcoin are made by your complete ecosystem transitioning to new guidelines that they select, by working node software program that enforces these guidelines.
Miners are part of that ecosystem, and their imposing of recent guidelines is a part of what makes them secure. But when miners refuse to undertake a rule change that the remainder of the ecosystem calls for, they don’t have any alternative. If a rule is carried out and enforced by the community’s full nodes, then miners who produce blocks that don’t observe these guidelines will merely be ignored.
The whole lot works higher nonetheless, if miners and the remainder of the ecosystem don’t diverge on what guidelines they’re demanding and imposing. For that function, a number of previous backward-compatible consensus modifications (“softforks”), have used a mechanism the place miners can sign that they are able to implement a selected rule, and as soon as a sure threshold is reached, all of them (together with non-miners) begin imposing these guidelines in lockstep.
So in actuality, such a signalling mechanism is for coordination, not for voting. Proposals might undergo even with out miners’ consent, nevertheless it’s higher for everybody if issues are synchronized.
Earlier softforks which have employed such a coordination mechanism are:
- BIP34 Top in coinbase (2012)
- BIP65 OP_CHECKLOCKTIMEVERIFY (2014)
- BIP66 Strict DER signatures (2015)
- BIP68/112/113 OP_CHECKSEQUENCEVERIFY and related relative locktime semantics (2016)
- BIP141/BIP143/144 Segregated witness (2016)
- BIP147 Coping with dummy stack factor malleability (packaged along with BIP141/BIP143/BIP144) (2016)
- BIP91 Lowered threshold Segwit MASF (2017)
- BIP341/BIP342 Taproot (2021).
The precise guidelines utilized by every of those differ (see my reply right here for particulars). Some used a easy threshold of 750 or 950 blocks over the previous 1000; some used BIP9.
Earlier softforks (BIP16, BIP30) had been coordinated on the human layer. BIP16 did use signalling in blocks as properly, however solely to tell modifications made to the software program. The precise activation was time based mostly (as quickly as sufficient assist was signalled, node software program was modified to start out imposing new guidelines after a sure date). As BIP16 did have a competing proposal (BIP17), it was straightforward to misread assist for one or the opposite as a vote. Maybe that’s the place the misperception originates.
Proper now (as of October 2021), there are no unactivated consensus modifications carried out in node software program, so there’s nothing to sign for.
Disclaimer: I’m a (co-)creator of a few of the BIP paperwork listed on this reply (BIP30, BIP66, BIP141/143/144, BIP340/341/342).
