path: root/ac/9f80b7279bef779856fa8c28efb227b46dacd2

Return-Path: <roconnor@blockstream.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 459FEC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 11 May 2022 19:22:54 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 42EBF83133
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 11 May 2022 19:22:54 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.899
X-Spam-Level: 
X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, BITCOIN_IMGUR=1, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key)
 header.d=blockstream-com.20210112.gappssmtp.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 YiZk4eX3n8VL
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 11 May 2022 19:22:53 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com
 [IPv6:2607:f8b0:4864:20::f2a])
 by smtp1.osuosl.org (Postfix) with ESMTPS id DB59582F9B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 11 May 2022 19:22:52 +0000 (UTC)
Received: by mail-qv1-xf2a.google.com with SMTP id kj8so2808545qvb.6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 11 May 2022 12:22:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=blockstream-com.20210112.gappssmtp.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=Q2ABZPHt73l+oC9YiQaS4dmQlGFFR+FgCVfFirXrDj8=;
 b=1xGE2a1UzqI64ohnW6KIVXvCF7AMd1F81K150PyLMB2Bi18l3g3gHYz8hKODeCAJ95
 7M/i7jR7vU7h5bWlpyBroBg0QD1ZlvSR/81Wu5dKNr+tkQ5Y7xkg+qLeAuyVJJjyd9bq
 vjnwUSCHEO8RunFwS4U+mSwLiZoAdZkxZcydrkQqnq+NqYPyIR+VLbmmKE2UL6bwKt5B
 4nkJoHeYKIuFzJInWazvXWGp+Ib6PNOQB9NKc46cAc5Vv2yAIdp6uzUxal1WJpCTaBSn
 I6KIKCDKi0u6BzcKHNxLzMyR4WCUfdjNwOzbMNixEJd4qx+x9wfMQjo9v6rLwldJhI0m
 vcbw==
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;
 bh=Q2ABZPHt73l+oC9YiQaS4dmQlGFFR+FgCVfFirXrDj8=;
 b=zMTh+rplmDIq5K4E3ifxYS/0cjuIEolZXa9udnHB9ebZZzy6r7oVB0NEjojLjLtUCR
 B7jAhYuk83dprQN1cbh/sGyxCasvMal5UHnyCcEf0EvaJO9Rqf9URkR4paKsYlq5RuRT
 OeEz6mdu3WohlSdhD8dhagR7CpYeYhdeUWsCRC3NmTuhi83S/4oiXjnkjFJCHuxc6pp/
 mBb7tqdLcq84TdU8gtr39DBy9mb7ePmhy8615578fNZCxP9wnm1IiR6GE5b5zoWFUBEO
 TatvABDAg4ZzLnM+gzvPccKIkOJ4otE1EbM+hYHEydN+w4J+28HYUgZzAcHEl9/H3tOP
 ls7w==
X-Gm-Message-State: AOAM5325w/fdRbPDGycXQ/A4Z+Q+AjOHHh1kKfnNdgh3TbtlN3C4RpPu
 ka1KRPjALUKq7AYD1FcCvMApJENY/ncxWHlJUhVy85JkwBqATQ==
X-Google-Smtp-Source: ABdhPJy/2YZaABiGkfHH5d71BB2Tai7eq6Ern4meFFYq71pCxmMbRJDwtOBfNk96cTIl46Q0RDdvlLk0C+rRTYJeFnU=
X-Received: by 2002:a0c:f1d2:0:b0:45a:8012:1a90 with SMTP id
 u18-20020a0cf1d2000000b0045a80121a90mr23723325qvl.31.1652296971328; Wed, 11
 May 2022 12:22:51 -0700 (PDT)
MIME-Version: 1.0
References: <8ZKbVUejj2P32rYfjnMaE6sLpiSUdQNHI-cNNpQ2KZiDT-TYrXrKUxJidZH0O5U1jMMllgpF2qiYuahUBeCBQ8ZAIKhIvIgZJ7PM9_b2t64=@protonmail.com>
In-Reply-To: <8ZKbVUejj2P32rYfjnMaE6sLpiSUdQNHI-cNNpQ2KZiDT-TYrXrKUxJidZH0O5U1jMMllgpF2qiYuahUBeCBQ8ZAIKhIvIgZJ7PM9_b2t64=@protonmail.com>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Wed, 11 May 2022 15:22:40 -0400
Message-ID: <CAMZUoKmXFxoSs5_5EM8ptAOpiiGP4ryqAibn5eghkbsaYz+oQA@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000000a35b105dec15ed2"
Subject: Re: [bitcoin-dev] Improving BIP 8 soft fork activation
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, 11 May 2022 19:22:54 -0000

