path: root/02/cc66317774ec8366fa609469811fcd558b4a8c

Return-Path: <gsanders87@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 731D6C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 12 May 2022 22:56:36 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 5EDF8415C0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 12 May 2022 22:56:36 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level: 
X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, 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: 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 qUAWye8ww511
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 12 May 2022 22:56:33 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com
 [IPv6:2607:f8b0:4864:20::b31])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 410B041570
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 12 May 2022 22:56:33 +0000 (UTC)
Received: by mail-yb1-xb31.google.com with SMTP id m190so12420984ybf.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 12 May 2022 15:56:33 -0700 (PDT)
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=vQwIlxW4HkiKKlgGy44bEd77+Th/oD/drKJHM7cCIGk=;
 b=pDGkocL8yeVw2Q32ji5V//NGuRCSk0Moww59wKjzBUpnYRXP6yVnyP8PDJmTnReQSZ
 6NHZ472q8roucgL9+FTV930Tvkuj5xZ0M/RTBag4SvsB3qZO3ZDXjFEKxKLD+v6UPiS0
 ixXv2Q4XyO5m+LY7EKrbtgZAsnO4jEusqzSXJnFciZWWrQZ4D0RVK4tmk2iO5YK5m6Kb
 vFtrEflacWoUHkpcaObfTVu4qg6HOMWhpQGXa/A2SNz63KJTaINtJPeNVoV+NYrm/IbX
 NOZnAu22qraFPsNUJBdybmSFw079cHWZ1PpYmnobkCYSS2sG/soVar4AC8FaQSp2GMhz
 lQZg==
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=vQwIlxW4HkiKKlgGy44bEd77+Th/oD/drKJHM7cCIGk=;
 b=ptQPDy9Ai/0rRUIEotsVMG5JzsBEkTuKAX99Ak+04hanVouGHAy9eT77vwb+SxOh2Z
 ru35XSIqWW/02rQs3YLv0vgLYEnteap1KHVOnwck1N7qUBpmqUHlkvWxRhHbQFgaNK5i
 LloBGnpQQurgElJ+89L5IaeZ8EZTEwpBhjZiAjmY4liCme0gkhP4GSy+xmB9D4fsbH4k
 rZPhsHvfOKBxLh/0az3nnSYLO4YKRNJ4Fd6ewD/RwYsu6VTYZflBWnoTN0J7wlnUh1Iw
 lMdpwLoJuib1kyFb+wFNAnlwYul/zGjRDvwZ/mG4Kz26/Zz22jwx0HbcDZOd3moxgs0/
 uepA==
X-Gm-Message-State: AOAM533UxxkrLvPZqqvPQxqloKabYt4WkF0fh11JNtxavMFhfzBqQOlA
 or4A6J2PAJa9/SUr06l+1glrdHJn9IJw6Je1txZOHxA4
X-Google-Smtp-Source: ABdhPJxut9DPgrQbA86e8sEIcI9/I/+wzVQQMtxfBfO/rzqG3TktcFFIsaKawO/3NAJtlldAaegeVTHKeWYGGf0rae0=
X-Received: by 2002:a25:848e:0:b0:64a:6b66:49f with SMTP id
 v14-20020a25848e000000b0064a6b66049fmr2166125ybk.276.1652396192083; Thu, 12
 May 2022 15:56:32 -0700 (PDT)
MIME-Version: 1.0
References: <8ZKbVUejj2P32rYfjnMaE6sLpiSUdQNHI-cNNpQ2KZiDT-TYrXrKUxJidZH0O5U1jMMllgpF2qiYuahUBeCBQ8ZAIKhIvIgZJ7PM9_b2t64=@protonmail.com>
 <CAMZUoKmXFxoSs5_5EM8ptAOpiiGP4ryqAibn5eghkbsaYz+oQA@mail.gmail.com>
 <kQ7oSMJyxVmU6SPSgRfgGFb6rT0MtUEoZhaSaarnv1yalWc9aPD4tOQcVfanxWFFFDGSE3Nfiyg99BhQx8547obgRh3wCOlydMk6lNEInV4=@protonmail.com>
