BIP 8: Make threshold configurable, and reduce recommendation to 90% #1069

No description provided.

ACK 6ea5857b62d37724b1ea6947e0dc847afbc1b644 -- This is what was agreed during 2021/02 Taproot activation meeting in which most participants agreed it was reasonable.

I think a reduced threshold is probably a good idea. The downsides of a reduced threshold can be offset by putting in an effort to go nag parties that haven't updated during the period between lock in and activation.

90% seems like a reasonable threshold, last i saw anyone run the probability of long forks of non-upgraded miners, 90% was reasonably unlikely to cause them. That said, much lower and you start to hit unlikely-but-unreasonable-risk territory, at least if I recall the numbers presented to me correctly.

I’m not sure why this needs to be a parameter so much as an amount - I worry that defining everything as a “parameter” normalizes ideas that are probably bad ideas - why would anyone ever bother with readiness signaling with activation thresholds materially less than 90%? If there’s material fork risk, might as well go for a flag day and make it explicit.

On Feb 17, 2021, at 15:59, Luke Dashjr notifications@github.com wrote:

 You can view, comment on, or merge this pull request online at:

#1069

Commit Summary

BIP 8: Make threshold a parameter BIP 8: Reduce threshold recommendation to 90% File Changes

M bip-0008.mediawiki (4) Patch Links:

#1069.patch #1069.diff — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

@TheBlueMatt I did a simple simulation here: https://github.com/jonasnick/bip8-tester/blob/master/threshold.py

Probability that unupdated node is on >= 2 block invalid fork with 95.0% threshold: 1.22%
Probability that unupdated node is on >= 3 block invalid fork with 95.0% threshold: 0.17%
Probability that unupdated node is on >= 2 block invalid fork with 90.0% threshold: 4.81%
Probability that unupdated node is on >= 3 block invalid fork with 90.0% threshold: 1.28%
Probability that unupdated node is on >= 2 block invalid fork with 85.0% threshold: 10.45%
Probability that unupdated node is on >= 3 block invalid fork with 85.0% threshold: 4.13%

This represents the worst-case of miners not updating after lock-in. In light of that, 90% doesn't seem too bad while 85% would be quite a bit worse. Defining the threshold as a parameter may help increasing it - depending on the circumstances - to 95% again because that's just safer.

I'm not sure there's any reason to even look at less than the standard confirmation minimum of 6 blocks...?

Using @jonasnick's code, modified:

Probability that unupdated node is on >= 6 block invalid fork with 95.0% threshold: 0.00030%
Probability that unupdated node is on >= 8 block invalid fork with 95.0% threshold: 0.00000%
Probability that unupdated node is on >= 6 block invalid fork with 90.0% threshold: 0.02320%
Probability that unupdated node is on >= 8 block invalid fork with 90.0% threshold: 0.00200%
Probability that unupdated node is on >= 6 block invalid fork with 85.0% threshold: 0.27080%
Probability that unupdated node is on >= 8 block invalid fork with 85.0% threshold: 0.05560%

@TheBlueMatt I made it a parameter because I'm not sure 90% is going to be ideal for every softfork.

For example, if a softfork only affects miners, it might make sense to use a lower, or perhaps higher threshold, with an expectation that miners are also making a decision and not merely activating a predecided change.

Would it be satisfactory to simply make the 90% recommendation stronger somehow? (Though it already says "should"...)

why would anyone ever bother with readiness signaling with activation thresholds materially less than 90%?

I can't envisage a scenario where it should be less than 90 percent personally but we can't tell the future and I think we should lean on flexibility for the consideration of future soft forks. I don't think there is certainty that 90 percent should always be used. A future soft fork may choose to go back up to 95 percent for example.

Would it be satisfactory to simply make the 90% recommendation stronger somehow? (Though it already says "should"...)

I think "should" and the setting of precedent for future of soft forks is strong enough personally. Without flexibility, future soft fork proposals may merely choose to ditch this BIP and create a new BIP for the purpose of the activation mechanism. I think we should do our best to avoid that necessity.

I'm not sure there's any reason to even look at less than the standard confirmation minimum of 6 blocks...?

Sadly, 6 isn't really "standard" anymore. Lots of users accept at 3 confirmations (many 1, but there's not really anything we can do about that, they have fork risk monthly anyway).

I made it a parameter because I'm not sure 90% is going to be ideal for every softfork.

For example, if a softfork only affects miners, it might make sense to use a lower, or perhaps higher threshold, with an expectation that miners are also making a decision and not merely activating a predecided change.

I don't think this holds - a lower threshold carries needles fork risk no matter the scenario.

Would it be satisfactory to simply make the 90% recommendation stronger somehow? (Though it already says "should"...)

I think maybe it makes sense to say something stronger about 90%, eg MUST be 90% or higher, likely with a justification section that mentions the above calculations and notes that long forks can put significant user funds at risk.

The important thing is to describe what the reasonable values for the threshold are.

The important thing is to describe what the reasonable values for the threshold are.

Doesn't this do that already, at least? It says it should be 90% (except on testnet)...

Err, sorry, I meant that if its parameterized with an intent that people may change it, it probably makes sense to describe why the suggested values are suggested, not just write that you should use 90 or whatever. This would presumably be two sentences and the math that jonas posted above.

The opinion that 3 block confirmation should be given special attention isn't universal (I certainly don't agree).

This seems good enough to merge; but feel free to open another PR elaborating further on reason(s) for the recommendation if you strongly think it's needed.

Post-merge ACK.