--0000000000000a35b105dec15ed2
Content-Type: text/plain; charset="UTF-8"

Hi alicexbt,

As far as I understand things, I believe the whole notion of a MUST_SIGNAL
state is misguided today. Please correct me if I'm misunderstanding
something here.

Back when BIP8 was first proposed by Shaolin Fry, we were in a situation
where many existing clients waiting for segwit signalling had already been
deployed.  The purpose of mandatory signaling at that point in time was to
ensure all these existing clients would be activated together with any BIP8
clients.

However, if such other clients do not exist, the MUST_SIGNAL state no
longer accomplishes its purpose.  Going forward, I think there is little
reason to expect such other clients to exist alongside a BIP8 deployment.
If everyone uses a BIP8 deployment, then there are no other clients to
activate.  Alternatively, Speedy Trial was specifically designed to avoid
this parallel deployment for the reason that several people object to
allowing their client's non-BIP8 activation logic to be hijacked in this
manner.

Now I understand that some people would like *some* signal on the chain
that indicates a soft-fork activation in order to allow people who object
to the fork to make an "anti-fork" that rejects blocks containing the
soft-fork signal.  And while some sort of mandatory version bit signaling
*could* be used for this purpose, we do not *have* to use version bits.  We
also don't need such a signal span over multiple blocks.  Indeed, using
version bits and signaling over multiple blocks is quite bad because it
risks losing mining power if miners don't conform, or are unable to
conform, to the version bits signal.  (Recall at the time taproot's
signaling period started, the firmware needed for many miners to signal
version bits did not even exist yet!).

A soft-fork signal to enable an "anti-fork" only needs to be on a single
block and it can be almost anything.  For example we could have a signal
that at the block at lockin or perhaps the block at activation requires
that the coinbase must *not* contain the suffix "taproot sucks!".  This
suffices to prepare an "anti-fork" which would simply require that the
specified block must contain the suffix "taproot sucks!".

Anyway, I'm sure there are lots of design choices available better than a
MUST_SIGNAL state that does not risk potentially taking a large fraction of
mining hardware offline for a protracted period of time.

On Tue, May 10, 2022 at 10:02 AM alicexbt via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Bitcoin Developers,
>
> There were some disagreements with speedy trial activation method recently
> and BIP 8 became controversial because of LOT earlier. I have tried to
> solve these two problems after reading some arguments for/against different
> activation methods by removing LOT from BIP 8 and calculating MUST_SIGNAL
> state based on threshold reached.
>
> BIP draft with no code and some changes in BIP 8:
> https://gist.github.com/1440000bytes/5e58cad7ba9d9c1a7000d304920fe6f1
>
> State transitions diagram: https://i.imgur.com/dj4bFVK.png
>
> This proposal removes lockinontimeout flag, activation never fails
> although MUST_SIGNAL can be longer if miners signaling does not reach the
> threshold. Longer period for MUST_SIGNAL state is useful for coordination
> if LOCKED_IN was not reached.
>
> MUST_SIGNAL = ((100-t)/10)*2016 blocks, where t is threshold reached and
> blocks that fail to signal in MUST_SIGNAL phase are invalid.
>
> Example:
>
> - This activation method is used for a soft fork
> - Only 60% miners signaled readiness and timeout height was reached
> - MUST_SIGNAL phase starts and will last for 4*2016 blocks
> - LOCKED_IN and ACTIVE states remain same as BIP 8
> - Soft fork is activated with a delay of 2 months
>
>
> /dev/fd0
>
> Sent with ProtonMail <https://protonmail.com/> secure email.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div>Hi alicexbt,</div><div><br></div><div>As far as I und=
erstand things, I believe the whole notion of a MUST_SIGNAL state is misgui=
ded today. Please correct me if I&#39;m misunderstanding something here.</d=
iv><div><br></div><div>Back when BIP8 was first proposed by Shaolin Fry, we=
 were in a situation where many existing clients waiting for segwit signall=