In-Reply-To: <kQ7oSMJyxVmU6SPSgRfgGFb6rT0MtUEoZhaSaarnv1yalWc9aPD4tOQcVfanxWFFFDGSE3Nfiyg99BhQx8547obgRh3wCOlydMk6lNEInV4=@protonmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Thu, 12 May 2022 18:56:22 -0400
Message-ID: <CAB3F3DubWD-xV53dBTHU6agzhTz6mGV7DN5p=5OCZ=4-put6WQ@mail.gmail.com>
To: alicexbt <alicexbt@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000000eb1d905ded87818"
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: Thu, 12 May 2022 22:56:36 -0000

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

I think you may be confused. Mandatory signaling is not the same thing as
mandatory activation on timeout, aka Lock On Timeout aka LOT=true.

These are two related but separate things.

On Thu, May 12, 2022, 6:53 PM alicexbt via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Russell,
>
>
> 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.
>
>
> I won't consider it misguided. Not using MUST_SIGNAL gives opportunity for
> drama and politics during signaling. MUST_SIGNAL phase is initiated when
> height + 2016 >= timeoutheight and if a mining pool is still not sure about
> signaling at that point, maybe they are not interested in mining bitcoin
> anymore.
>
> Rephrasing 'motivation' section in BIP 8:
>
> BIP 9 activation is dependent on near unanimous hashrate signaling which
> may be impractical and result in veto by a small minority of
> non-signaling hashrate. All consensus rules are ultimately enforced by full
> nodes, eventually any new soft fork will be enforced by the economy. BIP 8
> provides optional flag day activation after a reasonable time, as well as
> for accelerated activation by majority of hash rate before the flag date.
>
> 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!).
>
>
> Solutions to these problems:
>
> 1)Developers plan and ship the binaries with activation code in time.
> 2)Mining pools pay attention, participate in soft fork discussions, hire
> competent developers and reach out to developers in community if require
> help.
> 3)Mining pools understand the loss involved in mining invalid blocks and
> upgrade during the first month of signaling.
>
> If some mining pools still mine invalid blocks, Bitcoin should still work
> normally as it did during May-June 2021 when 50% hashrate went down due to
> some issues in China.
>
>
> /dev/fd0
>
> Sent with ProtonMail <https://protonmail.com/> secure email.
>
> ------- Original Message -------
> On Thursday, May 12th, 2022 at 12:52 AM, Russell O'Connor via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> 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
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"auto">I think you may be confused. Mandatory signaling is not t=
he same thing as mandatory activation on timeout, aka Lock On Timeout aka L=
OT=3Dtrue.<div dir=3D"auto"><br></div><div dir=3D"auto">These are two relat=
ed but separate things.=C2=A0</div></div><br><div class=3D"gmail_quote"><di=
v dir=3D"ltr" class=3D"gmail_attr">On Thu, May 12, 2022, 6:53 PM alicexbt v=
ia bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org"=
>bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div style=3D"font-family:arial;font-size:14px;color:rgb=
(34,34,34)">Hi Russell,</div><div style=3D"font-family:arial;font-size:14px=
;color:rgb(34,34,34)"><br></div><div style=3D"font-family:arial;font-size:1=
4px;color:rgb(34,34,34)"><br></div><div style=3D"font-family:arial;font-siz=
e:14px;color:rgb(34,34,34)"><blockquote type=3D"cite" style=3D"padding:0px =
0px 0px 1rem;margin:0px;border-left:4px solid rgb(229,229,229);color:rgb(0,=
0,0);font-family:Arial,&quot;Helvetica Neue&quot;,Helvetica,sans-serif;back=
ground-color:rgb(255,255,255)"><div dir=3D"ltr"><span>As far as I understan=
d things, I believe the whole notion of a MUST_SIGNAL state is misguided to=
day. Please correct me if I&#39;m misunderstanding something here.</span><d=
iv><br></div><span>Back when BIP8 was first proposed by Shaolin Fry, we wer=
e 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 togeth=
er with any BIP8 clients.</span></div></blockquote></div><div style=3D"font=
-family:arial;font-size:14px;color:rgb(34,34,34)"><br></div><div style=3D"f=
ont-family:arial;font-size:14px;color:rgb(34,34,34)">I won&#39;t consider i=
t misguided. Not using MUST_SIGNAL gives opportunity for drama and politics=
 during signaling. MUST_SIGNAL phase is initiated when height + 2016 &gt;=
