Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id BDC22C000A for ; Wed, 7 Apr 2021 05:01:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 990AA402AF for ; Wed, 7 Apr 2021 05:01:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.653 X-Spam-Level: X-Spam-Status: No, score=-1.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 l52TJdy_D3gz for ; Wed, 7 Apr 2021 05:01:58 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from ozlabs.org (bilbo.ozlabs.org [IPv6:2401:3900:2:1::2]) by smtp4.osuosl.org (Postfix) with ESMTPS id 57896402A5 for ; Wed, 7 Apr 2021 05:01:58 +0000 (UTC) Received: by ozlabs.org (Postfix, from userid 1011) id 4FFXLS74sfz9sWK; Wed, 7 Apr 2021 15:01:52 +1000 (AEST) From: Rusty Russell To: Ryan Grant , Bitcoin Protocol Discussion In-Reply-To: References: <874kgkkpji.fsf@rustcorp.com.au> Date: Wed, 07 Apr 2021 14:31:13 +0930 Message-ID: <87pmz6it7q.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes 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: Wed, 07 Apr 2021 05:01:59 -0000 Ryan Grant writes: > On Tue, Apr 6, 2021 at 11:58 PM Rusty Russell via bitcoin-dev > wrote: >> The core question always was: what do we do if miners fail to activate? >> >> [...] Speedy Trial takes the approach that "let's pretend we didn't >> *actually* ask [miners]". > > What ST is saying is that a strategy of avoiding unnecessary risk is > stronger than a strategy of brinkmanship when brinkmanship wasn't > our only option. Having deescalation in the strategy toolkit makes > Bitcoin stronger. I don't believe that having a plan is brinkmanship or an escalation. During the segwit debate, Pieter Wuille said that users should decide. I've been thinking about that a lot, especially about what that means in a practical sense where the normal developer / miner dynamic has failed. >> It's totally a political approach, to avoid facing the awkward question. >> Since I believe that such prevaricating makes a future crisis less >> predictable, I am forced to conclude that it makes bitcoin less robust. > > LOT=true does face the awkward question, but there are downsides: > > - in the requirement to drop blocks from apathetic miners (although > as Luke-Jr pointed out in a previous reply on this list they have > no contract under which to raise a complaint); and Surely, yes. If the users of bitcoin decide blocks are invalid, they're invalid. With a year's warning, and developer and user consensus against them, I think we've reached the limits of acceptable miner apathy. > - in the risk of a chain split, should gauging economic majority > support - which there is zero intrinsic tooling for - go poorly. Agreed that we should definitely do better here: in practice people would rely on third party explorers for information on the other side of the split. Tracking the cumulative work on invalid chains would be a good idea for bitcoind in general (AJ suggested this, IIRC). >> Personally, I think the compromise position is using LOT=false and >> having those such as Luke and myself continue working on a LOT=true >> branch for future consideration. It's less than optimal, but I >> appreciate that people want Taproot activated more than they want >> the groundwork future upgrades. > > Another way of viewing the current situation is that should > brinkmanship be necessary, then better tooling to resolve a situation > that requires brinkmanship will be invaluable. But: > > - we do not need to normalize brinkmanship; > > - designing brinkmanship tooling well before the next crisis does > not require selecting conveniently completed host features to > strap the tooling onto for testing; and Again, openly creating a contingency plan is not brinkmanship, it's normal. I know that considering these scenarios is uncomfortable; I avoid conflict myself! But I feel obliged to face this as a real possibility. I think we should be normalizing the understanding that bitcoin users are the ultimate decider. By offering *all* of them the tools to do so we show this isn't lip-service, but something that businesses and everyone else in the ecosystem should consider. > - it's already the case that a UASF branch can be prepared along > with ST (ie. without requiring LOT=false), although the code is a > bit more complex and the appropriate stopheight a few blocks later. I don't believe this is true, unless you UASF before ST expires? ST is explicitly designed *not* to give time to conclude that miners are stalling (unless something has changed from the initial 3 month proposal?). > Although your NACK is well explained, for the reasons above I am > prepared to run code that overrides it. Good. In the end, we're all at the whim of the economic majority. Cheers! Rusty.