From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9CDD9C0001 for ; Fri, 19 Feb 2021 23:30:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 99EBC606E5 for ; Fri, 19 Feb 2021 23:30:56 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0wrUH_7g1rL for ; Fri, 19 Feb 2021 23:30:52 +0000 (UTC) Received: by smtp3.osuosl.org (Postfix, from userid 1001) id A519B60701; Fri, 19 Feb 2021 23:30:52 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from mail.as397444.net (mail.as397444.net [69.59.18.99]) by smtp3.osuosl.org (Postfix) with UTF8SMTPS id 4F434606E3 for ; Fri, 19 Feb 2021 23:30:50 +0000 (UTC) Received: by mail.as397444.net (Postfix) with UTF8SMTPSA id E7D694A79EC for ; Fri, 19 Feb 2021 23:30:47 +0000 (UTC) X-DKIM-Note: Keys used to sign are likely public at https://as397444.net/dkim/ DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattcorallo.com; s=1613775664; t=1613777447; bh=DC//mRUixMj/rrOQ01gb2yBBrE0jom38pu65cqaBa5g=; h=Date:Subject:To:References:From:In-Reply-To:From; b=rUOpuHrs9jLWCGXkH3kOcPoYyb9KV6UaMMexNteeTrHIaD6UDcYUdRYWZQIEQTE3U YO/eHPaNE/DRuJtguRVvoKKKsmtUn9feAWj3b9+KpAdzyu7wXsae4yBc50rJwm69hD T4MLdZdk0LXyud7EmRrhqPs7H0O+zmVVKFZPrVlaEIPrz1y6oJQMFM69gztusf3o8z XgOkBEmgxWqru0iFma/fONnT8WSRzROEq9EwY1lVbpgRAvccUn6kHI73GicTxpPi8S ZdWrnb4KVlW2FG+hYm7G+LXnjOz5fxg6My4SGDqRzYFhtyteM8Z2pXLkxgYcp1Bpjp 8qBSyYocra1fg== Message-ID: Date: Fri, 19 Feb 2021 18:30:47 -0500 MIME-Version: 1.0 Content-Language: en-US To: Matt Hill via bitcoin-dev References: From: Matt Corallo In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 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: Fri, 19 Feb 2021 23:30:56 -0000 (off-list) Your email client didn't thread correctly, so I'm not sure if you saw my responses to Adam's email, but note that there is no such thing as "All that must be done" here - supporting multiple, different, consensus rules for a given chain is a nontrivial undertaking in Bitcoin Core from a software perspective. The only practical way is to, just treat it as a different chain, which, in practice, it could be. One group running LOT=true and one running LOT=false results in two Bitcoins, and the software would need to be able to handle that (and, presumably, allow users to switch between chains). Matt On 2/19/21 17:12, Matt Hill via bitcoin-dev wrote: > Good day all, this is my first post to this mailing list. Per Adam's comment below: > > > given there are clearly people of both views, or for now don't care > but might later, it would minimally be friendly and useful if > bitcoin-core has a LOT=true option - and that IMO goes some way to > avoid the assumptive control via defaults. > > Both here and elsewhere, the debate taking place is around the manner of Taproot activation, not whether or not Taproot > should be activated. The latter seems to have widespread support. Given this favorable environment, it seems to me this > is an incredible opportunity for the developer contingency to "take the high road" while also minimizing time to Taproot > activation using political incentives. By offering power on the left hand to miners and and power on the right to users, > neither of whom is expressing disapproval of activation, but both of whom are able to activate without the consent of > the other, both are incentivized to signal activation as quickly as possible to emerge as the "group that did it". All > that must be done is to include a LOT=true option to Bitcoin Core that carries a default of LOT=false. Miners can > activate at any time, users can signal their intent to activate should miners renege, and developers emerge as > politically neutral in the eyes of both. > > Extrapolating a bit, I contend this expanded agency of full node operatorship may result in more users running a full > node, which is good and healthy. From a miner's point of view, more full nodes only increases the likelihood of future > UASFs, and so they are even further incentivized to expedite Taproot activation. Perhaps this is a stretch, perhaps not. > > To summarize: (1) this positions developers as neutral facilitators who deferred power to the other contingencies; (2) > we may see a rise in the popularity of running a full node and the number of full node operators; (3) miners are > incentivized to activate quickly to avoid being perceived as the "bad guys" and to avoid the spread of full nodes; and > (4) even if miners do not activate, users can organize a UASF in a grass-roots way. > > Matt Hill > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >