path: root/02/efa339a476c4efa540ebbdb8b9c8d70a15700e

Return-Path: <fresheneesz@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 04C05C002F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Jan 2022 02:26:31 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id E5E0660E3A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Jan 2022 02:26:30 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 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,
 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: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
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 kXR9vMO0I3xC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Jan 2022 02:26:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com
 [IPv6:2a00:1450:4864:20::52d])
 by smtp3.osuosl.org (Postfix) with ESMTPS id D24B8607FF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Jan 2022 02:26:29 +0000 (UTC)
Received: by mail-ed1-x52d.google.com with SMTP id u21so4114384edd.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Jan 2022 18:26:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=GYlhF1WheSv1ptgysyDEFoPV54nwC+LaS0J6puLNsNc=;
 b=UIeurO46patvqw7QSU0bc+ifZN9xtde8nZqzW7utJoZlGytnQhpBpm3ofMKto+zOu6
 KOqSIsKbiWZs3YrBekW1fgzFqFOTLZj7fD9PcXF4rE6MzmFRS5TqJprZZ7KAilqvngmh
 iIRYYowhE+NSGXkY6sblQcXVErbmsWjjykG8zbbNSzDznNk+itc7gqOk4OkzAujrPpep
 PnKP+BNt4ZMSXNGeKYA8xjBX+kMUCJbJN8qkRnXiI0BiER3g/MrbrnCTrZDXWacOvJWf
 bMQiqdN2bpS3EjSJrPnY7Gl6Y6VKJZ6yKo4uFzStSc4mus+Sp50z24KqGYRIUARRtRfj
 7jMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=GYlhF1WheSv1ptgysyDEFoPV54nwC+LaS0J6puLNsNc=;
 b=pSt82j3QfQCwQa5Jn9J/hVoa7s8AQm+J7W9EwHLuS6SVOUt4jyYTpgVCV4tmDFhsQt
 orOwRvycxpXCX6eYi0McfLt/OzsIsteQdpKbCiFzsGr9mTGWZJq59SC2tvMTmJH5sJix
 JZNVeH8O3HS0ZOv/A7YFUD8GUG7Js2rbgFs5sB/uxT4zUr3erI4UMQoTxYI4OWAtPfK1
 y0Yo1+e+pIO6Neaf0weEJvtspfxN0ZzgsT1di13tAOKTBAzjUsudA2sAX0OcC1p2O+WF
 xCbikqWXSQd6l6goKZe203MtauFi0dhyQtPwUX1JFLC5nNyrYJnFAgXsosaTjeGYOwKf
 9HmQ==
X-Gm-Message-State: AOAM532cNZcZQCCwUb8Kh3TAygIwiJx+odgzPYDsOkvEw55RK/kIBtqm
 Ve+hSbnQTIUAuAm+bqjdyMqb7J6RzIU7ypOfeLk=
X-Google-Smtp-Source: ABdhPJzxdY7KvNQEA9TWKx3r2BtUiuuX9CTKS+HmnnkYStiRBmVrrQPgzGSuejqoMofwjFdDN0YLyn8aXT88IqNPMxA=
X-Received: by 2002:aa7:db41:: with SMTP id n1mr28187436edt.307.1642559188035; 
 Tue, 18 Jan 2022 18:26:28 -0800 (PST)
MIME-Version: 1.0
References: <MtiCR2x--7-2@tutanota.de>
In-Reply-To: <MtiCR2x--7-2@tutanota.de>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Tue, 18 Jan 2022 20:26:12 -0600
Message-ID: <CAGpPWDYzVyjfKNL4thxCwAcZgfpdrjRcffu=HL4aUL9b4pG+PA@mail.gmail.com>
To: Prayank <prayank@tutanota.de>
Content-Type: multipart/alternative; boundary="000000000000eced1705d5e61c0a"
X-Mailman-Approved-At: Wed, 19 Jan 2022 09:11:26 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] On the regularity of soft forks
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Jan 2022 02:26:31 -0000

