Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3D1FCC0001 for ; Mon, 8 Mar 2021 14:13:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 1C7D047121 for ; Mon, 8 Mar 2021 14:13:49 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=voskuil-org.20150623.gappssmtp.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 HXl4EUP8AsiI for ; Mon, 8 Mar 2021 14:13:46 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) by smtp4.osuosl.org (Postfix) with ESMTPS id EDA9E470A7 for ; Mon, 8 Mar 2021 14:13:45 +0000 (UTC) Received: by mail-pg1-x529.google.com with SMTP id a4so6486678pgc.11 for ; Mon, 08 Mar 2021 06:13:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :thread-index:content-language; bh=yBzfum3HKIUzPOZyQqtuQfxCnQxuXAYnjEaPi0i67+k=; b=odzPjxHH/gr/1X4eNnf2PLDeWY5jHEvCFYYQ1C6QvwfejBm5y+w/MBNPA6YjzCATMS kXT7d5zG9LjytkyIsUlIa9YcgjtW/h+O/dAwhHWpgV0kdNExkU2sUrBRmFGvdkdfZqXN E4XMsy/JBDfvr/0tpdE5sD33eM+/scM0q5pngp3s9Sn0Lxiht5Q9exjIkaiWA7IRIxkd o5+z4IOFLW2ieC1ROcbv4B1yYrXNjww4uQBylTedUCXBTBJaSOrbFWY4bhtcp3zf1uF1 LOguUMHcyQDUQqVqdQ7aJ6GO1iDjxpP1khGpw7xAo+bMYScWG4z4TSmSWnKJUtB4pE1x tLUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=yBzfum3HKIUzPOZyQqtuQfxCnQxuXAYnjEaPi0i67+k=; b=R2EK8yqjiVESblkZ/Hq0Nxof7pG54lV7eL6rAvYRmwcf/WZFIpYqtUzib4m4Tk4avT fKWjY/9GUO/5C8leNQpIgW1w1zvSCpyRFwSzEIOnrv6Szxg9VieBKW5IcoFgbyL4ZMf1 5Ba8Co97GwnSIciIrE7X/ay3+HYLOn10dahwooP9bsuWZfUlzJRXaXMAdJsFSqA43fcJ aGzOMJjmG1jmZCD/itdUM4/jUpQmFqCh9znm+1H7JPAre9QoTIKB3IIjIC+E3HfK8WK6 hwtSJe3Cf24YCw1Q2t7MTIHCPFfi9UUwQv6Zw9m2fj7+AvvGzW4uj968EUXe6bCpzhKQ 5feA== X-Gm-Message-State: AOAM532Wt2ujOQxWKy4iDBBRdy5womj2Qo178flIilYVFsNc/uCV132e 314kkc1lIEsRLh9Z3gbscMyhqA== X-Google-Smtp-Source: ABdhPJyVP6jKIyrGqwjBT+u8SyvDe5M4732XU0pz6koL8KxEQU0dt3bIQDs1e2J1adXcrV1O77ONCQ== X-Received: by 2002:a63:a512:: with SMTP id n18mr20798986pgf.198.1615212825179; Mon, 08 Mar 2021 06:13:45 -0800 (PST) Received: from ERICDESKTOP ([2601:600:9c00:1d0::b000]) by smtp.gmail.com with ESMTPSA id v14sm11692021pju.19.2021.03.08.06.13.44 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Mar 2021 06:13:44 -0800 (PST) From: To: =?UTF-8?Q?'Jorge_Tim=C3=B3n'?= , "'Bitcoin Protocol Discussion'" , "'Anthony Towns'" References: <20210303145902.cl4mzg6l7avjboil@erisian.com.au> <281679eb-860b-c6cb-7e7a-5ae28b60f149@mattcorallo.com> <20210306113326.mrftlkmmloy2dsag@erisian.com.au> In-Reply-To: Date: Mon, 8 Mar 2021 06:13:44 -0800 Message-ID: <011601d71425$40221580$c0664080$@voskuil.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0117_01D713E2.3200F860" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFl55qKIqsoxHhUjfhG81x6LAbnOgLfavyCA3zpG7UBGI8lPgK9NEvOqwrYlKA= Content-Language: en-us Subject: Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation 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, 08 Mar 2021 14:13:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0117_01D713E2.3200F860 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable One should not assume that those trying to avoid a chain split are = against Taproot. =20 There is a concerning widespread misperception in the community at large = that soft forks are inherently =E2=80=9Cbackward compatible=E2=80=9D. To = many people this seems to mean that, even without hash power = enforcement, activation will not create a chain split. This is no doubt = reinforced by loose wording in past proposals, such as the unqualified, = =E2=80=9CAs a soft fork, older software will continue to operate without = modification.=E2=80=9D (BIP141). If operating means not crashing, then = hard forks also qualify. Many people do not understand that hash power = enforcement is also required for a soft fork to avoid a chain split. =20 This misperception has also been fed by devs who should know better = claiming that BIP16 was not signaled by supermajority hash power before = it was activated. The only distinction being that an *automated* = activation method had not yet been developed. Starting with BIP16 *all = active soft forks* have been activated by supermajority hash power = signaling. I was told publicly by someone who should certainly know = better that SegWit missed its BIP9 activation window and that BIP9 = failed. Yet SegWit activated under BIP9 2.5 months before its activation = window closed. It never entered its FAILED state and remains in its = ACTIVE state (BIP90 being presumed to be merely a code optimization). = This type of misinformation is a root cause of much of the conflict. =20 Yes, some people threatened to split themselves off with BIP148, and yes = miners used BIP91 to accelerate SegWit enforcement, preventing that = split well before the SegWit the activation window was set to expire. So = those people claim BIP9 failed. It=E2=80=99s a false narrative. BIP9 = could have failed, but did not. Soft fork activation could be = unsupported by miners, but to date no such activation attempt has = failed. No doubt it will someday. But why are people picking a fight = where there isn=E2=80=99t one. =20 This should not about who gets to =E2=80=9Cdecide the rules=E2=80=9D, = but that is exactly what it has become. It=E2=80=99s the only = explanation for the conflict. Otherwise there does not appear to be any = whatsoever. Miner activation is used if at all possible because it = avoids a chain split. It=E2=80=99s as simple as that. Anyone can of = course decide what rules they run. But telling them that they can do so = without splitting is flatly irresponsible. If it comes to that, inform = people properly and let them decide. =20 The reason for BIP8 is clearly to codify activation without hash power = support. You are right that BIP8(LOT=3Dfalse) is just BIP9. The other = differences are immaterial. Given that there are other differences, it = seems advisable to use what has already been coded, tested, deployed, = and successful in the past. It=E2=80=99s also understandable that many = devs no not want to be responsible for shipping code to large numbers of = people who are misinformed about its behavior, potentially causing a = chain split and loss of both money and faith in the system. =20 If one needs to consider this a question of who gets to decide, = it=E2=80=99s not clear to me why one would side with exchanges over = miners given that the latter are able to prevent a chain split. HODLer = nodes are non-economic, to the extent they even exist. This = isn=E2=80=99t a David vs. Goliath scenario, and even if it was, the = supposed giant appears to overwhelmingly support Taproot. =20 e =20 From: bitcoin-dev On = Behalf Of Jorge Tim=C3=B3n via bitcoin-dev Sent: Monday, March 8, 2021 4:52 AM To: Anthony Towns ; Bitcoin Protocol Discussion = Subject: Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation =20 Concept nack. This has no advantage over bip8(true). Bip9(false) is just bip9. Thr only reasonable argument against bip8(true) is "some people may do = bip8(false) instead", which is a stypid argument applyable to any = activation method. =20 People against taproot should want code to forbid its activation rather = than limiting themselves to suport bip9/bip8(false) and hope it doesn't = get activated it. =20 Some other arguments seem to be based on the wrong assumption that = miners should decide the rules. =20 Thisproposal solves nothing, just adds to the noise and thus is really = disappointing. =20 ------=_NextPart_000_0117_01D713E2.3200F860 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

