Voting results of BIP´s & Hard/Soft Forks

[sherblock]

Hello
where can i find the voting results of BIP´s and Hard/Soft-Forks?
Thank you

[1715539024]

1715539024

[1715539024]

1715539024

[1715539024]

1715539024

[achow101]

You can't because no such vote exists. There is no vote for activating a soft fork. There isn't really an official specified process either.

You could scan the blockchain to observe the version number changes that signal for a fork to be deployed. However if you do that, you must remember that that is not a vote. Miners did not vote, and them signaling readiness in their blocks is not a vote. Miner signaling is a coordination mechanism deployed after there is sufficient evidence of consensus for a fork to be activated.

[sherblock]

Ist there a way to see a transparent documented development process that led for example to the SegWit ubdate and the BCH hard fork?

[Wind_FURY]

Ist there a way to see a transparent documented development process that led for example to the SegWit ubdate and the BCH hard fork?

What kind of document are you looking for? An "official document" saying that "this is what actually happened"? There's none, but Aaron Van Wirdum wrote this for Bitcoin Magazine, https://bitcoinmagazine.com/technical/the-long-road-to-segwit-how-bitcoins-biggest-protocol-upgrade-became-reality

The people from the Bitcoin Cash community might say it's not the most objective/accurate article telling those events though.

[sherblock]

Thank you for the link.

I am looking for something like this https://github.com/bitcoin/bitcoin/pull/8149

Is this the maximum i can get when i want to know, who did when and what in the development process and what the pro/contra arguments were?

[BlackHatCoiner]

Miner signaling is a coordination mechanism deployed after there is sufficient evidence of consensus for a fork to be activated.

I'm confused.

To reach consensus for the activation of a fork, there has to be signalling. Why isn't block header signal considered voting?

[garlonicon]

Why isn't block header signal considered voting?

Because Bitcoin is not ruled by miners: https://en.bitcoin.it/wiki/Bitcoin_is_not_ruled_by_miners
Also read Harmony and Discord: https://bitcointalk.org/dec/p1.html

There are many groups. There are miners, there are users, there are developers, there are traders. All people using Bitcoin form a consensus. Signalling is not voting, just because not only miners decide, what is and what is not Bitcoin. If Bitcoin would be ruled by miners, then they could decide to for example get all coins and ignore all signatures. Or to increase block reward to 100 BTC ad infinitum. But they cannot. They could start signalling for such changes, but because signalling is not voting, those rules can be still rejected by non-miners. That's also the reason, why full nodes are so important.

[BlackHatCoiner]

They could start signalling for such changes, but because signalling is not voting, those rules can be still rejected by non-miners.

This is how I understand it:

• One group proposes a change, let's say miners.
• They suggest on increasing the block subsidy by 6.25 coins.
• They publish the source code with a programmed change on a future block.
• No other group agrees with the change. (Therefore votes against)
• Miners are discouraged to mine in the new chain, because there's much less demand.
• Miners switch to the old chain.

Another example:

• Developers propose to increase the block size by 100 MB.
• Developers publish the source code with the condition that if 90% of the block headers contain a certain version number, then after a future block, Bitcoin Core will limit block size to 100 MB.
• Most of the miners agree with the change and a few hundreds of blocks afterwards, a chain split occurs.
• Most of the users disagree with the change, but no one knows it, because it's not publicly known as it is with the block headers.
• The minority of the miners continues using the old chain and so are most of the users who're running a full node. Their denial to upgrade shows that they're voting against.
• The old miners become discouraged due to less demand and continue to the old chain.

[sherblock]

You could get some information from bitcoin-dev mailing...

Thank you.

...sufficient evidence of consensus...

Is there an example for this?

[Wind_FURY]

They could start signalling for such changes, but because signalling is not voting, those rules can be still rejected by non-miners.

This is how I understand it:

• One group proposes a change, let's say miners.
• They suggest on increasing the block subsidy by 6.25 coins.
• They publish the source code with a programmed change on a future block.
• No other group agrees with the change. (Therefore votes against)
• Miners are discouraged to mine in the new chain, because there's much less demand.
• Miners switch to the old chain.

Another example:

• Developers propose to increase the block size by 100 MB.
• Developers publish the source code with the condition that if 90% of the block headers contain a certain version number, then after a future block, Bitcoin Core will limit block size to 100 MB.
• Most of the miners agree with the change and a few hundreds of blocks afterwards, a chain split occurs.
• Most of the users disagree with the change, but no one knows it, because it's not publicly known as it is with the block headers.
• The minority of the miners continues using the old chain and so are most of the users who're running a full node. Their denial to upgrade shows that they're voting against.
• The old miners become discouraged due to less demand and continue to the old chain.

Everything in Bitcoin concerning consensus is, very complex. It can be debated that hashing power is a mechanism not for consensus, but a Sybil Attack protection mechanism.

Plus there's also the UASF by shaolinfry, which has demonstrated that miner signalling have been used as a political tool by Jihan Wu, Roger Ver and their mining-cartel.

https://bitcointalk.org/index.php?topic=1805060.0

[NotATether]

Ist there a way to see a transparent documented development process that led for example to the SegWit ubdate and the BCH hard fork?

The most official documentation about this is the BIPs themselves, particularly BIP148 (this describes the activation timeline for segwit) and BIPs 8-9 (these describe the actual signaling method for deployment).

[pooya87]

The most official documentation about this is the BIPs themselves, particularly BIP148 (this describes the activation timeline for segwit) and BIPs 8-9 (these describe the actual signaling method for deployment).

BIP9 is the correct procedure to activate forks and this BIP or a similar alternative is always used for all the forks.
BIP148 on the other hand is describing a very dangerous attack against bitcoin and its consensus reaching mechanism. It is basically saying that anybody can ignore what the majority of miners say and enforce any fork by rejecting valid blocks. Very similar to what bcash did, they ignored what the majority of miners (and nodes and the economy) and enforced their own rules creating a minority fork.