--000000000000eced1705d5e61c0a
Content-Type: text/plain; charset="UTF-8"

>  That day is nowhere near IMO and maybe we won't see it in my lifetime.

I think there is a reasonable argument to be made that maybe bitcoin needs
to move faster now than it should in the future, and the cost of having the
community remain vigilant against harmful changes is worth the extra speed.
The question then becomes, does doing soft forks more often make things go
faster? Its not clear to me that the answer is yes.

> This is not possible in a decentralized network like Bitcoin and makes no
sense.

Why do you think that its not possible? I completely disagree. The bitcoin
community has already come up with cultural norms like this, like the idea
of doing soft forks instead of hardforks wherever possible. Its impossible
to prevent others from doing otherwise, but its completely possible and
desirable for the bitcoin community to adopt standards that we attempt to
adhere to.

> More changes bundled require more review and still more probability to
have bugs.

I already addressed this in my previous email. Why do you think there is
more to review in a soft fork with two bundled changes than in two separate
concurrent soft-fork activations using BIP8 or BIP9? Both require both
changes to be in the software and both require testing to ensure that the
changes interact appropriately. The difference is that in the second case,
you have to test all combinations of which order the proposals activate in.

And let's consider the easiest case of change A, then soft fork 1, then
change B, and soft fork 2. Change A needs to be tested all on its own, and
change B when it comes along also then needs to be tested on code that
already has change A. If the changes are bundled, the same procedure needs
to happen. You just avoid having to do soft fork 1.

> BIP 8 with LOT=TRUE was a better activation mechanism

I completely disagree, but that's not relevant to this topic.

On Tue, Jan 18, 2022 at 11:22 AM Prayank <prayank@tutanota.de> wrote:

> > We should strive to one day get to a point where the bitcoin consensus
> isn't updating at all.
>
> That day is nowhere near IMO and maybe we won't see it in my lifetime.
>
> > Perhaps we should come to a consensus as a consensus as a community what
> the minimum time between soft forks should be, and just as importantly,
> what the minimum time between finalized consensus-change implementation and
> when we decide community consensus has been achieved.
>
> This is not possible in a decentralized network like Bitcoin and makes no
> sense. Soft forks can/should be done as and when required. This does not
> mean we do them often but if a change makes sense, looks ready, got enough
> consensus, reviewed properly etc. then timing doesn't really matter in
> every case.
>
> > Activating multiple consensus changes in a bundle is far safer than
> having multiple separate in-flight soft forks at once.
>
> This is not true. More changes bundled require more review and still more
> probability to have bugs. Security is always about keeping things simple.
>
> > One solution is that we could be a lot more direct about how decisions
> are made. There's been a lot of rhetoric around UASF and how the economic
> majority is really who's running the show.
>
> BIP 8 with LOT=TRUE was a better activation mechanism option in Taproot
> but some influential developers wrote its misleading, unsafe etc. on social
> media so you can call me negative at this moment however I have realized
> the truth is really sad and we can't blindly follow some people. There are
> lot of people who will tell you bad things about UASF and how speedy trial
> is the best thing Bitcoin has ever experienced.
>
> Michael Folkson also had some opinion in activation mechanism IIRC,
>
>
> --
> Prayank
>
> A3B1 E430 2298 178F
>

--000000000000eced1705d5e61c0a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt;=C2=A0

That day is nowhere near IMO and maybe we won&#39;t see it in my lifetime.<=
div><br></div><div>I think there is a reasonable argument to be made that m=
aybe bitcoin needs to move faster now than it should in the future, and the=
 cost of having the community remain vigilant=C2=A0against harmful changes =
