Exploring alternative activation mechanisms: decreasing threshold
7 messages, 25 Feb to 1 Mar 2021. Started by Gregorio Guidi.
Gregorio Guidi (2), Ryan Grant (2), Luke Dashjr, Matt Corallo, Anthony Towns
Hello,
I followed the debate on LOT=false / LOT=true trying to get a grasp of the balance of risks and advantages. The summary by Aaron van Wirdum [1] explains well the difficulties to find a good equilibrium... it concludes that "perhaps, a new possibility will present itself".
Thinking about such a "new possibility" that overcomes the LOT=true/false dichotomy, I would like to offer the following proposal. It could be called "decreasing threshold activation".
Decreasing threshold activation works similarly to BIP8, with the difference that the threshold that triggers the STARTED -> LOCKED_IN transition starts at 100% for the first retargeting period, and then is gradually reduced on each period in steps of 24 blocks (~1,2%). More precisely:
On the 1st period (starting on start_height): if 2016 out of 2016 blocks signal, the state is changed to LOCKED_IN on the next period (otherwise stays STARTED) On the 2nd period: if 1992 out of 2016 blocks signal (~98.8%), the state transitions to LOCKED_IN on the next period On the 3rd period: if 1968 out of 2016 blocks signal (~97.6%), the state transitions to LOCKED_IN on the next period ... On the 14th period (~6 months): if 1704 out of 2016 blocks signal (~84.5%), the state transitions to LOCKED_IN on the next period ... On the 27th period (~12 months): if 1392 out of 2016 blocks signal (~69.0%), the state transitions to LOCKED_IN on the next period ... On the 40th period (~18 months): if 1080 out of 2016 blocks signal (~53.6%), the state transitions to LOCKED_IN on the next period ... On the 53th period (~24 months): if 768 out of 2016 blocks signal (~38.1%), the state transitions to LOCKED_IN on the next period ... On the 66th period (~30 months): if 456 out of 2016 blocks signal (~22.6%), the state transitions to LOCKED_IN on the next period ... On the 79th period (~36 months): if 144 out of 2016 blocks signal (~7.1%), the state transitions to LOCKED_IN on the next period ... On the 84th and final period (~39 months): if 24 out of 2016 blocks signal (~1.2%), the state transitions to LOCKED_IN on the next period, otherwise goes to FAILED
(For reference, I include below a snippet of pseudocode for the decreasing thresholds in the style of BIP8 and BIP9.)
Here are the main features and advantages of this approach:
1. It is relatively conservative at the beginning: for activation to happen in the first year, it requires a clear majority of signaling hashrate, indicating that the activation is relatively safe. Only later the threshold starts to move towards "unsafe" territory, accepting the tradeoff of less support from existing hashrate in exchange for ensuring that the activation eventually happens.
2. Like LOT=true, the activation will always occur in the end (except in the negligible case where less than 1.2% of hashrate supports it).
3. This approach is quite easy to implement, in particular it avoids the extra code to deal with the MUST_SIGNAL period.
4. There are no parameters to set (except startheight). I am a KISS fan, so this is a plus for me, making the activation mechanism robust and predictable with less chance for users to shoot themselves in the foot. It is also a plus for me that - if adopted as the default mechanism - it would require very little discussion on how to activate future soft-forks. In fact I think it would be a winning move for Core to commit to such a scheme, to avoid getting lost in game-theoretic rabbit holes.
5. Since there is no MUST_SIGNAL period, no automatic chain split occurs around activation when not all miners have upgraded (so activation is generally as benign as a MASF). A chain split will occur only when/if an invalid block is created (and this requires dedicated effort! it can only happen by circumventing the normal policy rules [2]). This mitigates the risk of reorgs and involuntary forks around activation, even with low miner signaling.
6. It removes motivation to create UASF clients that force activation. While individual nodes could still try to force a quicker activation, the motivation to do so is reduced since the same result is obtained just by waiting a little more.
7. Compared to LOT=true, activation is cleaner and quicker when it is relatively safe to do so (when the signaling hashrate is - let's say - in the 70%-80% range). On the other hand, activation is pushed further and further in time when it is less safe (when signaling hashrate is <50%, meaning that there is a serious risk that users/miners that did not upgrade start following an alternative chain). This gives everyone time to prepare properly for such a potentially disruptive event.
8. If a significant number of users and miners consciously decide (for whatever reasons) that they don't want to upgrade and want to fork themselves off from the chain followed by Core (as is their prerogative), they will have time to do so safely.
9. Compared to the strategy of doing LOT=false and then LOT=true if it fails, using the decreasing threshold approach may not seem very different. But it completely removes the need to fiddle with different client releases and with the issues associated with deployed nodes with different consensus parameters.
All in all, reading the various perspectives on this mailing list and outside I have the feeling that the strongest arguments against LOT=true have at their core a certain uneasiness with the MUST_SIGNAL mechanism and the related automatic chain split on activation, which is something that greatly complicates the analysis (but please tell me if I am wrong...). In this sense, this proposal achieves the big objective of always ending in activation (like LOT=true) without resorting to MUST_SIGNAL and chain splits.
A final note: this proposal should be seen as somewhat independent from the discussion on taproot activation. Personally I would be happy with a LOT=false activation for taproot that succeeds quickly, while the decreasing threshold approach could be evaluated as potential default activation mechanism for the future.
I would be happy to hear what you think about this. What are the possible issues/drawbacks of using this mechanism?
Thanks,
Gregorio
[2] This was not the case in the past for upgrades such as BIP16 (P2SH), which generated frequent reorgs due to a combination of low activation threshold (55%) and no policy protection. But for upgrades such as taproot the normal policy rules prevent the creation of invalid blocks by non-upgraded miners. See https://blog.bitmex.com/the-arts-of-making-softforks-protection-by-policy-rule/
Pseudocode:
case STARTED:
int elapsed_periods = (block.height - startheight) / 2016;
if (elapsed_periods > 2016 / 24) {
return FAILED;
}
int threshold = 2016 - 24 * (elapsed_periods - 1);
int count = 0;
walk = block;
for (i = 0; i < 2016; i++) {
walk = walk.parent;
if (walk.nVersion & 0xE0000000 == 0x20000000 && (walk.nVersion >> bit) & 1 == 1) {
++count;
}
}
if (count >= threshold) {
return LOCKED_IN;
}
return STARTED;Huh. I like the mechanism.
I like the honesty that once a feature with high demand and safety is ready, activation pressure will keep increasing.
The gradual march of time in this Decreasing Threshold proposal is predictable and incremental in ways that help avoid brinkmanship.
Avoiding the hard fork dynamic (that LOT=true requires) prevents some chain splits, but activation under political opposition may then still depend on a UASF. If I thought the time had come to line up a UASF for a feature, I'd first want to have nodes out there running this softer Decreasing Threshold activation (maybe before it fails).
It's also not as unresponsive to miner wisdom as LOT=true. Conceptually, it asks miners to arbitrate both version adoption as well as whether nodes which haven't upgraded face risks in an early activation. Should miners find themselves in dramatic unanimity, they even have enough influence to technically fail any activation.
This has the same problems BIP149 did: since there is no signalling, it is ambiguous whether the softfork has activated at all. Both anti-SF and pro-SF nodes will remain on the same chain, with conflicting perceptions of the rules, and resolution (if ever) will be chaotic. Absent resolution, however, there is a strong incentive not to rely on the rules, and thus it may never get used, and therefore also never resolved.
Additionally, it loses the flexibility of BIP 8 to, after the initial deployment, move the timeoutheight sooner.
Luke
On Thursday 25 February 2021 22:33:25 Gregorio Guidi via bitcoin-dev wrote:
Quoted text (165 lines)
> Hello, > > I followed the debate on LOT=false / LOT=true trying to get a grasp of > the balance of risks and advantages. The summary by Aaron van Wirdum [1] > explains well the difficulties to find a good equilibrium... it > concludes that "perhaps, a new possibility will present itself". > > Thinking about such a "new possibility" that overcomes the > LOT=true/false dichotomy, I would like to offer the following proposal. > It could be called "decreasing threshold activation". > > Decreasing threshold activation works similarly to BIP8, with the > difference that the threshold that triggers the STARTED -> LOCKED_IN > transition starts at 100% for the first retargeting period, and then is > gradually reduced on each period in steps of 24 blocks (~1,2%). More > precisely: > > On the 1st period (starting on start_height): if 2016 out of 2016 blocks > signal, the state is changed to LOCKED_IN on the next period (otherwise > stays STARTED) > On the 2nd period: if 1992 out of 2016 blocks signal (~98.8%), the state > transitions to LOCKED_IN on the next period > On the 3rd period: if 1968 out of 2016 blocks signal (~97.6%), the state > transitions to LOCKED_IN on the next period > ... > On the 14th period (~6 months): if 1704 out of 2016 blocks signal > (~84.5%), the state transitions to LOCKED_IN on the next period > ... > On the 27th period (~12 months): if 1392 out of 2016 blocks signal > (~69.0%), the state transitions to LOCKED_IN on the next period > ... > On the 40th period (~18 months): if 1080 out of 2016 blocks signal > (~53.6%), the state transitions to LOCKED_IN on the next period > ... > On the 53th period (~24 months): if 768 out of 2016 blocks signal > (~38.1%), the state transitions to LOCKED_IN on the next period > ... > On the 66th period (~30 months): if 456 out of 2016 blocks signal > (~22.6%), the state transitions to LOCKED_IN on the next period > ... > On the 79th period (~36 months): if 144 out of 2016 blocks signal > (~7.1%), the state transitions to LOCKED_IN on the next period > ... > On the 84th and final period (~39 months): if 24 out of 2016 blocks > signal (~1.2%), the state transitions to LOCKED_IN on the next period, > otherwise goes to FAILED > > (For reference, I include below a snippet of pseudocode for the > decreasing thresholds in the style of BIP8 and BIP9.) > > Here are the main features and advantages of this approach: > > 1. It is relatively conservative at the beginning: for activation to > happen in the first year, it requires a clear majority of signaling > hashrate, indicating that the activation is relatively safe. Only later > the threshold starts to move towards "unsafe" territory, accepting the > tradeoff of less support from existing hashrate in exchange for ensuring > that the activation eventually happens. > > 2. Like LOT=true, the activation will always occur in the end (except in > the negligible case where less than 1.2% of hashrate supports it). > > 3. This approach is quite easy to implement, in particular it avoids the > extra code to deal with the MUST_SIGNAL period. > > 4. There are no parameters to set (except startheight). I am a KISS fan, > so this is a plus for me, making the activation mechanism robust and > predictable with less chance for users to shoot themselves in the foot. > It is also a plus for me that - if adopted as the default mechanism - it > would require very little discussion on how to activate future > soft-forks. In fact I think it would be a winning move for Core to > commit to such a scheme, to avoid getting lost in game-theoretic rabbit > holes. > > 5. Since there is no MUST_SIGNAL period, no automatic chain split occurs > around activation when not all miners have upgraded (so activation is > generally as benign as a MASF). A chain split will occur only when/if an > invalid block is created (and this requires dedicated effort! it can > only happen by circumventing the normal policy rules [2]). This > mitigates the risk of reorgs and involuntary forks around activation, > even with low miner signaling. > > 6. It removes motivation to create UASF clients that force activation. > While individual nodes could still try to force a quicker activation, > the motivation to do so is reduced since the same result is obtained > just by waiting a little more. > > 7. Compared to LOT=true, activation is cleaner and quicker when it is > relatively safe to do so (when the signaling hashrate is - let's say - > in the 70%-80% range). On the other hand, activation is pushed further > and further in time when it is less safe (when signaling hashrate is > <50%, meaning that there is a serious risk that users/miners that did > not upgrade start following an alternative chain). This gives everyone > time to prepare properly for such a potentially disruptive event. > > 8. If a significant number of users and miners consciously decide (for > whatever reasons) that they don't want to upgrade and want to fork > themselves off from the chain followed by Core (as is their > prerogative), they will have time to do so safely. > > 9. Compared to the strategy of doing LOT=false and then LOT=true if it > fails, using the decreasing threshold approach may not seem very > different. But it completely removes the need to fiddle with different > client releases and with the issues associated with deployed nodes with > different consensus parameters. > > All in all, reading the various perspectives on this mailing list and > outside I have the feeling that the strongest arguments against LOT=true > have at their core a certain uneasiness with the MUST_SIGNAL mechanism > and the related automatic chain split on activation, which is something > that greatly complicates the analysis (but please tell me if I am > wrong...). In this sense, this proposal achieves the big objective of > always ending in activation (like LOT=true) without resorting to > MUST_SIGNAL and chain splits. > > A final note: this proposal should be seen as somewhat independent from > the discussion on taproot activation. Personally I would be happy with a > LOT=false activation for taproot that succeeds quickly, while the > decreasing threshold approach could be evaluated as potential default > activation mechanism for the future. > > I would be happy to hear what you think about this. What are the > possible issues/drawbacks of using this mechanism? > > Thanks, > > Gregorio > > [1] > https://bitcoinmagazine.com/articles/lottrue-or-lotfalse-this-is-the-last-h >urdle-before-taproot-activation > > [2] This was not the case in the past for upgrades such as BIP16 (P2SH), > which generated frequent reorgs due to a combination of low activation > threshold (55%) and no policy protection. But for upgrades such as > taproot the normal policy rules prevent the creation of invalid blocks > by non-upgraded miners. See > https://blog.bitmex.com/the-arts-of-making-softforks-protection-by-policy-r >ule/ > > Pseudocode: > > case STARTED: > int elapsed_periods = (block.height - startheight) / 2016; > if (elapsed_periods > 2016 / 24) { > return FAILED; > } > int threshold = 2016 - 24 * (elapsed_periods - 1); > int count = 0; > walk = block; > for (i = 0; i < 2016; i++) { > walk = walk.parent; > if (walk.nVersion & 0xE0000000 == 0x20000000 && > (walk.nVersion >> bit) & 1 == 1) { ++count; > } > } > if (count >= threshold) { > return LOCKED_IN; > } > return STARTED; > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
On 2/27/21 6:55 PM, Luke Dashjr wrote:
Quoted text (11 lines)
> This has the same problems BIP149 did: since there is no signalling, it is > ambiguous whether the softfork has activated at all. Both anti-SF and pro-SF > nodes will remain on the same chain, with conflicting perceptions of the > rules, and resolution (if ever) will be chaotic. Absent resolution, however, > there is a strong incentive not to rely on the rules, and thus it may never > get used, and therefore also never resolved. > > Additionally, it loses the flexibility of BIP 8 to, after the initial > deployment, move the timeoutheight sooner. > > Luke
I see the point about possible problems of not having immediate resolution in the case of a contentious activation. I guess in such cases a certain amount of chaos is unavoidable... I see the alternatives of BIP8(lot=true) and Decresing Thresholds as a choice between having the chaos earlier (BIP8), or leaving it dormant with the possibility of having it later (Decreasing Thresholds). You might be right: there is a cost in pushing forward the resolution, but overall I think the risks are roughly comparable.
Trying to see this scenario from a more general perspective (at this point the debate is more theoretical than practical, forgive me for that): let's we are say in the soft-fork situation where Core is at version X and a new version Y is released with new consensus rules to be activated. The risk that nodes at version X do not upgrade and start following an invalid chain (invalid for Y) cannot be completely avoided. So there is a basic choice to make as a first step:
* Option 1 (only safe soft-fork activation): Core decides that activating the soft fork can only be done with a strong guarantee that most of the hashrate follows version Y. This gives assurance that an invalid chain, if it appears, will be short-lived. That is: only lot=false is allowed for BIP8.
* Option 2 (possibly unsafe soft-fork activation): Core accepts the risk that the activation occurs even when there is no guarantee that most of the hashrate (or even a majority of the hashrate) follows Y, because the advantages of activation outweigh the risks. That is: Core will consider activation mechanisms stronger than BIP8(lot=false).
This is a difficult choice, and honestly I wouldn't blame at all the Core devs if they go for option 1, as it is the safest on paper. But here we are considering what happens under option 2...
Under option 2, the risk can be mitigated in various ways, with the key factors being these assumption:
* Assumption A1: there is strong evidence (gathered before and during the development of the soft-fork) that version Y will be adopted by the "economic majority", meaning that miners that mine a block invalid for Y are very likely to not have the value of the block recognized by the counterparties with which they normally transact. In other words: mining invalid blocks likely leads to an economic loss.
* Assumption A2: enough lead time is given before a possibly unsafe activation, so that during this period it is possible to diffuse widely and loudly the message on the risks associated to not upgrading to Y. Given enough time, most economic agents will have made up their mind and acted accordingly (by upgrading, or possibly by forking themselves off from the Y chain in a safe manner, creating a forked coin).
I think both BIP8(lot=true) and Decreasing Threshold work decently under these assumptions. But in the worst case bip8(lot=true) forces resolution immediately upon activation, forcing an economic loss immediately on non-upgraded miners, while Decreasing Threshold keeps the issue lingering a bit more but is more lenient, forcing the economic loss on the miners only at the moment that they mine an invalid block. In addition, it gives more time for upgrading (and better fulfilling assumption A2) before and after activation.
About the final point on BIP8 flexibility, I can say that sometimes not having to take a difficult choice can be an advantage... :)
Thanks for your insight and for your work, cheers,
Gregorio
Quoted text (166 lines)
> On Thursday 25 February 2021 22:33:25 Gregorio Guidi via bitcoin-dev wrote: >> Hello, >> >> I followed the debate on LOT=false / LOT=true trying to get a grasp of >> the balance of risks and advantages. The summary by Aaron van Wirdum [1] >> explains well the difficulties to find a good equilibrium... it >> concludes that "perhaps, a new possibility will present itself". >> >> Thinking about such a "new possibility" that overcomes the >> LOT=true/false dichotomy, I would like to offer the following proposal. >> It could be called "decreasing threshold activation". >> >> Decreasing threshold activation works similarly to BIP8, with the >> difference that the threshold that triggers the STARTED -> LOCKED_IN >> transition starts at 100% for the first retargeting period, and then is >> gradually reduced on each period in steps of 24 blocks (~1,2%). More >> precisely: >> >> On the 1st period (starting on start_height): if 2016 out of 2016 blocks >> signal, the state is changed to LOCKED_IN on the next period (otherwise >> stays STARTED) >> On the 2nd period: if 1992 out of 2016 blocks signal (~98.8%), the state >> transitions to LOCKED_IN on the next period >> On the 3rd period: if 1968 out of 2016 blocks signal (~97.6%), the state >> transitions to LOCKED_IN on the next period >> ... >> On the 14th period (~6 months): if 1704 out of 2016 blocks signal >> (~84.5%), the state transitions to LOCKED_IN on the next period >> ... >> On the 27th period (~12 months): if 1392 out of 2016 blocks signal >> (~69.0%), the state transitions to LOCKED_IN on the next period >> ... >> On the 40th period (~18 months): if 1080 out of 2016 blocks signal >> (~53.6%), the state transitions to LOCKED_IN on the next period >> ... >> On the 53th period (~24 months): if 768 out of 2016 blocks signal >> (~38.1%), the state transitions to LOCKED_IN on the next period >> ... >> On the 66th period (~30 months): if 456 out of 2016 blocks signal >> (~22.6%), the state transitions to LOCKED_IN on the next period >> ... >> On the 79th period (~36 months): if 144 out of 2016 blocks signal >> (~7.1%), the state transitions to LOCKED_IN on the next period >> ... >> On the 84th and final period (~39 months): if 24 out of 2016 blocks >> signal (~1.2%), the state transitions to LOCKED_IN on the next period, >> otherwise goes to FAILED >> >> (For reference, I include below a snippet of pseudocode for the >> decreasing thresholds in the style of BIP8 and BIP9.) >> >> Here are the main features and advantages of this approach: >> >> 1. It is relatively conservative at the beginning: for activation to >> happen in the first year, it requires a clear majority of signaling >> hashrate, indicating that the activation is relatively safe. Only later >> the threshold starts to move towards "unsafe" territory, accepting the >> tradeoff of less support from existing hashrate in exchange for ensuring >> that the activation eventually happens. >> >> 2. Like LOT=true, the activation will always occur in the end (except in >> the negligible case where less than 1.2% of hashrate supports it). >> >> 3. This approach is quite easy to implement, in particular it avoids the >> extra code to deal with the MUST_SIGNAL period. >> >> 4. There are no parameters to set (except startheight). I am a KISS fan, >> so this is a plus for me, making the activation mechanism robust and >> predictable with less chance for users to shoot themselves in the foot. >> It is also a plus for me that - if adopted as the default mechanism - it >> would require very little discussion on how to activate future >> soft-forks. In fact I think it would be a winning move for Core to >> commit to such a scheme, to avoid getting lost in game-theoretic rabbit >> holes. >> >> 5. Since there is no MUST_SIGNAL period, no automatic chain split occurs >> around activation when not all miners have upgraded (so activation is >> generally as benign as a MASF). A chain split will occur only when/if an >> invalid block is created (and this requires dedicated effort! it can >> only happen by circumventing the normal policy rules [2]). This >> mitigates the risk of reorgs and involuntary forks around activation, >> even with low miner signaling. >> >> 6. It removes motivation to create UASF clients that force activation. >> While individual nodes could still try to force a quicker activation, >> the motivation to do so is reduced since the same result is obtained >> just by waiting a little more. >> >> 7. Compared to LOT=true, activation is cleaner and quicker when it is >> relatively safe to do so (when the signaling hashrate is - let's say - >> in the 70%-80% range). On the other hand, activation is pushed further >> and further in time when it is less safe (when signaling hashrate is >> <50%, meaning that there is a serious risk that users/miners that did >> not upgrade start following an alternative chain). This gives everyone >> time to prepare properly for such a potentially disruptive event. >> >> 8. If a significant number of users and miners consciously decide (for >> whatever reasons) that they don't want to upgrade and want to fork >> themselves off from the chain followed by Core (as is their >> prerogative), they will have time to do so safely. >> >> 9. Compared to the strategy of doing LOT=false and then LOT=true if it >> fails, using the decreasing threshold approach may not seem very >> different. But it completely removes the need to fiddle with different >> client releases and with the issues associated with deployed nodes with >> different consensus parameters. >> >> All in all, reading the various perspectives on this mailing list and >> outside I have the feeling that the strongest arguments against LOT=true >> have at their core a certain uneasiness with the MUST_SIGNAL mechanism >> and the related automatic chain split on activation, which is something >> that greatly complicates the analysis (but please tell me if I am >> wrong...). In this sense, this proposal achieves the big objective of >> always ending in activation (like LOT=true) without resorting to >> MUST_SIGNAL and chain splits. >> >> A final note: this proposal should be seen as somewhat independent from >> the discussion on taproot activation. Personally I would be happy with a >> LOT=false activation for taproot that succeeds quickly, while the >> decreasing threshold approach could be evaluated as potential default >> activation mechanism for the future. >> >> I would be happy to hear what you think about this. What are the >> possible issues/drawbacks of using this mechanism? >> >> Thanks, >> >> Gregorio >> >> [1] >> https://bitcoinmagazine.com/articles/lottrue-or-lotfalse-this-is-the-last-h >> urdle-before-taproot-activation >> >> [2] This was not the case in the past for upgrades such as BIP16 (P2SH), >> which generated frequent reorgs due to a combination of low activation >> threshold (55%) and no policy protection. But for upgrades such as >> taproot the normal policy rules prevent the creation of invalid blocks >> by non-upgraded miners. See >> https://blog.bitmex.com/the-arts-of-making-softforks-protection-by-policy-r >> ule/ >> >> Pseudocode: >> >> case STARTED: >> int elapsed_periods = (block.height - startheight) / 2016; >> if (elapsed_periods > 2016 / 24) { >> return FAILED; >> } >> int threshold = 2016 - 24 * (elapsed_periods - 1); >> int count = 0; >> walk = block; >> for (i = 0; i < 2016; i++) { >> walk = walk.parent; >> if (walk.nVersion & 0xE0000000 == 0x20000000 && >> (walk.nVersion >> bit) & 1 == 1) { ++count; >> } >> } >> if (count >= threshold) { >> return LOCKED_IN; >> } >> return STARTED; >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation•org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Forced-signaling, or any form of signaling, does not materially change whether a soft fork can be seen to be safe to use. Pieter wrote a great post[1] some time ago that goes into depth about the security of soft forks, but, while miners can help to avoid the risk of forks, they aren't the determining factor in whether use of a fork should be considered safe (ie the fork "has activated").
Not only that, but the signaling methods used in BIP 8/9 (ie the version field in the block header) do not imply anything about whether mining pools are running full nodes which enforce the soft fork at all, only whether the pool has configured their stratum software to signal or not.
Ultimately, forced-signaling, or signaling period, are not a substitute for having a broad set of upgraded nodes across the network, including an overwhelming majority of economically-active nodes, enforcing the rules of a new fork. As this can be difficult to measure, waiting some time after a fork and examining upgrade patterns across the network is important.
Matt
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012014.html
On 2/27/21 12:55, Luke Dashjr via bitcoin-dev wrote:
Quoted text (185 lines)
> This has the same problems BIP149 did: since there is no signalling, it is > ambiguous whether the softfork has activated at all. Both anti-SF and pro-SF > nodes will remain on the same chain, with conflicting perceptions of the > rules, and resolution (if ever) will be chaotic. Absent resolution, however, > there is a strong incentive not to rely on the rules, and thus it may never > get used, and therefore also never resolved. > > Additionally, it loses the flexibility of BIP 8 to, after the initial > deployment, move the timeoutheight sooner. > > Luke > > > On Thursday 25 February 2021 22:33:25 Gregorio Guidi via bitcoin-dev wrote: >> Hello, >> >> I followed the debate on LOT=false / LOT=true trying to get a grasp of >> the balance of risks and advantages. The summary by Aaron van Wirdum [1] >> explains well the difficulties to find a good equilibrium... it >> concludes that "perhaps, a new possibility will present itself". >> >> Thinking about such a "new possibility" that overcomes the >> LOT=true/false dichotomy, I would like to offer the following proposal. >> It could be called "decreasing threshold activation". >> >> Decreasing threshold activation works similarly to BIP8, with the >> difference that the threshold that triggers the STARTED -> LOCKED_IN >> transition starts at 100% for the first retargeting period, and then is >> gradually reduced on each period in steps of 24 blocks (~1,2%). More >> precisely: >> >> On the 1st period (starting on start_height): if 2016 out of 2016 blocks >> signal, the state is changed to LOCKED_IN on the next period (otherwise >> stays STARTED) >> On the 2nd period: if 1992 out of 2016 blocks signal (~98.8%), the state >> transitions to LOCKED_IN on the next period >> On the 3rd period: if 1968 out of 2016 blocks signal (~97.6%), the state >> transitions to LOCKED_IN on the next period >> ... >> On the 14th period (~6 months): if 1704 out of 2016 blocks signal >> (~84.5%), the state transitions to LOCKED_IN on the next period >> ... >> On the 27th period (~12 months): if 1392 out of 2016 blocks signal >> (~69.0%), the state transitions to LOCKED_IN on the next period >> ... >> On the 40th period (~18 months): if 1080 out of 2016 blocks signal >> (~53.6%), the state transitions to LOCKED_IN on the next period >> ... >> On the 53th period (~24 months): if 768 out of 2016 blocks signal >> (~38.1%), the state transitions to LOCKED_IN on the next period >> ... >> On the 66th period (~30 months): if 456 out of 2016 blocks signal >> (~22.6%), the state transitions to LOCKED_IN on the next period >> ... >> On the 79th period (~36 months): if 144 out of 2016 blocks signal >> (~7.1%), the state transitions to LOCKED_IN on the next period >> ... >> On the 84th and final period (~39 months): if 24 out of 2016 blocks >> signal (~1.2%), the state transitions to LOCKED_IN on the next period, >> otherwise goes to FAILED >> >> (For reference, I include below a snippet of pseudocode for the >> decreasing thresholds in the style of BIP8 and BIP9.) >> >> Here are the main features and advantages of this approach: >> >> 1. It is relatively conservative at the beginning: for activation to >> happen in the first year, it requires a clear majority of signaling >> hashrate, indicating that the activation is relatively safe. Only later >> the threshold starts to move towards "unsafe" territory, accepting the >> tradeoff of less support from existing hashrate in exchange for ensuring >> that the activation eventually happens. >> >> 2. Like LOT=true, the activation will always occur in the end (except in >> the negligible case where less than 1.2% of hashrate supports it). >> >> 3. This approach is quite easy to implement, in particular it avoids the >> extra code to deal with the MUST_SIGNAL period. >> >> 4. There are no parameters to set (except startheight). I am a KISS fan, >> so this is a plus for me, making the activation mechanism robust and >> predictable with less chance for users to shoot themselves in the foot. >> It is also a plus for me that - if adopted as the default mechanism - it >> would require very little discussion on how to activate future >> soft-forks. In fact I think it would be a winning move for Core to >> commit to such a scheme, to avoid getting lost in game-theoretic rabbit >> holes. >> >> 5. Since there is no MUST_SIGNAL period, no automatic chain split occurs >> around activation when not all miners have upgraded (so activation is >> generally as benign as a MASF). A chain split will occur only when/if an >> invalid block is created (and this requires dedicated effort! it can >> only happen by circumventing the normal policy rules [2]). This >> mitigates the risk of reorgs and involuntary forks around activation, >> even with low miner signaling. >> >> 6. It removes motivation to create UASF clients that force activation. >> While individual nodes could still try to force a quicker activation, >> the motivation to do so is reduced since the same result is obtained >> just by waiting a little more. >> >> 7. Compared to LOT=true, activation is cleaner and quicker when it is >> relatively safe to do so (when the signaling hashrate is - let's say - >> in the 70%-80% range). On the other hand, activation is pushed further >> and further in time when it is less safe (when signaling hashrate is >> <50%, meaning that there is a serious risk that users/miners that did >> not upgrade start following an alternative chain). This gives everyone >> time to prepare properly for such a potentially disruptive event. >> >> 8. If a significant number of users and miners consciously decide (for >> whatever reasons) that they don't want to upgrade and want to fork >> themselves off from the chain followed by Core (as is their >> prerogative), they will have time to do so safely. >> >> 9. Compared to the strategy of doing LOT=false and then LOT=true if it >> fails, using the decreasing threshold approach may not seem very >> different. But it completely removes the need to fiddle with different >> client releases and with the issues associated with deployed nodes with >> different consensus parameters. >> >> All in all, reading the various perspectives on this mailing list and >> outside I have the feeling that the strongest arguments against LOT=true >> have at their core a certain uneasiness with the MUST_SIGNAL mechanism >> and the related automatic chain split on activation, which is something >> that greatly complicates the analysis (but please tell me if I am >> wrong...). In this sense, this proposal achieves the big objective of >> always ending in activation (like LOT=true) without resorting to >> MUST_SIGNAL and chain splits. >> >> A final note: this proposal should be seen as somewhat independent from >> the discussion on taproot activation. Personally I would be happy with a >> LOT=false activation for taproot that succeeds quickly, while the >> decreasing threshold approach could be evaluated as potential default >> activation mechanism for the future. >> >> I would be happy to hear what you think about this. What are the >> possible issues/drawbacks of using this mechanism? >> >> Thanks, >> >> Gregorio >> >> [1] >> https://bitcoinmagazine.com/articles/lottrue-or-lotfalse-this-is-the-last-h >> urdle-before-taproot-activation >> >> [2] This was not the case in the past for upgrades such as BIP16 (P2SH), >> which generated frequent reorgs due to a combination of low activation >> threshold (55%) and no policy protection. But for upgrades such as >> taproot the normal policy rules prevent the creation of invalid blocks >> by non-upgraded miners. See >> https://blog.bitmex.com/the-arts-of-making-softforks-protection-by-policy-r >> ule/ >> >> Pseudocode: >> >> case STARTED: >> int elapsed_periods = (block.height - startheight) / 2016; >> if (elapsed_periods > 2016 / 24) { >> return FAILED; >> } >> int threshold = 2016 - 24 * (elapsed_periods - 1); >> int count = 0; >> walk = block; >> for (i = 0; i < 2016; i++) { >> walk = walk.parent; >> if (walk.nVersion & 0xE0000000 == 0x20000000 && >> (walk.nVersion >> bit) & 1 == 1) { ++count; >> } >> } >> if (count >= threshold) { >> return LOCKED_IN; >> } >> return STARTED; >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation•org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
On Sat, Feb 27, 2021 at 5:55 PM Luke Dashjr via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (2 lines)
> This has the same problems BIP149 did: since there is no signalling, it is > ambiguous whether the softfork has activated at all.
You only need to see one block in the heaviest valid chain to dissolve that ambiguity. There are a lot of volunteers in this space who would (collectively) commit a few block's worth of hashrate, to know.
Quoted text (2 lines)
> Additionally, it loses the flexibility of BIP 8 to, after the initial > deployment, move the timeoutheight sooner.
It doesn't interfere with concurrent UASFs using any combination of timeoutheights.
On Sat, Feb 27, 2021 at 05:55:00PM +0000, Luke Dashjr via bitcoin-dev wrote:
[on the topic of non-signalled activation; ie "it doesn't matter what miners do or signal, the rules are active as of height X"]
Quoted text (6 lines)
> This has the same problems BIP149 did: since there is no signalling, it is > ambiguous whether the softfork has activated at all. Both anti-SF and pro-SF > nodes will remain on the same chain, with conflicting perceptions of the > rules, and resolution (if ever) will be chaotic. Absent resolution, however, > there is a strong incentive not to rely on the rules, and thus it may never > get used, and therefore also never resolved.
I think this might be a bit abstract, and less convincing than it might otherwise be.
To give a more explicit hypothetical: imagine that instead of making it impossible to use an optimisation when mining (as segwit did to ASICBoost, for which a patent had been applied for), a future soft-fork made it possible/easier to use some mining optimisation, and further that the optimisation is already patented, and that the patent wasn't widely known, and the owners of the patent have put everyone that they can under NDA.
Obviously mining optimisations are great for manufacturers -- it means a new generation of hardware is more efficient, which means miners want to upgrade to it; but patented mining optimisations are bad for decentralisation, because the're no competition in who can sell the new generation of mining hardware, so the patent holder is able to choose who is able to mine, and because miners control transaction selection, they could insist that the only people they'll sell to must censor transactions, and attempt to render miners that don't censor uncompetitive.
So the incentives there are:
- the patent holder wants the soft-fork to activate ASAP, and does not want to reveal the patent until after it's permanently locked in
- people who want decentralisation/competition and know about the patent want to stop the soft-fork from activation, or hard-fork it out after it's activated; but they can't talk about the patent because of NDA (or other bribes/threats intended to keep them silent)
Suppose further that the anti-patent folks either directly control 20% of hashpower, or are otherwise able to block the easy consensus path, and that the patent holder isn't able to get over 50% of hashpower to commit to orphaning non-signalling blocks to ensure early activation despite that. (Or, alternatively, that an approach like Matt suggests in "Straight Flag Day (Height)" is used, and there is no early-activation via hashpower supermajority option)
So under that scenario you reach the timeout, but without activation occurring. You also don't have any "reasonable, directed objection": everyone who could provide a reasonable objection is under NDA.
What's the scenario look like if you say "signalling doesn't matter, the software enforces the consensus rules"?
I think it'll be obvious there'll be two sets of software out there and supported and following a single chain; one set that enforces the new rules, and one set that doesn't, just as we had Bitcoin Unlimited back in the day. For at least a while, it will be safe to do spends protected by the new rules, because one set of nodes will enforce them, and any miners running the other software won't want see it in their mempool, and won't want to risk manually mining non-compliant transactions in case it turns out they're in the minority -- just as Bitcoin Unlimited miners didn't actually attempt to mine big blocks on mainnet back in the day.
So for a while, we have two divergent sets of maintained node software following the same chain, with advocates of both claiming that they're the majority. Some people will beleive the people claiming the new rules are safe, and commit funds to them, and as those funds are demonstrably not stolen, the number of people thinking it's safe will gradually increase -- presumably the new rules have some benefit other than to the patent holder, after all.
Eventually the patent gets revealed, though, just as covert ASICBoost did. Either NDA's expire, something violates them, someone rediscovers or reverse-engineers the idea, or the patent holder decides it's time to start either suing competitors or advertising.
What happens at that point? We have two sets of node software that both claim to have been in the majority, and one of which is clearly better for decentralisation.
But if we all just switch to that two things happen: we allow miners to steal the funds that users entrusted to the new rules, and anyone who was enforcing the new rules but is not following the day-to-day drama has a hard-fork event and can no longer follow the main chain until the find new software to run.
Alternatively, do we all switch to software that protects users funds and avoids hard-fork events, even though that software is bad for decentralisation, and do we do that precisely when the people who were advocating against using that software have just been proven to have been right all along?
In my opinion, while the first choice would be horrible, the second choice is completely at odds with human nature, so I think we'd end up making the horrible choice, and so should avoid getting into that scenario in the first place.
There's two ways we could avoid it: one is by not making changes any time there's the possibility of good reasons to be against something: so in the above, in an ideal world, we might have to delay activation until any potential NDAs will expire.
I'm not convinced that level of patience is really plausible either though: when covert ASICBoost became widely known, that was a "reasonable, directed objection" to segwit -- it made real mining hardware less efficient. We could have halted segwit deployment at that point and changed the spec so that it didn't prevent covert ASICBoost -- eg, sorting the wtxids prior to calculating the witness commitment would have made segwit compatible with ASICBoost without a large impact in any other way, and started again, perhaps with a BIP-91-alike to forbid miners signalling for segwit so that we could begin a second activation attempt sooner.
But we didn't do anything like that; instead we got segwit activated following the existing plan, and ended up with a hard-forked chain split in the form of BCH. I'd suggested a lighter weight compromise to some folks in early June 2017, to which one of the response was "The time for this soft of ASICBoost compromise would have been right after Scaling Bitcoin HK, when the mining hardware manufacturers realized the unintentional effects of segwit on their hardware. But that door has long since closed and at this point this proposal smells of appeasement." and I think that ended up being a pretty accurate take.
The other way of avoiding that horrible scenario is committing to the activation on-chain. That is, if the chain history satisfies property X, enforce the new rules; if it does not satisify that property, don't enforce the rules. That avoids the ambiguity: whether the new rules are active becomes a matter of history, not subject to ongoing debate and political posturing.
In the above scenario, where no one is able to discover/explain the actual problems with the soft-fork before it activates, activation by signalling means it likely activates unambiguously (because the opposition does not seem reasonable), and once the problems are known they have to be dealt with directly, there's no option to just pretend it never happened (and that it's therefore fine to steal any funds from people who thought it was able to be relied upon). That's much the same as how we've attempted to fix problems with p2sh in segwit or taproot.
Other failure modes are possible too.
One is if only a small number of rabid advocates run the code enforcing the flag day, and someone calls their bluff -- if you're excluding that failure case because "oh, but if core does it, plenty of people will run the enforcing code" then you're assuming the market will just do whatever the dev's say, and that devs are willing to test that assumption.
Another is if people factor in the above scenario and decide that if there's any ongoing controversy they won't use the new soft fork's rules -- if there's a chance everyone will switch over to the non-enforcing software, why take the risk? But that allows you to prevent a soft-fork from getting any adoption simply by maintaining an alternative client, and hiring sock puppets to create controversy.
Another thing to consider is that it probably makes sense to support "user-prohibited soft-forks" in a similar way to "user-activated soft-forks". Saying "it's active if and only if there's signalling" moves this action to whether you're required/prohibited from signalling, which is fairly straightforward, with easy to analyse results. If you make it be "just do/don't enforce the rules", then a user-prohibited soft-fork following the same scheme seems like it would be very uncertain.
Cheers, aj