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 8D981C002F for ; Wed, 19 Jan 2022 12:02:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 7C0D041527 for ; Wed, 19 Jan 2022 12:02:23 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=protonmail.com 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 P1SX5mNp3_i3 for ; Wed, 19 Jan 2022 12:02:22 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22]) by smtp4.osuosl.org (Postfix) with ESMTPS id 688D8408D4 for ; Wed, 19 Jan 2022 12:02:22 +0000 (UTC) Date: Wed, 19 Jan 2022 12:02:18 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail2; t=1642593739; bh=pt1tbsoM3mja/WHBqYDpGBpmmSKCrB906jq5ROmUyQw=; h=Date:To:From:Reply-To:Subject:Message-ID:In-Reply-To:References: From:To:Cc; b=wy6TH4itMAOsH0UMNqlu0A1SnHIrjTdNVTq9+pJQgIMzuvcajViFeBYJsb6okFw67 2fi3cnrhEcBZ0F2N5iywXFAUFHQ59+nHWimtzmhH2R7FD1fIcwR/pwnfx7mNQUtHf2 fRtuPqKfZLk406V/FoxzMsFsGNqvhGqKo3d5sKjYgfVzo7lPSEV1Mv0X+ipBCyL15H cRkeuqXdCQmese4ap7G1Z25d3thpygv9azyAJ3o3u1sHLxlI7WTHUxx7uxqATN5Bjh 184G1M9er17upc+v8HkKdQicrHPW+1YMTXKeNTLB5orZRCzJBFL2HZo83GbJfNtHLd 5fcmlsi/bLmtQ== To: eric@voskuil.org, Bitcoin Protocol Discussion From: Michael Folkson Reply-To: Michael Folkson Message-ID: In-Reply-To: <000601d80cbf$2f6a1d80$8e3e5880$@voskuil.org> References: <202201182119.02687.luke@dashjr.org> <02cc01d80cb7$1339c050$39ad40f0$@voskuil.org> <202201182209.46044.luke@dashjr.org> <000601d80cbf$2f6a1d80$8e3e5880$@voskuil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 19 Jan 2022 12:36:49 +0000 Subject: Re: [bitcoin-dev] CTV BIP review 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, 19 Jan 2022 12:02:23 -0000 Eric, Luke Can I request that you don't discuss activation methods for future soft for= ks on a thread for CTV BIP review? I (and a number of others [0]) do not su= pport an upcoming activation attempt of standalone OP_CTV. If you want to d= iscuss activation methods for soft forks generally it would be much better = if you set up a separate thread. OP_CTV is not the only current soft fork p= roposal and there will likely be more. The activation discussion for Taproot was deliberately kept separate from t= he review of the Taproot BIPs and implementation. It only commenced once th= ere was overwhelming community consensus for the soft fork to be activated = (months after in fact). Though you are free to discuss whatever topics you = wish (obviously) discussing soft fork activation methods on a OP_CTV thread= might give the mistaken impression that OP_CTV is the next soft fork to be= activated which is mere speculation at this point. In an ideal world the p= romoters of OP_CTV would follow the strong precedent set by the authors and= contributors to the Taproot BIPs but regrettably that seems to have gone o= ut the window at this point. Thanks Michael [0]: https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b71= 8 -- Michael Folkson Email: michaelfolkson at protonmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Tuesday, January 18th, 2022 at 11:00 PM, Eric Voskuil via bitcoin-dev wrote: > -----Original Message----- > > From: Luke Dashjr luke@dashjr.org > > Sent: Tuesday, January 18, 2022 2:10 PM > > To: eric@voskuil.org > > Cc: 'Bitcoin Protocol Discussion' bitcoin-dev@lists.linuxfoundation.org > > Subject: Re: [bitcoin-dev] CTV BIP review > > On Tuesday 18 January 2022 22:02:24 eric@voskuil.org wrote: > > > The only material distinction between BIP9 and BIP8 is that the latter > > > > may activate without signaled support of hash power enforcement. > > > > As unenforced soft forks are not "backward compatible" they produce a > > > > chain split. > > Enforcement of the Bitcoin consensus protocol is by users, not miners. Given that I stated "hash power enforcement" it is quite clear that this is in fact only produced by mining. You are misrepresenting my statement to make an emotional appeal. Without "hash power enforcement", a soft fork is NOT backward compatible. "[enforcement of] consensus protocol" is of course by merchants, but that i= s not the question at hand. The question is explicitly compatibility. Anyone can activate a soft fork at any time, but without "hash power enforcement" soft forks are NOT backward compatible. > Softforks never produce a chain split. Miners can, and might try to do it to cause disruption in retaliation, but the softfork itself does not. Maybe you are trying to split hairs given the fact that blocks are produced only by miners, so only miners can "cause" a split. But through not intention ("disruption in retaliation") whatsoever by mining, a soft fork will result in those activating the rule being split of= f the original chain unless majority hash power enforces the rule. The fact that doing nothing apart from deploying the rule will result in a split is the very definition of NOT compatible. I assume you will argue that the original chain is not "valid" and therefor= e irrelevant (as if no chain split occurred). But again the point is about compatibility. The appearance of multiple chains, which appear valid according to either the previous or new rules, is obviously the incompatibility. I shouldn't have to point this out, but observed chain splits have occurred in more the one large scale soft fork deployment. These splits have only been resolved through hash power enforcement. In 2010 it took 51 blocks before the current chain took the lead. In 2012 minority chains persisted for months. The deployment of soft forks caused these splits, NOT the actions of miners. And unless majority hash power eventually enforces it, the soft fork branch necessarily dies. > > It was for this reason alone that BIP8 never gained sufficient > > > > support. > > BIP 8 in fact achieved consensus for Taproot activation. Please define "achieved consensus", because by any definition I can imagine= , this is simply untrue. > > This is one of the most misleading statements I've seen here. It's not > > > > technically a lie, because it states what "should" happen. But it is > > > > clearly intended to lead people to believe that BIP8 was actually used > > > > ("again") - it was not. ST was some technical tweaks to BIP9. > > BIP 8 was used to activate Taproot. No, it wasn't. I find it hard to imaging how you rationalize such grossly misleading statements. > > The outright deception around this one topic has led to significant > > > > unnecessary conflict in the community. Make your argument, but make it > > > > honestly. > > You are the one attempting to deceive here. That is for others to decide. I appreciate your responses above, since they certainly help clarify what is happening here. e bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev