Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id CFF09C0001 for ; Thu, 4 Mar 2021 11:02:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id AED7E83148 for ; Thu, 4 Mar 2021 11:02:37 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 0.602 X-Spam-Level: X-Spam-Status: No, score=0.602 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbxhC65bg5FY for ; Thu, 4 Mar 2021 11:02:36 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) by smtp1.osuosl.org (Postfix) with ESMTPS id 652418434B for ; Thu, 4 Mar 2021 11:02:36 +0000 (UTC) Received: by mail-oi1-x22f.google.com with SMTP id w65so6071170oie.7 for ; Thu, 04 Mar 2021 03:02:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vFyqlq6rgHBkPiII9UTC7+36sfDPV8/cxC7MzrUdqz0=; b=h4+28kx8uIP+d+webIL//ncZNlIDt4x0FRBWtFlxnFh2ErUEYEr47FuD1SMkntixgZ nYWrWQxWHuyJik9H4Yzr0bM5iUmQbpmtGDZaq9jLuTcVOpVAIqUm8UOn1Sp55vT91rqY sFc/aPxg/6t5oRIBGB2rYWiu+1UqKCLOWHFnk5mZ5kCNuRXCyLDysDTbQhk1lxSFHlr8 dQ5GQwRRL/uTkM7yqhcz22fMz9yxzhb3S3f2yHj8GRD1MfMNUClIhLHSjoDKi0Xtk+MJ mQpeXvZ+EsWoVuS/u8hL/JfApqIx+5pZGHyCrBb6yszLcwVZbQnyIkODf+rfFHfPA/3R ffGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vFyqlq6rgHBkPiII9UTC7+36sfDPV8/cxC7MzrUdqz0=; b=TCtOO0LJVJp5xxztGH8TyFzLgQosxUu/EXQLKIQSnkQ27nVBD+Au8jG85Rfxd++MxB ZpVRpo4ssYbIrE0+J5mdCOF2iVc/XOz8YYzvsrloudmqVAuHcAZyAaOhLPCRE8CwQL4j j1aDiWLxsldFgA7uNrr6KxT3A3k+moCDKNCdPreIgPkaQrzgd/rJS0tg7CLOqpy+1kJH wEk3RabSvAaACqGjCp0qtlaCfWKpTqbmJU4FOxWu88l6Qq4npTb2IU4s3W87i0GuNEe/ D+nsoj8cuqeP196HpwNOmSpgliqsY0KF8dwLAbiil+a3GaiyqevkN8ALY8YIvWRghDJP F1Zw== X-Gm-Message-State: AOAM532S1WzzrCN1h4WTLiuYEie23mhOUvhJx/04z8W93b6jHf3RzV9l 9G7bSm5YF0Sih++PYk3B16vyh9X/ezksGI+qyGjYiZNoTKJ3rg== X-Google-Smtp-Source: ABdhPJxuM+mW6uBJvLME+I0nBcfLz6BLlUiOiDcl8qX3G1Oma2ohpcMqRHR0siiydeZJWzkx0c1QagQX8HbK8Et1UIc= X-Received: by 2002:aca:aa96:: with SMTP id t144mr2596867oie.131.1614855270060; Thu, 04 Mar 2021 02:54:30 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Michael Folkson Date: Thu, 4 Mar 2021 10:54:19 +0000 Message-ID: To: Ariel Luaces Content-Type: multipart/alternative; boundary="000000000000bc559205bcb3ca43" X-Mailman-Approved-At: Thu, 04 Mar 2021 11:23:13 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] =?utf-8?b?WWVzdGVyZGF54oCZcyBVQVNGIChMT1Q9dHJ1ZSkg?= =?utf-8?q?kick_off_meeting?= 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: Thu, 04 Mar 2021 11:02:38 -0000 --000000000000bc559205bcb3ca43 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ariel > I think Bitcoin is fine staying as is until that minority forks off with their own alt-node.... A quick UASF fork allows for an early LOT=3Dfalse activation. I think you misunderstand BIP 8 (LOT=3Dtrue). Although no timetable has bee= n finalized as of yet (and hence we are in the realm of speculation rather than facts), the earliest the MUST_SIGNAL period would kick in is around July 2022. That doesn't sound very quick to me if you seek a LOT=3Dfalse release after a LOT=3Dtrue release has failed to activate. > The current risk to taproot and all future activations is a loud minority of users who are threatening to co-opt a LOT=3Dfalse activation by switchin= g the parameter As I've said in previous emails to this list, some people are determined to ignore the discussion and (open to all) meetings of recent weeks and block progress until they find their philosopher's stone. They seek to ignore all the work people have done laying out the options, communicating those options to the community and narrowing them down. Instead they bring up alternative proposals which were discussed and rejected weeks or months ago. With this mindset we'll still be arguing about Taproot activation in 2030. I get that there isn't overwhelming consensus on the LOT parameter, this is a fact. But there won't be overwhelming consensus on any activation mechanism, that has become clear. I am of the view that consensus on one parameter of an activation mechanism does not need to be as high as it is on the actual soft fork that is being activated (which does have overwhelming consensus). And of course if and when a LOT=3Dtrue (UASF) version is released you are absolutely free not to run it. I hope (and suspect) you would reconsider if July 2022 (or later) was approaching and it was the only way to activate Taproot. Thanks Michael On Thu, Mar 4, 2021 at 2:18 AM Ariel Luaces wrote: > On Wed, Mar 3, 2021 at 12:25 PM Michael Folkson via bitcoin-dev > wrote: > > > > At this point in time it also appears the greatest risk to Taproot > > dying a slow death is a small group of developers who think talking in > > conservative tones and talking about endless philosophy makes Bitcoin > > a conservative system. (It doesn=E2=80=99t, it just makes it a dying, d= ecaying > > one). > > The current risk to taproot and all future activations is a loud > minority of users who are threatening to co-opt a LOT=3Dfalse activation > by switching the parameter and organizing a marketing blitz that could > end in a fork if things don't go well. > As long as that threat persists consensus won't be reached. Then an > activation client probably won't be released because I don't expect > many devs will have an appetite for writing code that either doesn't > have consensus or code that will be manipulated into creating > consensus conflicts. > I think Bitcoin is fine staying as is until that minority forks off > with their own alt-node. If the UASF minority is dead set on creating > the alt-node then I only hope it's released quickly so the deadlock > can break. A quick UASF fork allows for an early LOT=3Dfalse activation. > > Cheers > Ariel Lorenzo-Luaces > > > -- > > Michael Folkson > > Email: michaelfolkson@gmail.com > > Keybase: michaelfolkson > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --=20 Michael Folkson Email: michaelfolkson@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --000000000000bc559205bcb3ca43 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ariel

