Comments in IRC provide some context: without the information in rules field "miners have no way to know what rules are being used and might produce invalid blocks"

Discussion in 16060 is here: #16060 (comment)

(For clarity, I didn't mean fixing this bug in a separate PR, but rather the missing "!" and/or bad name/description of the gbt_force flag.)

#9955 introduced a bug, sure, but that bug would only have impacted Segwit-unaware miners. Segwit-aware miners would have continued to work correctly because they saw that segwit was an active rule.

Removing the rule entirely means that sigops are counted differently, and transactions may not include witness data. I don't know if there are any real-world miners impacted by this, but it is at least theoretically possible (IIRC, at least some branches of Eloipool support a safety trim based on sigop counts).

that bug would only have impacted Segwit-unaware miners.

I think you have this the wrong way round. Segwit-unaware miners would see "segwit" in the rules, but according to BIP 9:

Without this ["!"] prefix, GBT clients may assume the rule will not impact usage of the template as-is;

and so the segwit-unaware miner would use the template, but not be able to add the witness commitment to the coinbase.

sigops are counted differently

Since #14811, the GBT request must include "segwit" in the rule array, so sigops are always counted according to BIP 141 rules. Whether or not the return object includes "segwit" in the rules doesn't change this.

In any case, I think it's fine to make this change because it doesn't really matter. Segwit has been active for two years and all miners using 0.18 onwards have to set "segwit" in the rules. I find it very hard to believe that any are reading what's returned in the rules field.

I think you have this the wrong way round. Segwit-unaware miners would see "segwit" in the rules,

They would fail by mining invalid blocks, instead of failing explicitly. Either way, they fail.

Segwit-capable miners, on the other hand, shouldn't fail, but might because they think they're mining a non-segwit block.

Since #14811, the GBT request must include "segwit" in the rule array, so sigops are always counted according to BIP 141 rules.

The request rule doesn't affect sigop counting, only indicates the client can understand a segwit template. Sigop counting is enabled only when the template has segwit in its rules list.

FYI without this mining with ckpool breaks since it will only try to produce segwit blocks when the segwit rule is seen.

FYI without this mining with ckpool breaks since it will only try to produce segwit blocks when the segwit rule is seen.

@jameshilliard can you point me at the code that does that? The only getblocktemplate "rules" handling code I was able to find in ckpool was checking that the gbt response doesn't contain an unknown rule: https://bitbucket.org/ckolivas/ckpool/src/73f560cf3144f824823077c1b9e1663d89823ed7/src/bitcoin.c#lines-127

@jnewbery Well here's the workaround ck had to apply.

ACK 412d5fe

Thanks for the references, James.

Tested ACK 412d5fe.

This should be backported to v0.20.

This this need a new rc? Maybe not for a two-line change?

I suggest either creating a backport pr or bringing it up in the meeting, so that it is not forgotten.