=3D timeoutheight and if a mining pool is still not sure about signaling at=
 that point, maybe they are not interested in mining bitcoin anymore.</div>=
<div style=3D"font-family:arial;font-size:14px;color:rgb(34,34,34)"><br></d=
iv><div style=3D"font-family:arial;font-size:14px;color:rgb(34,34,34)">Reph=
rasing &#39;motivation&#39; section in BIP 8:</div><div style=3D"font-famil=
y:arial;font-size:14px;color:rgb(34,34,34)"><br></div><div><font color=3D"#=
222222" face=3D"arial">BIP 9 activation is dependent on near unanimous hash=
rate signaling=C2=A0which may be impractical and result in veto by a small =
minority of non-signaling=C2=A0hashrate.=C2=A0All consensus rules are ultim=
ately enforced by full nodes, eventually any new soft fork will be enforced=
 by the economy. BIP 8 provides optional flag day activation after a reason=
able time, as well as for accelerated activation by majority of hash rate b=
efore the flag date.</font></div><div style=3D"font-family:arial;font-size:=
14px;color:rgb(34,34,34)"><span><br></span></div><div style=3D"font-family:=
arial;font-size:14px;color:rgb(34,34,34)"><span><blockquote type=3D"cite" s=
tyle=3D"padding:0px 0px 0px 1rem;margin:0px;border-left:4px solid rgb(229,2=
29,229);color:rgb(0,0,0);font-family:Arial,&quot;Helvetica Neue&quot;,Helve=
tica,sans-serif;background-color:rgb(255,255,255)"><div dir=3D"ltr"><span>W=
e also don&#39;t need such a signal span over multiple blocks. Indeed, usin=
g version bits and signaling over multiple blocks is quite bad because it r=
isks losing mining power if miners don&#39;t conform, or are unable to conf=
orm, to the version bits signal. (Recall at the time taproot&#39;s signalin=
g period started, the firmware needed for many miners to signal version bit=
s did not even exist yet!).</span></div></blockquote><br></span></div><div =
style=3D"font-family:arial;font-size:14px;color:rgb(34,34,34)">Solutions to=
 these problems:</div><div style=3D"font-family:arial;font-size:14px;color:=
rgb(34,34,34)"><br></div><div style=3D"font-family:arial;font-size:14px;col=
or:rgb(34,34,34)">1)Developers plan and ship the binaries with activation c=
ode in time.</div><div style=3D"font-family:arial;font-size:14px;color:rgb(=
34,34,34)">2)Mining pools pay attention, participate in soft fork discussio=
ns, hire competent developers and reach out to developers in community if r=
equire help.</div><div style=3D"font-family:arial;font-size:14px;color:rgb(=
34,34,34)">3)Mining pools understand the loss involved in mining invalid bl=
ocks and upgrade during the first month of signaling.</div><div style=3D"fo=
nt-family:arial;font-size:14px;color:rgb(34,34,34)"><br></div><div style=3D=
"font-family:arial;font-size:14px;color:rgb(34,34,34)">If some mining pools=
 still mine invalid blocks, Bitcoin should still work normally as it did du=
ring May-June 2021 when 50% hashrate went down due to some issues in China.=
=C2=A0</div><div style=3D"font-family:arial;font-size:14px;color:rgb(34,34,=
34)"><br></div><div style=3D"font-family:arial;font-size:14px;color:rgb(34,=
34,34)"><br></div><div style=3D"font-family:arial;font-size:14px;color:rgb(=
34,34,34)">/dev/fd0</div><div style=3D"font-family:arial;font-size:14px"><b=
r></div>
<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 noreferrer" target=3D"_blank">ProtonMail</a> secure email.
    </div>
