Greg Sanders [ARCHIVE] on Nostr: 📅 Original date posted:2022-05-12 📝 Original message:I think you may be ...
📅 Original date posted:2022-05-12
📝 Original message: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 at 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 at 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 at 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:
>>
>> 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220512/ee216a78/attachment.html>;
📝 Original message: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 at 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 at 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 at 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:
>>
>> 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220512/ee216a78/attachment.html>;