pull down to refresh

You can now read the details of the Reduce Data Temporary Soft Fork in the BIPs repository. Inclusion in the rep doesn't mean it's active or necessarily going to activate, but rather that the BIP is in a fairly complete form.

BIPs can still be edited, but it seems that the above link is a good place to find the most up to date details on it.

If you're curious about their proposed deployment plan:

Personally, I'm still a little confused by the activation plan. I saw this:

It seems like if they do not meet their required 55% of blocks signalling before block 961542, there will be one difficulty period where BIP 110 nodes require all blocks to signal and those that do not will be treated as invalid by BIP 110 nodes. Then there will be one difficulty period where BIP 110 activation is locked in, and then in the next difficulty period BIP 110 nodes will actually start enforcing the more strict rules about transactions as proposed in the BIP.

I'm confused about the necessity of the mandatory signalling period. I'm sure there is a reason for it, but I haven't been able to grok it. If the rules will go active one way or the other in 965664, why bother with mandatory signalling? I'd think that was only useful if they planned on not ever activating the rules unless the threshold is met.

I think the mandatory signalling period is basically a coordination buffer — it prevents nodes from enforcing the new rules before the majority have clearly switched. Even if activation is scheduled, the signalling phase helps miners and node operators sync their versions and avoid accidental chain splits.

It’s kind of a “grace period” rather than a vote. Once everyone’s aligned, enforcement becomes safer.

reply

if you cannot reach 55% before that time, how is it safer?

reply

True, if it never reaches the 55% threshold then activation stalls — that’s by design. The “safer” part is mostly about avoiding premature enforcement. It ensures that nodes don’t start rejecting blocks under the new rules until enough of the network has signaled. Basically, it trades speed for coordination....

reply
0 sats \ 1 reply \ @optimism 1h
if it never reaches the 55% threshold then activation stalls

No, that's not what the BIP or the activation client code says.

Standard BIP9 uses a time-based timeout that transitions to FAILED if the threshold is not reached. This deployment sets timeout to NO_TIMEOUT and instead uses a BIP8-like, height-based max_activation_height. The deployment transitions to LOCKED_IN at height 963648 (one retarget period before max_activation_height), then to ACTIVE at height 965664.
Similar to BIP8, this deployment enforces mandatory signaling during the retarget period immediately before mandatory lock-in (blocks 961632 to 963647; lock-in happens no later than block 963648). During this window, blocks that do not signal bit 4 are rejected as invalid. Mandatory signaling ends once the deployment reaches the LOCKED_IN state.
reply

Got it, that makes sense — sounds like this deployment is mixing aspects of BIP8 and BIP9 in a unique way. Appreciate the detailed breakdown

That's what my first thought was too

reply