> I think Bitcoin is fine staying as is= until that minority forks off with their own alt-node....=C2=A0 A quick UA= SF fork allows for an early LOT=3Dfalse activation.

I think you misu= nderstand BIP 8 (LOT=3Dtrue). Although no timetable has been finalized as o= f yet (and hence we are in the realm of speculation rather than facts), the= earliest the MUST_SIGNAL period would kick in is around July 2022. That do= esn't sound very quick to me if you seek a LOT=3Dfalse release after a = LOT=3Dtrue release has failed to activate.

> The current risk to = taproot and all future activations is a loud minority of users who are thre= atening to co-opt a LOT=3Dfalse activation by switching the parameter
<= br>
As I've said in previous emails to this list, some people= are determined to ignore the discussion and (open to all) meetings of rece= nt weeks and block progress until they find their philosopher's stone. = They seek to ignore all the work people have done laying out the options, c= ommunicating those options to the community and narrowing them down. Instea= d they bring=C2=A0up alternative proposals which were discussed and rejecte= d weeks or months ago. With this mindset we'll still be arguing about T= aproot activation in 2030.=C2=A0

I get that there = isn't overwhelming consensus on the LOT parameter, this is a fact. But = there won't be overwhelming consensus on any activation mechanism, that= has become clear. I am of the view that consensus on one parameter of an a= ctivation mechanism does not need to be as high as it is on the actual soft= fork that is being activated (which does have overwhelming consensus). And= of course if and when a LOT=3Dtrue (UASF) version is released you are abso= lutely free not to run it. I hope (and suspect) you would reconsider if Jul= y 2022 (or later) was approaching and it was the only way to activate Tapro= ot.

Thanks
Michael

<= div>



On Thu, Mar 4, 2021 at 2:18 AM Ariel Luaces <arielluaces@gmail.com> wrote:
On Wed, Mar 3, 202= 1 at 12:25 PM Michael Folkson via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> At this point in time it also appears the greatest risk to Taproot
> dying a slow death is a small group of developers who think talking in=
> conservative tones and talking about endless philosophy makes Bitcoin<= br> > a conservative system. (It doesn=E2=80=99t, it just makes it a dying, = decaying
> one).

The current risk to taproot and all future activations is a loud
minority of users who are threatening to co-opt a LOT=3Dfalse activation by switching the parameter and organizing a marketing blitz that could
end in a fork if things don't go well.
As long as that threat persists consensus won't be reached. Then an
activation client probably won't be released because I don't expect=
many devs will have an appetite for writing code that either doesn't have consensus or code that will be manipulated into creating
consensus conflicts.
I think Bitcoin is fine staying as is until that minority forks off
with their own alt-node. If the UASF minority is dead set on creating
the alt-node then I only hope it's released quickly so the deadlock
can break. A quick UASF fork allows for an early LOT=3Dfalse activation.
Cheers
Ariel Lorenzo-Luaces

> --
> Michael Folkson
> Email: m= ichaelfolkson@gmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev


--
Michael= Folkson
Keybase: michaelfolkson
=
PGP: 43E= D C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
--000000000000bc559205bcb3ca43--