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 6A347C000A for ; Mon, 29 Mar 2021 09:18:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 49FE4402FF for ; Mon, 29 Mar 2021 09:18:10 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 I3Q-Ag0QB7DP for ; Mon, 29 Mar 2021 09:18:08 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226]) by smtp4.osuosl.org (Postfix) with ESMTPS id 7E01F402F5 for ; Mon, 29 Mar 2021 09:18:08 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian)) id 1lQo26-0002EO-GV; Mon, 29 Mar 2021 19:18:05 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Mon, 29 Mar 2021 19:17:57 +1000 Date: Mon, 29 Mar 2021 19:17:57 +1000 From: Anthony Towns To: Russell O'Connor , Bitcoin Protocol Discussion Message-ID: <20210329091757.GA13603@erisian.com.au> References: <3286a7eb-9deb-77d6-4527-58e0c5882ae2@riseup.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Score-int: -18 X-Spam-Bar: - Subject: Re: [bitcoin-dev] Making the case for flag day activation of taproot 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: Mon, 29 Mar 2021 09:18:10 -0000 On Wed, Mar 03, 2021 at 02:08:21PM -0500, Russell O'Connor via bitcoin-dev wrote: > While I support essentially any proposed taproot activation method, including a > flag day activation, I think it is premature to call BIP8 dead. > > Even today, I still think that starting with BIP8 LOT=false is, generally > speaking, considered a reasonably safe activation method in the sense that I > think it will be widely considered as a "not wholly unacceptable" approach to > activation. If everyone started with lot=false, that would be true -- that was how segwit then BIP148/BIP91 worked, and was at least how I had been assuming people were going to make use of the new improved BIP8. But it seems more likely that when activation starts, even if many people run lot=false, many other people will run lot=true: see Luke's arguments on this list [0], Rusty's campaign for a lot=true option [1], the ##uasf channel (initial topic: Development of a Taproot activation implementation with default LOT=true) [2], or Samson's hat designs [3]. [0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018498.html [1] https://rusty.ozlabs.org/?p=628 https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f#gistcomment-3667311 [2] http://gnusha.org/uasf/ [3] https://twitter.com/Excellion/status/1363751091460956167 With lot=false and lot=true nodes active on the network, a chain split occurs if the activation is blocked: perhaps that might happen for good reasons, eg because there are implementation bugs found after activation settings are merged but prior to activation locking in, or perhaps for neutral or bad reasons that cause miners to be opposed. In the event of a huge conflict or emergency as bad as or worse than occurred with segwit, a chain split might well be the lesser evil compared to the activation being blocked or delayed substantially; but as default scenario for every consensus change, before we know if someone might find a problem while there's still time to back out, and before we know if there is going to be a huge conflict? It doesn't seem as focussed on safety as I'd expect from bitcoin. > After a normal and successful Core update with LOT=false, we will have more > data showing broad community support for the taproot upgrade in hand.  In the > next release, 6 months later or so, Core could then confidently deploy a BIP8 > LOT=true client, should it prove to be necessary. BIP8/lot=true is great for the situation we found ourselves in with BIP91/BIP148: there's an activation underway, that is being unexpectedly opposed, we want to ensure it activates, *and* we don't want to have everyone have to do a new round of software upgrades. But if we're able to calmly put out a new release with new activation parameters, with enough time before it takes effect that everyone can reasonably upgrade to it, that's a pretty different situation. First, since we're giving everyone time to upgrade, it can be a clean secondary deployment -- there's no need to try to drag the original lot=false users along -- we're giving everyone time to upgrade, and everyone includes them. Second, lot=true implies we're doing some unsignalled consensus change anyway -- blocks would be considered invalid if they don't signal for activation as of some height, with no prior on-chain signalling that that rule change has occurred. So if we're allowing that, there's no principle that requires signalling to lock in the change we're actually trying to activate. So at that point why not simply reverse the burden of proof entirely? Run an initial "speedy trial" type event that allows fast activation via miner enforcement prior to everyone having upgraded; and if that fails but there haven't been valid reasonable objections to activation identified, run a secondary activation attempt that instead of requiring 90% signalling to activate, requires 90% signalling to *fail*. Miners not upgrading is then not a blocker, and even if a few miners are buggy and signal accidently, that doesn't cause a risk to them of having their blocks dropped, or to the network of having the upgrade blocked. If there are good reasons to object to the fork being activated that are discovered/revealed (very) late, this also provides an opportunity to cleanly cancel the activation by convincing miners that the activation is undesirable and having them agree to signal for cancellation (via BIP-91 style coordination or even BIP-148 style mandatory signalling, eg). And, on the other hand, if 90% of miners are opposed to a soft fork for some selfish or bad reason, with that much hashpower they could easily do a 51% attack on the network after activation to prevent any new features being used, so cancelling activation in that case is probably not worse in practice than it would be continue with it despite the opposition. I think a state machine along the lines of: DEFINED - for 6 months after code release STARTED - exactly 1 period FAILED - if sufficient signalling occurs DELAYED - 6 months LOCKED_IN - exactly 1 period ACTIVE would work fine for an if-at-first-you-don't-succeed approach to deployment along the above lines. That seems to me to have a lot of desirable properties: - a minority of hashpower can't block activation - miners don't have to do anything and don't have to worry about their blocks getting orphaned - devs aren't making any final decisions on consensus changes, even if everyone's committed to running the same codebase (unlike when merging either lot=true or flag day activations) - there's no need to run different clients, or carefully configure your node to stay in consensus - if economic actors want to influence activation by setting up markets, they have a single signalling period to focus on, with 6 months lead time to set everything up and stabilise price discovery, and a fairly definite endpoint and clear result for closing out everyone's positions, whichever outcome occurs - there's no need/encouragement to use the machine vetting your business income as leverage to force/prevent changes to bitcoin consensus; configuring your node to not follow the most work chain is only needed when both devs and miners are getting it wrong, *and* market incentives haven't been enough to correct things The main drawback is that it doesn't allow faster activation with miner support; even with a speedy trial first, it's just a boolean: did miners indicate they've upgraded quickly enough to hit the early activation or not? Cheers, aj