From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id B6048C0001 for ; Sat, 27 Feb 2021 17:55:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 9D2C24F02D for ; Sat, 27 Feb 2021 17:55:08 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=dashjr.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9tbvYH6niuC for ; Sat, 27 Feb 2021 17:55:06 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) by smtp4.osuosl.org (Postfix) with ESMTP id C41B74EF74 for ; Sat, 27 Feb 2021 17:55:06 +0000 (UTC) Received: from ishibashi.lan (unknown [12.190.236.214]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id 49ED238A009F; Sat, 27 Feb 2021 17:55:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dashjr.org; s=zinan; t=1614448505; bh=2jJkIFs/7VnMqjmoj9x5GlXrO5iqHdn/3VDQD6K4PTY=; h=From:To:Subject:Date:References:In-Reply-To; b=H+l2Xbof+kD0aC0CCMtYbQ3wqA+zQWCvgcnGHyMgOTDlI7b36JWs8xLYGRRjBXFWA 8Ijb5NGAo74ucDGnN2NSVAgxGH+CI8CFuu+X5wA4DzaNt8AdEiDBH6Mi/t+IKLEsy0 NU1WAqf8tDr4ckrGBllBoiEdGLqaE9l4RTxOVUCg= From: Luke Dashjr To: bitcoin-dev@lists.linuxfoundation.org, Gregorio Guidi Date: Sat, 27 Feb 2021 17:55:00 +0000 User-Agent: KMail/1.9.10 References: In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <202102271755.02271.luke@dashjr.org> Subject: Re: [bitcoin-dev] Exploring alternative activation mechanisms: decreasing threshold X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2021 17:55:08 -0000 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