1

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!

3

See my answer here 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, BIP30

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, BIP65, BIP66

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; BIP65 used version 3; BIP66 used version 4).

Whenever 750 out blocks number N-1000..N-1 (so 75%) had the proposal's version number of 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/112/113, BIP141/143/144, BIP91

The rollout of relative locktimes (BIP68/112/113) and Segregated Witness (BIP141/143/144) used a different mechanism, which had its own document, BIP9. 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.

The future?

There are a variety of mechanisms available these days, and there is active discussion on what to use for the (likely) next softfork, specified in BIP340/341/342 (Taproot). This includes a variant of the BIP9 versionbits mechanism, called BIP8. An article on the various possible schemes can be found here.

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

| improve this answer | |
  • Thank you for your answer. Good luck in your future work on BIPs – ddavi031 Jul 17 at 10:50
0

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.

| improve this answer | |
  • 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 Jul 16 at 18:08
  • They put yes or no (a piece of code) inside the coinbase transaction – Hamita Jul 16 at 18:26
  • As part of the scriptSig? – ddavi031 Jul 16 at 18:29
  • take a look at the third point of this site and it wil explain it for you [medium.com/@dongha.sohn/… – Hamita Jul 16 at 18:45
  • 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. – Pieter Wuille Jul 16 at 19:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.