An epoch in CKB (4 hours) is far shorter than an epoch in BItcoin (2 weeks). The tally period of softfork signaling should be long enough so it's resistant to governance attack. Instead of 1 epoch (4 hours), I think CKB softfork activation tally period should be at least as long as Bitcoin's (2 weeks ~= 90 CKB epochs).

I'm not so sure it's appropriate to measure the replacement in realistic time, CKB is much faster to mine, 2 weeks ~= 151,200 blocks.
A big problem with BIP9 is that without the cooperation of miners, the process would be relatively long and a year would be wasted if it failed. So Speedy Trial proposes to "Start soon, Stop soon", there may have room for compromise here, for period and timeout.

Despite its similarities with BIP9, I would still like the following information to be added to the RFC so that it is more friendly to readers like me.

• Before presenting the parameters: where are these parameters written? Are they part of the block, or written somewhere on some website?
• How long should the fallow pause be? Do we need to prescribe miners to clear the bit for a long-enough time before we can assign a new meaning to that bit?

I agree with Jan that deciding on a soft fork upgrade with a four-hour epoch seems too short. Perhaps it's better to define a longer time-unit like "era" (90 epochs each) and make decisions based on eras. Personally, I think a month or two is enough to make decisions. So we can set the parameters so that as soon as all miners are on board, the soft fork is activated in a month.

An epoch in CKB (4 hours) is far shorter than an epoch in BItcoin (2 weeks). The tally period of softfork signaling should be long enough so it's resistant to governance attack. Instead of 1 epoch (4 hours), I think CKB softfork activation tally period should be at least as long as Bitcoin's (2 weeks ~= 90 CKB epochs).

I'm not so sure it's appropriate to measure the replacement in realistic time, CKB is much faster to mine, 2 weeks ~= 151,200 blocks. A big problem with BIP9 is that without the cooperation of miners, the process would be relatively long and a year would be wasted if it failed. So Speedy Trial proposes to "Start soon, Stop soon", there may have room for compromise here, for period and timeout.

Why is lockinontimeout not included in this proposal?

lockinontimeout

lockinontimeout is the logic of BIP8, which is used to start a flag day.

• MUST_SIGNAL for one retarget period prior to the timeout, if LOCKED_IN was not reached and lockinontimeout is true.
• During the MUST_SIGNAL phase, if (2016 - threshold) blocks in the retarget period have already failed to signal, any further blocks that fail to signal are invalid.

Optimistically, we hope that BIP8 will not be used,
BIP8 forced signaling (or automatic activation) in specific, is that it can be risky, this scheme could split the network between upgraded and non-upgraded nodes.

This risk is probably best countered by offering enough time to upgrade. Unfortunately, not everyone agrees on how much time is enough.

The current signaling period is tentatively set at 42 epochs, approximately one week.