is worth the extra speed. The question then becomes, does doing soft forks =
more often make things go faster? Its not clear to me that the answer is ye=
s.</div><div><br></div><div>&gt; This is not possible in a decentralized ne=
twork like Bitcoin and makes no sense.</div><div><br></div><div>Why do you =
think that its not possible? I completely disagree. The bitcoin community h=
as already come up with cultural norms like this, like the idea of doing so=
ft forks instead of hardforks wherever possible. Its impossible to prevent =
others from doing otherwise, but its completely possible and desirable for =
the bitcoin community to adopt standards that we attempt to adhere to.</div=
><div><br></div><div>&gt; More changes bundled require more review and stil=
l more probability to have bugs.=C2=A0</div><div><br></div><div>I already a=
ddressed this in my previous email. Why do you think there is more to revie=
w in a soft fork with two bundled changes than in two separate concurrent s=
oft-fork activations using BIP8 or BIP9? Both require both changes to be in=
 the software and both require testing to ensure that the changes interact =
appropriately. The difference is that in the second case, you have to test =
all combinations of which order the proposals activate in.=C2=A0</div><div>=
<br></div><div>And let&#39;s consider the easiest case of change A, then so=
ft fork 1, then change B, and soft fork 2. Change A needs to be tested all =
on its own, and change B when it comes along also then needs to be tested o=
n code that already has change A. If the changes are bundled, the same proc=
edure needs to happen. You just avoid having to do soft fork 1.=C2=A0</div>=
<div><br></div><div>&gt; BIP 8 with LOT=3DTRUE was a better activation mech=
anism</div><div><br></div><div>I completely disagree, but that&#39;s not re=
levant to this topic.=C2=A0</div></div><br><div class=3D"gmail_quote"><div =
dir=3D"ltr" class=3D"gmail_attr">On Tue, Jan 18, 2022 at 11:22 AM Prayank &=
lt;<a href=3D"mailto:prayank@tutanota.de" target=3D"_blank">prayank@tutanot=
a.de</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex">
 =20
   =20
 =20
  <div>
<div>&gt; We should strive to one day get to a point where the bitcoin cons=
ensus isn&#39;t updating at all.<br></div><div dir=3D"auto"><br></div><div =
dir=3D"auto">That day is nowhere near IMO and maybe we won&#39;t see it in =
my lifetime.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">&gt; Pe=
rhaps we should come to a consensus as a consensus as a community what the =
minimum time between soft forks should be, and just as importantly, what th=
e minimum time between finalized consensus-change implementation and when w=
e decide community consensus has been achieved.<br></div><div dir=3D"auto">=
<br></div><div dir=3D"auto">This is not possible in a decentralized network=
 like Bitcoin and makes no sense. Soft forks can/should be done as and when=
 required. This does not mean we do them often but if a change makes sense,=
 looks ready, got enough consensus, reviewed properly etc. then timing does=
n&#39;t really matter in every case.<br></div><div dir=3D"auto"><br></div><=
div dir=3D"auto">&gt; Activating multiple consensus changes in a bundle is =
far safer than having multiple separate in-flight soft forks at once.<br></=
div><div dir=3D"auto"><br></div><div dir=3D"auto">This is not true. More ch=
anges bundled require more review and still more probability to have bugs. =
Security is always about keeping things simple.<br></div><div dir=3D"auto">=
<br></div><div dir=3D"auto">&gt; One solution is that we could be a lot mor=
e direct about how decisions are made. There&#39;s been a lot of rhetoric a=
round UASF and how the economic majority is really who&#39;s running the sh=
ow.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">BIP 8 with LOT=
=3DTRUE was a better activation mechanism option in Taproot but some influe=
ntial developers wrote its misleading, unsafe etc. on social media so you c=
an call me negative at this moment however I have realized the truth is rea=
lly sad and we can&#39;t blindly follow some people. There are lot of peopl=
e who will tell you bad things about UASF and how speedy trial is the best =
thing Bitcoin has ever experienced.<br></div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">Michael Folkson also had some opinion in activation mechani=
sm IIRC,<br></div><div dir=3D"auto"><br></div><div><br></div><div>-- <br></=
div><div>Prayank<br></div><div><br></div><div dir=3D"auto">A3B1 E430 2298 1=
78F<br></div>  </div>

</blockquote></div>

--000000000000eced1705d5e61c0a--