</div>
<div style=3D"font-family:arial;font-size:14px"><br></div><div>
        ------- Original Message -------<br>
        On Thursday, May 12th, 2022 at 12:52 AM, Russell O&#39;Connor via b=
itcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" tar=
get=3D"_blank" rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a>=
&gt; wrote:<br><br>
        <blockquote type=3D"cite">
            <div dir=3D"ltr"><div>Hi alicexbt,</div><div><br></div><div>As =
far as I understand things, I believe the whole notion of a MUST_SIGNAL sta=
te is misguided today. Please correct me if I&#39;m misunderstanding someth=
ing here.</div><div><br></div><div>Back when BIP8 was first proposed by Sha=
olin Fry, we were in a situation where many existing clients waiting for se=
gwit signalling had already been deployed.  The purpose of mandatory signal=
ing at that point in time was to ensure all these existing clients would be=
 activated together with any BIP8 clients.</div><div><br></div><div>However=
, if such other clients do not exist, the MUST_SIGNAL state no longer accom=
plishes its purpose.  Going forward, I think there is little reason to expe=
ct such other clients to exist alongside a BIP8 deployment.  If everyone us=
es a BIP8 deployment, then there are no other clients to activate.  Alterna=
tively, Speedy Trial was specifically designed to avoid this parallel deplo=
yment for the reason that several people object to allowing their client&#3=
9;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* signal on th=
e chain that indicates a soft-fork activation in order to allow people who =
object to the fork to make an &quot;anti-fork&quot; that rejects blocks con=
taining 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 versio=
n bits.  We also don&#39;t need such a signal span over multiple blocks.  I=
ndeed, using version bits and signaling over multiple blocks is quite bad b=
ecause it risks losing mining power if miners don&#39;t conform, or are una=
ble to conform, to the version bits signal.  (Recall at the time taproot&#3=
9;s signaling period started, the firmware needed for many miners to signal=
 version bits did not even exist yet!).</div><div><br></div><div>A soft-for=
k signal to enable an &quot;anti-fork&quot; only needs to be on a single bl=
ock 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 th=
e coinbase must *not* contain the suffix &quot;taproot sucks!&quot;.  This =
suffices to prepare an &quot;anti-fork&quot; which would simply require tha=
t the specified block must contain the suffix &quot;taproot sucks!&quot;.</=
div><div><br></div><div>Anyway, I&#39;m sure there are lots of design choic=
es 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.<br></div></div><br><div class=3D"gmail_quote"><div class=3D"gmail=
_attr" dir=3D"ltr">On Tue, May 10, 2022 at 10:02 AM alicexbt via bitcoin-de=
v &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noref=
errer nofollow noopener noreferrer" target=3D"_blank">bitcoin-dev@lists.lin=
uxfoundation.org</a>&gt; wrote:<br></div><blockquote style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class=
=3D"gmail_quote"><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: <a href=3D"https://gist.g=
ithub.com/1440000bytes/5e58cad7ba9d9c1a7000d304920fe6f1" rel=3D"noreferrer =
nofollow noopener noreferrer" target=3D"_blank">https://gist.github.com/144=
0000bytes/5e58cad7ba9d9c1a7000d304920fe6f1</a><br>
<br>
State transitions diagram: <a href=3D"https://i.imgur.com/dj4bFVK.png" rel=
=3D"noreferrer nofollow noopener noreferrer" target=3D"_blank">https://i.im=
gur.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: <br>
<br>
- This activation method is used for a soft fork <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 rel=3D"noreferrer nofollow noopener noreferrer" href=
=3D"https://protonmail.com/" 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" rel=3D"noreferrer =
nofollow noopener noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoun=
dation.org</a><br>
<a rel=3D"noreferrer nofollow noopener noreferrer" href=3D"https://lists.li=
nuxfoundation.org/mailman/listinfo/bitcoin-dev" target=3D"_blank">https://l=
ists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>

        </blockquote><br>
    </div>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--0000000000000eb1d905ded87818--