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 >