Re: [bitcoin-dev] Improving BIP 8 soft fork activation

[alicexbt <alicexbt@protonmail.com>]

[-- Attachment #1: Type: text/plain, Size: 6460 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 10812 bytes --]