75% / 95% majority hashing power

[BlackJacky]

Guys,

I noticed that some updates like e.g. version 0.12 where CheckLogTimeVerify has been implemented we only needed 75% majority hashing power to activate it if Im not mistaken. Now for version 0.13.1 with SegWit we need 95%.

Why is it sometimes 75% and sometimes 95%? Who sets this?

Thanks in advance to all

[OmegaStarScream]

Guys,

I noticed that some updates like e.g. version 0.12 where CheckLogTimeVerify has been implemented we only needed 75% majority hashing power to activate it if Im not mistaken. Now for version 0.13.1 with SegWit we need 95%.

Why is it sometimes 75% and sometimes 95%? Who sets this?

Thanks in advance to all

I'm not sure about this as I'm no expert but I guess It has something to do with how big and important the decision is , which means In this case SegWit is way more important and big then CheckLogTimeVerify.

[BlackJacky]

Guys,

I noticed that some updates like e.g. version 0.12 where CheckLogTimeVerify has been implemented we only needed 75% majority hashing power to activate it if Im not mistaken. Now for version 0.13.1 with SegWit we need 95%.

Why is it sometimes 75% and sometimes 95%? Who sets this?

Thanks in advance to all

I'm not sure about this as I'm no expert but I guess It has something to do with how big and important the decision is , which means In this case SegWit is way more important and big then CheckLogTimeVerify.

Yes, it is much more important but who is deciding it to increase the percentage and to make it harder to activate it?

[OmegaStarScream]

Guys,

I noticed that some updates like e.g. version 0.12 where CheckLogTimeVerify has been implemented we only needed 75% majority hashing power to activate it if Im not mistaken. Now for version 0.13.1 with SegWit we need 95%.

Why is it sometimes 75% and sometimes 95%? Who sets this?

Thanks in advance to all

I'm not sure about this as I'm no expert but I guess It has something to do with how big and important the decision is , which means In this case SegWit is way more important and big then CheckLogTimeVerify.

Yes, it is much more important but who is deciding it to increase the percentage and to make it harder to activate it?

Bitcoin is decentralized but such a decision should be made from developers , from there... It's up to miners ,If they want to support the changes or not.

[odolvlobo]

Yes, it is much more important but who is deciding it to increase the percentage and to make it harder to activate it?

It is very simple. The developers of Bitcoin Core decide on what goes into Bitcoin Core. I'm sure they discuss it a bit. Wladimir van der Laan is the lead developer, so he probably has to approve.

[calkob]

I presume that it is set by the developers, and because it is a serious change then they want to make sure that most of the network is going to change.  If it was just 75% then there could be alot of miners who dont agree and we could end up with 2 bitcoins

[BlackJacky]

I presume that it is set by the developers, and because it is a serious change then they want to make sure that most of the network is going to change.  If it was just 75% then there could be alot of miners who dont agree and we could end up with 2 bitcoins

Correct me if Im wrong but we only could end up with two bitcoins if we do a hard fork. A split/fork in two bitcoins cant happen with a soft fork, right?

[odolvlobo]

I presume that it is set by the developers, and because it is a serious change then they want to make sure that most of the network is going to change.  If it was just 75% then there could be alot of miners who dont agree and we could end up with 2 bitcoins

Correct me if Im wrong but we only could end up with two bitcoins if we do a hard fork. A split/fork in two bitcoins cant happen with a soft fork, right?

A fork is a fork, whether hard or soft. The difference is that, in a soft fork, a legacy node still considers a segwit transaction to be valid (though it doesn't interpret it as a segwit transaction). In a hard fork, a legacy node would consider a segwit transaction to be invalid.

The reason that there is still a fork is that a legacy node disagrees with a segwit node on how the outputs of a segwit transaction can be spent.

[gmaxwell]

has been implemented we only needed 75% majority hashing power to activate it if Im not mistaken. Now for version 0.13.1 with SegWit we need 95%.

You're mistaken. Pre-BIP9 softforks had an extra stage where the new feature was enforced in blocks that claimed it, but wasn't required overall. 95% was still mandatory to require the change on the network. Bip9 eliminated that step because it added complexity without adding any obvious value.   This behavior is set by the change itself, or-- rather-- BIP9 which is a meta-proposal for how changes like this should be done.