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

[Billy Tetrud via bitcoin-dev]

@alicexbt
>  I think 'support' and 'opposition' can be replaced with readiness.
Miners should not consider signaling as voting.

I agree that it isn't voting, its signaling. But whether or not you call it
'readiness' or 'support', some miners will use it to signal 'support' and
will refuse to become ready if they do not support the change. Regardless,
I'm open to calling it "readiness" instead.

@Russell
>  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.

I tend to agree. The case where the fork has not locked in, but some miners
are beginning to orphan other miners' blocks, seems like a rather chaotic
state to program into an activation mechanism. I do like the idea of using
orphaning to ensure that miners are alerted to the fact that a fork has
*already* locked in, but such a thing should be done at a low level (eg
orphan <10% of their blocks) - just high enough so the drop in revenue
makes them investigate, but as minimal as possible to avoid lots of orphans
and loss of hashpower.


On Wed, May 11, 2022 at 10:15 AM alicexbt  wrote:

> Hi Billy,
>
> Thanks for the feedback. I agree with everything
> and bip-trinary-version-signaling looks interesting.
>
> > A primary difference from both BIP8 and BIP9 is that this proposal uses
> tri-state version signaling (rather than binary version bits) that can
> encode both active support as well as active opposition to an active soft
> fork.
>
>
> I think 'support' and 'opposition' can be replaced with readiness. Miners
> should not consider signaling as voting.
>
> > The meaning for each ternary value is as follows:
>
>
> 0 - No signal
> 1 - Ready for new consensus rules
> 2 - Not ready for new consensus rules
>
> The concept of a minimum and maximum threshold sounds intriguing, and I'm
> interested to read what other developers have to say about it.
>
> Concept ACK on removing LOT, using tri-state version signaling, min/max
> threshold and required threshold calculation.
>
>
> /dev/fd0
>
> Sent with ProtonMail secure email.
> --- Original Message ---
> On Tuesday, May 10th, 2022 at 9:01 PM, Billy Tetrud billy.tet...@gmail.com
> wrote:
>
>
>
> > I think this is a useful proposal. There are certainly things about BIP9
> that BIP8 fixes. I believe taproot's speedy trial did kind of a hybrid, but
> a BIP spec was never produced for it afaik. A possibly unhelpful comment:
> >
> > > minimum_activation_height
> > > I think a minor improvement would be to specify this as
> minimum_activation_blocks, ie a number of blocks passed the start_height.
> Slightly easier to reason about and change when necessary. I proposed
> semantics like that here.
> > > In any case, I'll give this a concept ACK. I would very much like
> future soft forks to use a previously specified activation mechanism rather
> than rolling out a rushed unspeced thing as part of the (very orthogonal)
> soft fork implementation.
> > > On Tue, May 10, 2022 at 9: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/144bytes/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

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

[Greg Sanders via bitcoin-dev]

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 

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

[alicexbt via bitcoin-dev]

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 
 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 
>  wrote:
>
>> Hi 

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

[Russell O'Connor via bitcoin-dev]

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/144bytes/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

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

[alicexbt via bitcoin-dev]

Hi Billy,

Thanks for the feedback. I agree with everything and 
bip-trinary-version-signaling looks interesting.

> A primary difference from both BIP8 and BIP9 is that this proposal uses 
> tri-state version signaling (rather than binary version bits) that can encode 
> both active support as well as active opposition to an active soft fork.


I think 'support' and 'opposition' can be replaced with readiness. Miners 
should not consider signaling as voting.

> The meaning for each ternary value is as follows:


0 - No signal
1 - Ready for new consensus rules
2 - Not ready for new consensus rules

The concept of a minimum and maximum threshold sounds intriguing, and I'm 
interested to read what other developers have to say about it.

Concept ACK on removing LOT, using tri-state version signaling, min/max 
threshold and required threshold calculation.


/dev/fd0

Sent with ProtonMail secure email.
--- Original Message ---
On Tuesday, May 10th, 2022 at 9:01 PM, Billy Tetrud billy.tet...@gmail.com 
wrote:



> I think this is a useful proposal. There are certainly things about BIP9 that 
> BIP8 fixes. I believe taproot's speedy trial did kind of a hybrid, but a BIP 
> spec was never produced for it afaik. A possibly unhelpful comment:
>
> > minimum_activation_height
> > I think a minor improvement would be to specify this as 
> > minimum_activation_blocks, ie a number of blocks passed the start_height. 
> > Slightly easier to reason about and change when necessary. I proposed 
> > semantics like that here.
> > In any case, I'll give this a concept ACK. I would very much like future 
> > soft forks to use a previously specified activation mechanism rather than 
> > rolling out a rushed unspeced thing as part of the (very orthogonal) soft 
> > fork implementation.
> > On Tue, May 10, 2022 at 9: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/144bytes/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

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

[Billy Tetrud via bitcoin-dev]

I think this is a useful proposal. There are certainly things about BIP9
that BIP8 fixes. I believe taproot's speedy trial did kind of a hybrid, but
a BIP spec was never produced for it afaik. A possibly unhelpful comment:

> minimum_activation_height

I think a minor improvement would be to specify this as
minimum_activation_blocks, ie a number of blocks passed the start_height.
Slightly easier to reason about and change when necessary. I proposed
semantics like that here

.

In any case, I'll give this a concept ACK. I would very much like future
soft forks to use a previously specified activation mechanism rather than
rolling out a rushed unspeced thing as part of the (very orthogonal) soft
fork implementation.

On Tue, May 10, 2022 at 9: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/144bytes/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

[bitcoin-dev] Improving BIP 8 soft fork activation

[alicexbt via bitcoin-dev]

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/144bytes/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