path: root/56/7c3b3452b57f8093216a5ff6c42247501b5b64

Return-Path: <fresheneesz@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 0A4F3C000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Jun 2021 19:43:11 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id E45E4415F7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Jun 2021 19:43:10 +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,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.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 GLZy8yQe07or
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Jun 2021 19:43:09 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [IPv6:2a00:1450:4864:20::535])
 by smtp4.osuosl.org (Postfix) with ESMTPS id CFDF3415E5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Jun 2021 19:43:08 +0000 (UTC)
Received: by mail-ed1-x535.google.com with SMTP id j11so4883183edq.6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Jun 2021 12:43:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:from:date:message-id:subject:to:cc;
 bh=1psxY6DaRb3iOACDPI74yh7Pg0S1Ox1q1zqxBazMurQ=;
 b=jxhnYLCG+mZqvXo5Hd/3hSL+XGNawmGt9762Zr9FR7A+TZfBNKxuy6NPpitk497t0X
 qzBOKeM0ki6bZjrElqzyCNwK+hx3sBRGSLk0mC1KRNzvFF9jXa63nW1zpBcMw7IjskpX
 hY6N1m1ynthT+8VtpWyTb9eXPyU0jF5ANYhw1IGckZ5DRky6WKBRJsRz97rh8XLA3gb5
 3uqbDsN92yUbvIKRXT62fuN4DGAGbJNJKRUUsE6mbKcUVAkoKvrn9HquyQ+8Hn82g1OU
 XZtuUjsz03lOXXbObjb9UNZHpWqKP4sbHQfpYfm59u+DFFgOFFK+BuClYKGGYE/QI5ZC
 Iw6w==
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:from:date:message-id
 :subject:to:cc;
 bh=1psxY6DaRb3iOACDPI74yh7Pg0S1Ox1q1zqxBazMurQ=;
 b=RoB7JYrpplmdYzZYSBFIIji8TmA5R7dku+O+qzmG4M7i9LTqzTynLsZNGJmy0hq0CC
 OkVdwGvmxu8eSvK/q6KTdxDWYxLXwq+8Y7s7gJ8dVrl60+dD+KjjRsjs+DxFIB6EOxRL
 /rdAKNXwsPNWwZwi14RTE48TFTv4oscAQ8hGAqpqXRMgenxXYTmmg0Ysk6xDKqXaYhwe
 OyrXQcxzsxe9ucrsYAzFME5IIW8D5W7J6vOLcinpjY+nk0EZAZdABy+VWmzvobZGcrUf
 ezJFo6XQMt7qeGD8RLbOKoLtN40g2v5ECqGtOt5Ique70QUFWvZx4buFWRjp1S0Es+qa
 zqlg==
X-Gm-Message-State: AOAM532bPQA7jWqQG1dufi1VAz4TjFk1MLbTDmmKona/XzdLuYAvUvmz
 v2j4u1dV9fvZXDIQCbzOy8yZ68G+8z+OE6wwS8M=
X-Google-Smtp-Source: ABdhPJxBL4dmjwHeSDnDxLfWRjWslisO0dCYRXww/xmk1YrRUMEpcyqvAsdwEzKCUmhrRoGFzoLKq5dmQU1b1BBwMX8=
X-Received: by 2002:a05:6402:1c1a:: with SMTP id
 ck26mr47952859edb.230.1625082186928; 
 Wed, 30 Jun 2021 12:43:06 -0700 (PDT)
MIME-Version: 1.0
References: <CABm2gDot=YnMB8isbouLV_g=P=OAeN7H966juqbBexXyK9jw8A@mail.gmail.com>
 <2368396E-6964-4F12-B50F-2BE477D0C7D8@voskuil.org>
 <CABm2gDrt5AD8erDwJQxtPg4bSbbxbRJ_Sm2KcHrqD2a=QVX3fQ@mail.gmail.com>
 <028901d76d95$abb883f0$03298bd0$@voskuil.org>
 <CAGpPWDYTOzJcksPxQDm8HOSjW-VPvSRskKw8YJR_CnmxR5Dmfw@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Wed, 30 Jun 2021 12:42:50 -0700
Message-ID: <CAGpPWDbWbCoE3oFWh2DTw2JG-r=gOf8R=AE-U6QDKeQ1QPLnbg@mail.gmail.com>
To: Eric Voskuil <eric@voskuil.org>
Content-Type: multipart/alternative; boundary="0000000000007b96c905c600ee95"
X-Mailman-Approved-At: Wed, 30 Jun 2021 20:01:43 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades
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, 30 Jun 2021 19:43:11 -0000