ing had already been deployed.=C2=A0 The purpose of mandatory signaling at =
that point in time was to ensure all these existing clients would be activa=
ted together with any BIP8 clients.</div><div><br></div><div>However, if su=
ch other clients do not exist, the MUST_SIGNAL state no longer accomplishes=
 its purpose.=C2=A0 Going forward, I think there is little reason to expect=
 such other clients to exist alongside a BIP8 deployment.=C2=A0 If everyone=
 uses a BIP8 deployment, then there are no other clients to activate.=C2=A0=
 Alternatively, Speedy Trial was specifically designed to avoid this parall=
el deployment for the reason that several people object to allowing their c=
lient&#39;s non-BIP8 activation logic to be hijacked in this manner.</div><=
div><br></div><div>Now I understand that some people would like *some* sign=
al on the chain that indicates a soft-fork activation in order to allow peo=
ple who object to the fork to make an &quot;anti-fork&quot; that rejects bl=
ocks containing the soft-fork signal.=C2=A0 And while some sort of mandator=
y version bit signaling *could* be used for this purpose, we do not *have* =
to use version bits.=C2=A0 We also don&#39;t need such a signal span over m=
ultiple blocks.=C2=A0 Indeed, using version bits and signaling over multipl=
e blocks is quite bad because it risks losing mining power if miners don&#3=
9;t conform, or are unable to conform, to the version bits signal.=C2=A0 (R=
ecall at the time taproot&#39;s signaling period started, the firmware need=
ed for many miners to signal version bits did not even exist yet!).</div><d=
iv><br></div><div>A soft-fork signal to enable an &quot;anti-fork&quot; onl=
y needs to be on a single block and it can be almost anything.=C2=A0 For ex=
ample we could have a signal that at the block at lockin or perhaps the blo=
ck at activation requires that the coinbase must *not* contain the suffix &=
quot;taproot sucks!&quot;.=C2=A0 This suffices to prepare an &quot;anti-for=
k&quot; which would simply require that the specified block must contain th=
e suffix &quot;taproot sucks!&quot;.</div><div><br></div><div>Anyway, I&#39=
;m sure there are lots of design choices available better than a MUST_SIGNA=
L state that does not risk potentially taking a large fraction of mining ha=
rdware offline for a protracted period of time.<br></div></div><br><div cla=
ss=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, May 10, 20=
22 at 10:02 AM alicexbt via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@l=
ists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wro=
te:<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 style=
=3D"font-family:arial;font-size:14px">Hi Bitcoin Developers,<br>
<br>
There were some disagreements with speedy trial activation method recently =
and BIP 8 became controversial because of LOT earlier. I have tried to solv=
e these two problems after reading some arguments for/against different act=
ivation methods by removing LOT from BIP 8 and calculating MUST_SIGNAL stat=
e based on threshold reached.<br>
<br>
BIP draft with no code and some changes in BIP 8:=C2=A0<a href=3D"https://g=
ist.github.com/1440000bytes/5e58cad7ba9d9c1a7000d304920fe6f1" target=3D"_bl=
ank">https://gist.github.com/1440000bytes/5e58cad7ba9d9c1a7000d304920fe6f1<=
/a><br>
<br>
State transitions diagram:=C2=A0<a href=3D"https://i.imgur.com/dj4bFVK.png"=
 target=3D"_blank">https://i.imgur.com/dj4bFVK.png</a><br>
<br>
This proposal removes lockinontimeout flag, activation never fails although=
 MUST_SIGNAL can be longer if miners signaling does not reach the threshold=
. Longer period for MUST_SIGNAL state is useful for coordination if LOCKED_=
IN was not reached.<br>
<br>
MUST_SIGNAL =3D ((100-t)/10)*2016 blocks, where t is threshold reached and =
blocks that fail to signal in MUST_SIGNAL phase are invalid.<br>
<br>
Example:=C2=A0<br>
<br>
- This activation method is used for a soft fork=C2=A0<br>
- Only 60% miners signaled readiness and timeout height was reached<br>
- MUST_SIGNAL phase starts and will last for 4*2016 blocks<br>
- LOCKED_IN and ACTIVE states remain same as BIP 8<br>
- Soft fork is activated with a delay of 2 months</div><div style=3D"font-f=
amily:arial;font-size:14px"><br>
<br>
/dev/fd0<br><br>

<div style=3D"font-family:arial;font-size:14px">
    <div>

            </div>

            <div>
        Sent with <a href=3D"https://protonmail.com/" rel=3D"noopener noref=
errer" target=3D"_blank">ProtonMail</a> secure email.
    </div>
</div>
</div>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--0000000000000a35b105dec15ed2--