One should not assume that = those trying to avoid a chain split are against = Taproot.

 

There is a concerning widespread misperception in the = community at large that soft forks are inherently =E2=80=9Cbackward = compatible=E2=80=9D. To many people this seems to mean that, even = without hash power enforcement, activation will not create a chain = split. This is no doubt reinforced by loose wording in past proposals, = such as the unqualified, =E2=80=9CAs a soft fork, older software will = continue to operate without modification.=E2=80=9D (BIP141). If = operating means not crashing, then hard forks also qualify. Many people = do not understand that hash power enforcement is also required for a = soft fork to avoid a chain split.

 

This = misperception has also been fed by devs who should know better claiming = that BIP16 was not signaled by supermajority hash power before it was = activated. The only distinction being that an *automated* = activation method had not yet been developed. Starting with BIP16 = *all active soft forks* have been activated by supermajority hash = power signaling. I was told publicly by someone who should certainly = know better that SegWit missed its BIP9 activation window and that BIP9 = failed. Yet SegWit activated under BIP9 2.5 months before its activation = window closed. It never entered its FAILED state and remains in its = ACTIVE state (BIP90 being presumed to be merely a code optimization). = This type of misinformation is a root cause of much of the = conflict.

 

Yes, some people threatened to split themselves off = with BIP148, and yes miners used BIP91 to accelerate SegWit enforcement, = preventing that split well before the SegWit the activation window was = set to expire. So those people claim BIP9 failed. It=E2=80=99s a false = narrative. BIP9 could have failed, but did not. Soft fork activation = could be unsupported by miners, but to date no such activation attempt = has failed. No doubt it will someday. But why are people picking a fight = where there isn=E2=80=99t one.

 