--0000000000007b96c905c600ee95
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

It feels like this discussion has gotten a bit off topic. The proposal is
intended to provide a best-of-both-worlds middleground between BIP8 and
BIP9. It would be nice if we could bring it back to a discussion of my
proposal in the context of other existing deployment plans (BIP8, BIP9,
taproot's hybrid deployment, even flag days).

The main relevant actually to my proposal that have been mentioned, as far
as I can tell, is that Luke opined that explicit signaling of opposition
was unnecessary, because he thinks we shouldn't try to avoid chain splits
when there's any opposition. Jorge agreed that we shouldn't try to avoid
chain splits. But I don't really understand what either of you (Luke or
Jorge) are actually proposing is better than using my proposal. Are you
proposing LOT=3Dtrue be added as an option to my proposal? Are you proposin=
g
that we should always use a LOT=3Dtrue style flag day, and not even conside=
r
the option of permanent failure for a deployment? Or are you simply saying
that miner opposition is never relevant or useful to know during a
deployment?

Everything else has been only tenuously related:

* Who "controls" or "defines" bitcoin"?
* Who "controls" what happens during a deployment?
* Should we deploy based on miner signaling at all?

If there's so much to discuss on these philosophical points, maybe it makes
sense to branch that off into a separate thread. I'd appreciate it if we
can reconnect this discussion with the proposal this thread is about.



On Wed, Jun 30, 2021 at 12:30 PM Billy Tetrud <billy.tetrud@gmail.com>
wrote:

> @Jorge
> > I disagree...  I would oppose such a change no matter what other users
> or miners say.
>
> I don't know why you think we disagree on that point. I agree that I woul=
d
> oppose a change to 1GB blocks no matter what other users or miners say. Y=
ou
> must have misunderstood me there.
>
> >>  Are you really saying that we should just hard fork every time
> instead of soft fork?
> > No
>
> So what are you advocating for then, exactly?
>
> >> Are you not at all worried about the costs associated with an
> increased orphan rate and reorg rate?
> > Orphan blocks are bad, yes, not sure what the point of your question is=
.
>
> The point is that if we just deployed with BIP8 LOT=3Dtrue (as that seems=
 to
> be the kind of thing you're advocating for) and only 60% of miners had
> upgraded to the new update by the time it activates, orphans and reorg ra=
te
> and depths would greatly increase. The point of the question is: shouldn'=
t
> we avoid that "when possible"?
>
> > What do you think of bip99?
>
> I haven't read it before, but after reading it, it seems like a reasonabl=
e
> discussion of possibilities and types of forks. It looks like you advocat=
ed
> that "miner voting" is appropriate for some of the types of forks. And ye=
t,
> from the way you're talking in this thread, it sounds like you don't thin=
k
> any consensus rule change deployment should consider miner signaling. So
> I'm confused because it seems like the things you're saying here conflict
> with some of the things you wrote in BIP99.
>
> What specifically did you want me to get out of BIP99 in this context?
>
> @Eric
> > I=E2=80=99d also question the use of the term =E2=80=9Cmajority=E2=80=
=9D
>
> I just want to clarify that by "economic majority" I mean a set of users
> that presently accept more than 50% of the volume of payments in a given
> period of time. I definitely agree that no majority of any kind is needed
> for a split.
>
>
> On Wed, Jun 30, 2021 at 2:52 AM <eric@voskuil.org> wrote:
>
>> > From: Jorge Tim=C3=B3n <jtimon@jtimon.cc>
>>
>> >> "Soft forks aren=E2=80=99t compatible without miner enforcement"
>> > Compatible with what?
>>
>> There is a good summary of what is meant by this term in BIP141:
>> https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki
>>
>> "Backward compatibility
>> As a soft fork, older software will continue to operate without
>> modification. Non-upgraded nodes, however, will not see nor validate the
>> witness data and will consider all witness programs as anyone-can-spend
>> scripts (except a few edge cases where the witness programs are equal to=
 0,
>> which the script must fail). Wallets should always be wary of
>> anyone-can-spend scripts and treat them with suspicion. Non-upgraded nod=
es
>> are strongly encouraged to upgrade in order to take advantage of the new
>> features."
>>
>> The explanation is however incomplete. If majority hash power does not
>> enforce the new rules, the above is incorrect. Granted the word "operate=
"
>> is vague, but clearly what is intended is that "non-upgraded" nodes will
>> not be on a different coin. But in fact they would be. The underlying
>> presumption is that BIP141 is not only signaled, but enforced by majorit=
y
>> hash power.
>>
>> >> "Soft forks without miner support cause splits".
>> > No, what causes splits are 3 things:
>> >
>> > 1) bugs
>> > 2) coordination mistakes
>> > 3) people wanting different rules.
>>
>> #3 (and possibly #4) is what we're talking about, so it's not at all
>> clear why you said "no".
>>
>> People change their rules, because #3. If majority hash power does not
>> enforce this (soft) change, it's a chain split.
>>
>> > Let me give an example. Let's say all users want change A.
>> >
>> > Only 60% miners want it.
>> > When it activates with LOT=3Dtrue, will this cause a split?
>>
>> No, regardless of percentage adoption. You've proposed that it' is
>> majority hash power enforced.
>>
>> Furthermore, the term compatibility (see above) implies that not everyon=
e
>> (your impossible presumption of 100%) is aligned.
>>
>> This is not a debatable subject as far as I'm concerned, but it's worth
>> discussion for those who aren't familiar.
>>
>> e
>>
>>

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

