The idea sounds like the rule activates for 75% and is locked in for 95%, but really 95% is the only one that matters.
Yup. it's just a point where you find out if your software was broken. 
Topic: Softfork cutoff (Read 1987 times)
In terms of safety before lock-in: Most soft-fork features are unsafe until locked in and enforcing in all blocks but permitting the rule to fall out is not safe
The 75% rule doesn't seem to make much difference then.
The idea sounds like the rule activates for 75% and is locked in for 95%, but really 95% is the only one that matters.
Before the point of no return happens, there is no real harm in allowing miners create version 2 blocks with the wrong block height or version 3 blocks which violate the new rules.
It creates a slight incentive to update nodes so they can determine if an updated block is valid.
Setting the thresholds is tricky. First you much recognize that this process is emphatically _NOT_ a vote, it is a safe transition mechanism for behavior changes which are up front believed to have (near universal) consensus. Miners are vendors for the network, providing a service and getting paid for it; their opinion counts for very little here compared to all the other users of Bitcoin, except in terms of avoiding a consensus fault which disrupts SPV clients which aren't enforcing the rules themselves-- it's just an objective question,:how likely is a significant consensus divergence if the rule is enforced now.
If the feature activates when there is only a minor super-majority and a invalid-to-the-new-rules block gets created then there will be a rather long reorganization opening up SPV clients to theft; effectively handing over the non-upgraded haspower to an attacker. If you think in terms of how much hashpower one is willing to hand to an attacker 25% sure seems like a lot! Of course-- it isn't quite that simple, because if the soft-fork is the only thing going on (e.g. no additional forking bug being exploited against non-updated nodes) then the forked off nodes will reorg back when the other chain gets decisively ahead. Keep in mind, even with soft-forks that only impact non-standard transactions we cannot be sure some miner won't go and mine one (invalid signatures incompatible with BIP66 were still being regularly mined every few days until an extensive manual effort was recently made to hunt down and get miners to unpatch their software. (In one case a miner had simply undermined all signature validation on his system.)
Another factor is that the estimate is very noisy, you might observe 60% density when only 40% is actually enforcing. Activating in that case would potentially result an an enormous (e.g. tens of blocks) reorg with non-negligible probability. The actual hashpower levels also change, especially due to the extreme consolidation of hash-power-- you might have 60% but then a single facility shuts off or loses power and again-- it's back to 40%, with a severe risk of a large reorg.
The fact that the upper threshold isn't 100% is already a compromise to prevent being totally stuck due to absentee operators. One could debate how much risk of hold up vs risk of consensus fault is tolerable; but whatever the thresholds are they should be pretty conservative.
In terms of safety before lock-in: Most soft-fork features are unsafe until locked in and enforcing in all blocks but permitting the rule to fall out is not safe... e.g. consider CLTV as an example. CLTV is enforced you think you can use it, you write some refunds, and then get completely ripped off when the txouts are spent via the refund path months before they were due when the network momentarily goes below threshold.
If the feature activates when there is only a minor super-majority and a invalid-to-the-new-rules block gets created then there will be a rather long reorganization opening up SPV clients to theft; effectively handing over the non-upgraded haspower to an attacker. If you think in terms of how much hashpower one is willing to hand to an attacker 25% sure seems like a lot! Of course-- it isn't quite that simple, because if the soft-fork is the only thing going on (e.g. no additional forking bug being exploited against non-updated nodes) then the forked off nodes will reorg back when the other chain gets decisively ahead. Keep in mind, even with soft-forks that only impact non-standard transactions we cannot be sure some miner won't go and mine one (invalid signatures incompatible with BIP66 were still being regularly mined every few days until an extensive manual effort was recently made to hunt down and get miners to unpatch their software. (In one case a miner had simply undermined all signature validation on his system.)
Another factor is that the estimate is very noisy, you might observe 60% density when only 40% is actually enforcing. Activating in that case would potentially result an an enormous (e.g. tens of blocks) reorg with non-negligible probability. The actual hashpower levels also change, especially due to the extreme consolidation of hash-power-- you might have 60% but then a single facility shuts off or loses power and again-- it's back to 40%, with a severe risk of a large reorg.
The fact that the upper threshold isn't 100% is already a compromise to prevent being totally stuck due to absentee operators. One could debate how much risk of hold up vs risk of consensus fault is tolerable; but whatever the thresholds are they should be pretty conservative.
In terms of safety before lock-in: Most soft-fork features are unsafe until locked in and enforcing in all blocks but permitting the rule to fall out is not safe... e.g. consider CLTV as an example. CLTV is enforced you think you can use it, you write some refunds, and then get completely ripped off when the txouts are spent via the refund path months before they were due when the network momentarily goes below threshold.
That is, once you pass the 75% then all non-standard version X blocks get rejected, that means that those small percentage of miners have to keep getting 5% of the blocks hashed and also that they have to be hashing them to a version < X (because if they were hashing to a non-standard version X, they'd be getting rejected by most miners because of the 75% threshold having been passed). I apologize if I misunderstood something.
The 75% rule means that new version blocks are verified. Once 75% is hit, then version 3 blocks (or higher) that fail the new rules are rejected.
It means that the 75% threshold doesn't really mean much, since you can still include the transactions in version 2 blocks.
I think a better rule would be that after 75% is achieved, then version 2 blocks would have to meet the rules for version 3 blocks. After 75% is achieved, then version 2 blocks are votes to reject the BIP.
Clients could have a rule that if 75% of the last 1000 blocks are greater than CURRENT_VERSION, then the client produces coinbase only blocks.
95% becomes the point of no return. All blocks must be version 3. Old clients could continue making coinbase only blocks and hope for the best.
I think I see what you mean. But is it correct that that small percentage of miners can actually hinder the softfork. That is, once you pass the 75% then all non-standard version X blocks get rejected, that means that those small percentage of miners have to keep getting 5% of the blocks hashed and also that they have to be hashing them to a version < X (because if they were hashing to a non-standard version X, they'd be getting rejected by most miners because of the 75% threshold having been passed). I apologize if I misunderstood something.
This are the current softfork cutoff rules:
Quote
75% rule: If 750 of the last 1,000 blocks are version X or greater, reject invalid version X blocks. (testnet3: 51 of last 100)
95% rule ("Point of no return"): If 950 of the last 1,000 blocks are version X or greater, reject all version Y (Y
Isn't the 95% requirement an overkill? It allows a few % of miners to indefinitely hinder a softfork.
If the requirement is reduced to 900/1000, it is still almost impossible for 87% of miners to achieve (probability=0.2%). So in the worst case, we would temporarily waste up to 15% of hashing power while they will be forced to upgrade immediately. No non-upgrading full nodes will be fooled as the probability for the 13% minority to have 6 blocks faster is only about 0.1% (as calculated by Satoshi in the white paper)
Making it as 1800/2000 will be even safer
95% rule ("Point of no return"): If 950 of the last 1,000 blocks are version X or greater, reject all version Y (Y
Isn't the 95% requirement an overkill? It allows a few % of miners to indefinitely hinder a softfork.
If the requirement is reduced to 900/1000, it is still almost impossible for 87% of miners to achieve (probability=0.2%). So in the worst case, we would temporarily waste up to 15% of hashing power while they will be forced to upgrade immediately. No non-upgrading full nodes will be fooled as the probability for the 13% minority to have 6 blocks faster is only about 0.1% (as calculated by Satoshi in the white paper)
Making it as 1800/2000 will be even safer
Jump to: