From: <eric@voskuil•org>
To: "'Jorge Timón'" <jtimon@jtimon•cc>,
"'Bitcoin Protocol Discussion'"
<bitcoin-dev@lists•linuxfoundation.org>,
"'Anthony Towns'" <aj@erisian•com.au>
Subject: Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation
Date: Mon, 8 Mar 2021 06:13:44 -0800 [thread overview]
Message-ID: <011601d71425$40221580$c0664080$@voskuil.org> (raw)
In-Reply-To: <CABm2gDpky7W-e_Vp5bFZ-k+y40-wFsNZ_-Cj-JNxi7PjTB2nxQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4395 bytes --]
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 “backward compatible”. 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, “As a soft fork, older software will continue to operate without modification.” (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’s 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’t one.
This should not about who gets to “decide the rules”, but that is exactly what it has become. It’s 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’s 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=false) 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’s 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’s 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’t 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ón 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.
[-- Attachment #2: Type: text/html, Size: 6986 bytes --]
prev parent reply other threads:[~2021-03-08 14:13 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-28 16:45 Matt Corallo
2021-02-28 17:20 ` Luke Dashjr
2021-02-28 17:29 ` Matt Corallo
2021-02-28 19:43 ` Jeremy
2021-02-28 19:51 ` Matt Corallo
2021-02-28 20:02 ` Jeremy
2021-02-28 20:19 ` Eric Voskuil
2021-02-28 20:25 ` Matt Corallo
2021-02-28 20:38 ` Eric Voskuil
2021-02-28 20:20 ` Matt Corallo
2021-03-03 14:59 ` Anthony Towns
2021-03-03 16:49 ` Matt Corallo
2021-03-06 11:33 ` Anthony Towns
2021-03-08 12:51 ` Jorge Timón
2021-03-08 14:13 ` eric [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='011601d71425$40221580$c0664080$@voskuil.org' \
--to=eric@voskuil$(echo .)org \
--cc=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jtimon@jtimon$(echo .)cc \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox