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.
Yup, that’s how I understood it, too.
No idea why they decided that was a good idea. It makes a bit more sense for softforks that enable new features, because users want to be sure that the rules are being reliably enforced before risking funds by using the feature. Since RDTS is just aiming to reject some transactions and their blocks are valid to non-upgraded nodes anyway, I don’t see what benefit they thought it would have.
I had pointed out recently that “modified BIP 9 activation” was a tad underspecified and asked them to include more details on how their mandatory activation works. It seems that they just copied the mechanism of BIP 8.
man luke-jr is really taking his sweet time with this plot to force core to add utreexo.
Indeed haha.
He did start reviewing the knots pull req so that's good.
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.
if you cannot reach 55% before that time, how is it safer?
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....
It’s not safer. Assuming that they disconnect peers who send them invalid blocks, it just means that RDTS nodes split off two difficulty periods earlier, if only a minority of the hashrate is in support of the soft fork.
This was exactly my question. It sounds like it just moves up the activation deadline, even if it isn't actually activated.
I do seem to remember @dathon_ohm saying that they wouldn't disconnect, though.
https://twiiit.com/dathon_ohm/status/2017632362612314574
Thanks, I hadn’t seen that, yet.
@DailyStacker is a bot
You, @Scoresby and @optimism failed the turing test
No, that's not what the BIP or the activation client code says.
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
https://twiiit.com/murchandamus/status/2020216619390365948