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 F348EC0001 for ; Sun, 28 Feb 2021 19:45:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id D60F86061D for ; Sun, 28 Feb 2021 19:45:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 0.25 X-Spam-Level: X-Spam-Status: No, score=0.25 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=dashjr.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 bjfNIYFjJyAm for ; Sun, 28 Feb 2021 19:45:31 +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 smtp3.osuosl.org (Postfix) with ESMTP id E46C660612 for ; Sun, 28 Feb 2021 19:45:30 +0000 (UTC) Received: from ishibashi.lan (unknown [12.190.236.214]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id A1F9338A00A5; Sun, 28 Feb 2021 19:45:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dashjr.org; s=zinan; t=1614541530; bh=ilgJpRlhp46jc/fmT/JrEEnHRYbdWvIV/uYSYe7+jLA=; h=From:To:Subject:Date:Cc:References:In-Reply-To; b=ONx7KMfAdDIcUZqvtgdCX39uk0xWexfkpojSj45FsaQE5KAWHZ/+qBefeG4kw502w swMa4MhFSdgM8pzTNDRgJcNIKKl9nqRXXsdLpwPI5rtEcIVo5zWKfso6Jg/OHnGwL5 boA4Ek5ge7GpfDgwF/2FcZc1Xhs7bjLdCYAp7kxo= From: Luke Dashjr To: bitcoin-dev@lists.linuxfoundation.org, "David A. Harding" Date: Sun, 28 Feb 2021 19:45:23 +0000 User-Agent: KMail/1.9.10 References: <20210213163257.uvn4apdy4znr7p2t@ganymede> In-Reply-To: <20210213163257.uvn4apdy4znr7p2t@ganymede> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <202102281945.24039.luke@dashjr.org> Cc: Michael Folkson Subject: Re: [bitcoin-dev] Taproot activation meeting 2 - Tuesday 16th February 19:00 UTC 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: Sun, 28 Feb 2021 19:45:32 -0000 Answering the F1-F7 arguments for LOT=3DFalse... > F1) The probability of Taproot not being activated by miners is small. Th= is > is not 2017, this is not SegWit, there is no need to worry. While we believe miners have no reason to sabotage Taproot activation, this= =20 was also the belief leading up to Segwit=E2=80=99s activation in 2017, and = regardless=20 it is not desirable to create such a risk forcing the community to place=20 extra trust in miners. Miners might very well not exploit an inflation bug,= =20 but that is no reason to purposefully add an inflation bug. > F2) The worst case scenario is we have to wait over a year for Taproot to > be activated. Even the worst case scenario is not a disaster. While it is true that a second activation can be deployed in the event of t= he=20 first one failing, doing so would not necessarily change the situation unle= ss=20 LOT were changed to true anyway - in which case, it might as well be true f= or=20 the initial deployment as well. Furthermore, a re-deployment could create a= =20 situation where users believe they have already upgraded for Taproot, but d= o=20 not enforce it due to not understanding the need to upgrade yet again. > F3) If in the unlikely scenario miners did not activate Taproot for a year > for no apparent reason we would never set LOT to false again for any > potential future soft fork. If miners fail to activate Taproot despite > pledging support and there being overwhelming community consensus for it, > it would set a precedent that miners cannot be relied upon *at all* to > activate soft forks. Setting LOT=3Dfalse with a threat to change it to true later is antagonisti= c=20 against miners. With LOT=3Dtrue, expectations are simply made clear and min= ers=20 can simply cooperate by making valid blocks as they do day-to-day already. > F4) If in the highly unlikely scenario that a bug or some problem with the > Taproot implementation was found during the signaling period miners could > choose not to activate it which is cleaner than needing an emergency Core > release. The risk that a bug in Taproot is discovered this late yet before activatio= n,=20 to warrant aborting the deployment, is extremely low (much lower than the=20 risks created by LOT=3Dfalse). Even if such a scenario occurred, and even w= ith=20 LOT=3Dfalse, users would still need to upgrade to back out the deployment. = In=20 the best-case scenario, users would need to upgrade to deploy the fixed=20 Taproot. So in the end, nothing is to be gained from relying on a miner abo= rt=20 for such scenarios. > F5) LOT =3D false is more similar to what was done previously (unless you= go > way back to the earliest soft forks which were more similar to LOT =3D tr= ue) The behaviour of LOT=3Dfalse has proven problematic and caused failure of S= egwit=20 activation in 2017. LOT=3Dtrue behaviour has a long history of success, and= was=20 used to resolve and activate Segwit in 2017 after LOT=3Dfalse=E2=80=99s fai= lure. > F6) It is more important that no rules that harm users are deployed than = it > is that new useful rules are deployed quickly. If there is a choice betwe= en > =E2=80=9Cfaster=E2=80=9D and =E2=80=9Cmore clear that this isn=E2=80=99t = a mechanism to force bad things on > users=E2=80=9D we should prefer the latter. Plenty of people just don=E2= =80=99t like > LOT=3Dtrue very much absent evidence that miners are blocking deployment.= To > some it just feels needlessly antagonistic and distrusting towards part of > our community. Any deployment, or even status quo, can be falsely portrayed/spun in a way = to=20 harm Bitcoin. As such, only objective criteria should be considered. BIP 8 makes it explicitly easy for people to reject the softfork if they do= n't=20 like it, so any claim of being "forced" is a non-starter to an honest perso= n. > F7) defaulting to LOT=3Dfalse makes non-activation possible even if people > run the code that developers provide, meaning a successful > activation proves that at least some people (e.g. miners or UASFers) > voluntarily took actions that were well outside the scope of > developer control. > > This makes it clear that developers don't control changes to the > system. There are other arguments that demonstrate that developers > aren't in control[1], but they aren't as clear as simply pointing > out that a rule change won't go into effect until at least several > non-developers independently act of their own accord. > > Having such a clear argument that developers aren't in control > bolsters the decentralized ethos of Bitcoin and reduces the chance > that bad actors will pressure Bitcoin developers to attempt future > unwanted changes. Even if developers release software, it must still be accepted by the=20 community in the form of actively choosing to run the software which includ= es=20 the activation. So long as the activation is clearly and prominently=20 documented, users have taken the action to accept the protocol change.=20 =46urthermore, the community has already demonstrated a clear and undispute= d=20 support for the activation of Taproot. If there was/is any question of=20 whether that is true or not, it is premature to be planning activation of A= NY=20 type. Luke