Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 731D6C002D for ; 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 ; 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 ; 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 ; Thu, 12 May 2022 22:56:33 +0000 (UTC) Received: by mail-yb1-xb31.google.com with SMTP id m190so12420984ybf.4 for ; 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> In-Reply-To: From: Greg Sanders Date: Thu, 12 May 2022 18:56:22 -0400 Message-ID: To: alicexbt , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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
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.

These are two relat= ed but separate things.=C2=A0

On Thu, May 12, 2022, 6:53 PM alicexbt v= ia bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Hi Russell,


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'm misunderstanding something here.
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.

I won'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 >= =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.
=

Reph= rasing 'motivation' section in BIP 8:

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.

W= e also don'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't conform, or are unable to conf= orm, to the version bits signal. (Recall at the time taproot's signalin= g period started, the firmware needed for many miners to signal version bit= s did not even exist yet!).

Solutions to= these problems:

1)Developers plan and ship the binaries with activation c= ode in time.
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.
3)Mining pools understand the loss involved in mining invalid bl= ocks and upgrade during the first month of signaling.

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


/dev/fd0
Sent with ProtonMail secure email.

------- Original Message -------
On Thursday, May 12th, 2022 at 12:52 AM, Russell O'Connor via b= itcoin-dev <bitcoin-dev@lists.linuxfoundation.org= > wrote:

Hi alicexbt,

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'm misunderstanding someth= ing here.

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.

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= 9;s non-BIP8 activation logic to be hijacked in this manner.

=
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 "anti-fork" 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'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't conform, or are una= ble to conform, to the version bits signal. (Recall at the time taproot= 9;s signaling period started, the firmware needed for many miners to signal= version bits did not even exist yet!).

A soft-for= k signal to enable an "anti-fork" 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 "taproot sucks!". This = suffices to prepare an "anti-fork" which would simply require tha= t the specified block must contain the suffix "taproot sucks!".

Anyway, I'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.

On Tue, May 10, 2022 at 10:02 AM alicexbt via bitcoin-de= v <bitcoin-dev@lists.lin= uxfoundation.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 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.

BIP draft with no code and some changes in BIP 8: https://gist.github.com/144= 0000bytes/5e58cad7ba9d9c1a7000d304920fe6f1

State transitions diagram: https://i.im= gur.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 =3D ((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 secure email.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoun= dation.org
https://l= ists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--0000000000000eb1d905ded87818--