This should = not about who gets to =E2=80=9Cdecide the rules=E2=80=9D, but that is = exactly what it has become. It=E2=80=99s the only explanation for the = conflict. Otherwise there does not appear to be any whatsoever. Miner = activation is used if at all possible because it avoids a chain split. = It=E2=80=99s as simple as that. Anyone can of course decide what rules = they run. But telling them that they can do so without splitting is = flatly irresponsible. If it comes to that, inform people properly and = let them decide.

 

The reason = for BIP8 is clearly to codify activation without hash power support. You = are right that BIP8(LOT=3Dfalse) is just BIP9. The other differences are = immaterial. Given that there are other differences, it seems advisable = to use what has already been coded, tested, deployed, and successful in = the past. It=E2=80=99s also understandable that many devs no not want to = be responsible for shipping code to large numbers of people who are = misinformed about its behavior, potentially causing a chain split and = loss of both money and faith in the system.

 

If one needs = to consider this a question of who gets to decide, it=E2=80=99s not = clear to me why one would side with exchanges over miners given that the = latter are able to prevent a chain split. HODLer nodes are non-economic, = to the extent they even exist. This isn=E2=80=99t a David vs. Goliath = scenario, and even if it was, the supposed giant appears to = overwhelmingly support Taproot.

 

e

 

From: bitcoin-dev = <bitcoin-dev-bounces@lists.linuxfoundation.org> On Behalf Of = Jorge Tim=C3=B3n via bitcoin-dev
Sent: Monday, March 8, = 2021 4:52 AM
To: Anthony Towns <aj@erisian.com.au>; = Bitcoin Protocol Discussion = <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: = [bitcoin-dev] Straight Flag Day (Height) Taproot = Activation

 

Concept = nack.

This has no advantage over = bip8(true).

Bip9(false) is = just bip9.

Thr only = reasonable argument against bip8(true) is "some people may do = bip8(false) instead", which is a stypid argument applyable to any = activation method.

 

People against taproot should want code to forbid its = activation rather than limiting themselves to suport bip9/bip8(false) = and hope it doesn't get activated it.

 

Some other arguments seem to be based on the wrong = assumption that miners should decide the = rules.

 

Thisproposal solves nothing, just adds to the noise = and thus is really disappointing.

 

------=_NextPart_000_0117_01D713E2.3200F860--