📝 Original message: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220511/2cdd2915/attachment.html>;