<div dir=3D"ltr"><div>It feels like this discussion has gotten a bit off to=
pic. The proposal is intended to provide a best-of-both-worlds middleground=
 between BIP8 and BIP9. It would be nice if we could bring it back to a dis=
cussion of my proposal in the context of other existing deployment plans (B=
IP8, BIP9, taproot&#39;s=C2=A0hybrid deployment, even flag days).=C2=A0</di=
v><div><br></div><div>The main relevant actually to my proposal that have b=
een mentioned, as far as I=C2=A0can tell, is that Luke opined that explicit=
 signaling of opposition was unnecessary, because he thinks we shouldn&#39;=
t try to avoid chain splits when there&#39;s any opposition. Jorge agreed t=
hat we shouldn&#39;t try to avoid chain splits. But I don&#39;t really unde=
rstand what either of you (Luke or Jorge) are actually proposing is better =
than using my proposal. Are you proposing LOT=3Dtrue be added as an option =
to my proposal? Are you proposing that we should always use a LOT=3Dtrue st=
yle flag day, and not even consider the option of permanent failure for a d=
eployment? Or are you simply saying that miner opposition is never relevant=
 or useful to know during a deployment?=C2=A0</div><div><br></div><div>Ever=
ything else has been only tenuously related:</div><div><br></div><div>* Who=
 &quot;controls&quot; or &quot;defines&quot; bitcoin&quot;?</div><div>* Who=
 &quot;controls&quot; what happens during a deployment?</div><div>* Should =
we deploy based on miner signaling at all?</div><div><br></div><div>If ther=
e&#39;s so much to discuss on these philosophical points, maybe it makes se=
nse to branch that off into a separate thread. I&#39;d appreciate it if we =
can reconnect this discussion with the proposal this thread is about.=C2=A0=
</div><div><br></div><div><br></div></div><br><div class=3D"gmail_quote"><d=
iv dir=3D"ltr" class=3D"gmail_attr">On Wed, Jun 30, 2021 at 12:30 PM Billy =
Tetrud &lt;<a href=3D"mailto:billy.tetrud@gmail.com">billy.tetrud@gmail.com=
</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
<div dir=3D"ltr"><div>@Jorge<br></div>&gt; I disagree...=C2=A0 I would oppo=
se such a change no matter what other users or miners say.<div><br></div><d=
iv>I don&#39;t know why you think we disagree on that point. I agree that I=
 would oppose a change to 1GB blocks no matter what other users or miners s=
ay. You must have misunderstood me there.</div><div><br></div><div>&gt;&gt;=
=C2=A0<span style=3D"color:rgb(80,0,80)">=C2=A0</span><span style=3D"color:=
rgb(80,0,80)">Are you really saying that we should just hard fork every tim=
e instead of soft fork?</span></div><div><span style=3D"color:rgb(80,0,80)"=
>&gt; No</span></div><br>So what are you advocating for then, exactly? <div=
><span style=3D"color:rgb(80,0,80)"><br></span></div><div><span style=3D"co=
lor:rgb(80,0,80)">&gt;&gt;=C2=A0</span><span style=3D"color:rgb(80,0,80)">A=
re you not at all worried about the costs associated with an increased orph=
an rate and reorg rate?</span></div><div><span style=3D"color:rgb(80,0,80)"=
>&gt;=C2=A0</span>Orphan blocks are bad, yes, not sure what the point of yo=
ur question is.</div><div><br></div><div>The point is that if we just deplo=
yed with BIP8 LOT=3Dtrue (as that seems to be the kind of thing you&#39;re=
=C2=A0advocating for) and only 60% of miners had upgraded to the new update=
 by the time it activates, orphans and reorg rate and depths would greatly =
increase. The point of the question is: shouldn&#39;t we avoid that &quot;w=
hen possible&quot;?=C2=A0</div><div><br></div><div>&gt; What do you think o=
f bip99?</div><div><br></div><div>I haven&#39;t read it before, but after r=
eading it, it seems like a reasonable discussion of possibilities and types=
 of forks. It looks like you advocated that &quot;miner voting&quot; is app=
ropriate for some of the types of forks. And yet, from the way you&#39;re t=
alking in this thread, it sounds like you don&#39;t think any consensus rul=
e change deployment should consider miner signaling. So I&#39;m confused be=
cause it seems like the things=C2=A0you&#39;re saying here conflict with so=
me of the things you wrote in BIP99.=C2=A0</div><div><br></div><div>What sp=
ecifically did you want me to get out of BIP99 in this context?<br></div><d=
iv><br></div><div>@Eric<br></div><div>&gt; I=E2=80=99d also question the us=
e of the term =E2=80=9Cmajority=E2=80=9D</div><div><br></div><div>I just wa=
nt to clarify that by &quot;economic majority&quot; I mean a set of users t=
hat presently accept more than 50% of the volume of payments in a given per=
iod of time. I definitely agree that no majority of any kind is needed for =
a split.=C2=A0</div><div><br></div></div><br><div class=3D"gmail_quote"><di=
v dir=3D"ltr" class=3D"gmail_attr">On Wed, Jun 30, 2021 at 2:52 AM &lt;<a h=
ref=3D"mailto:eric@voskuil.org" target=3D"_blank">eric@voskuil.org</a>&gt; =
wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">&gt; From=
: Jorge Tim=C3=B3n &lt;jtimon@jtimon.cc&gt; <br>
<br>
&gt;&gt; &quot;Soft forks aren=E2=80=99t compatible without miner enforceme=
nt&quot;<br>
&gt; Compatible with what?<br>
<br>
There is a good summary of what is meant by this term in BIP141:<br>
<a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki" =
rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/bips/blob/m=
aster/bip-0141.mediawiki</a><br>
<br>
&quot;Backward compatibility<br>
As a soft fork, older software will continue to operate without modificatio=
n. Non-upgraded nodes, however, will not see nor validate the witness data =
and will consider all witness programs as anyone-can-spend scripts (except =
a few edge cases where the witness programs are equal to 0, which the scrip=
t must fail). Wallets should always be wary of anyone-can-spend scripts and=
 treat them with suspicion. Non-upgraded nodes are strongly encouraged to u=
pgrade in order to take advantage of the new features.&quot;<br>
<br>
The explanation is however incomplete. If majority hash power does not enfo=
rce the new rules, the above is incorrect. Granted the word &quot;operate&q=
uot; is vague, but clearly what is intended is that &quot;non-upgraded&quot=
; nodes will not be on a different coin. But in fact they would be. The und=
erlying presumption is that BIP141 is not only signaled, but enforced by ma=
jority hash power.<br>
<br>
&gt;&gt; &quot;Soft forks without miner support cause splits&quot;.<br>
&gt; No, what causes splits are 3 things:<br>
&gt;<br>
&gt; 1) bugs<br>
&gt; 2) coordination mistakes<br>
&gt; 3) people wanting different rules.<br>
<br>
#3 (and possibly #4) is what we&#39;re talking about, so it&#39;s not at al=
l clear why you said &quot;no&quot;.<br>
<br>
People change their rules, because #3. If majority hash power does not enfo=
rce this (soft) change, it&#39;s a chain split.<br>
<br>
&gt; Let me give an example. Let&#39;s say all users want change A.<br>
&gt;<br>
&gt; Only 60% miners want it.<br>
&gt; When it activates with LOT=3Dtrue, will this cause a split?<br>
<br>
No, regardless of percentage adoption. You&#39;ve proposed that it&#39; is =
majority hash power enforced.<br>
<br>
Furthermore, the term compatibility (see above) implies that not everyone (=
your impossible presumption of 100%) is aligned.<br>
<br>
This is not a debatable subject as far as I&#39;m concerned, but it&#39;s w=
orth discussion for those who aren&#39;t familiar.<br>
<br>
e<br>
<br>
</blockquote></div>
</blockquote></div>

--0000000000007b96c905c600ee95--