The term “force” is ambiguous and not used in BIP9 where there ! rule prefix is introduced.
E.g. this code is hard to read:
0if (!gbt_force) {
1 s.insert(s.begin(), '!');
Additionally, #29039 renamed gbt_vb_name to gbt_force_name which, at least for me, further increased the confusion.
This is a pure (variable rename) refactor (plus documentation) and does not change behavior.
Reminder of how to verify a scripted diff:
0test/lint/commit-script-check.sh origin/master..HEAD
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/32386.
See the guideline for information on the review process.
| Type | Reviewers |
|---|---|
| ACK | achow101, janb84, musaHaruna, glozow |
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
The term "force" is ambiguous and not used in BIP9 where the ! rule
prefix is introduced.
Additionally, #29039 renamed gbt_vb_name to gbt_force_name which
might increase the confusion.
-BEGIN VERIFY SCRIPT-
sed -i s/gbt_force_name/gbt_rule_value/g ./src/rpc/mining.cpp
sed -i s/gbt_force/gbt_optional_rule/g $(git grep -l gbt_force)
-END VERIFY SCRIPT-
Note that there this field combines three effects:
I don’t think the third effect has ever actually been used: since bip9, segwit was the only gbt_force=false rule, but that was set to gbt_force=true prior to activation with #9955. See also #16060 and #17946. In particular https://github.com/bitcoin/bitcoin/pull/16060/files#r309323261
I also documented some of the ! behavior in #26201. It might be worth including that here, along with @ajtowns’s explanation.
Behavior (3) is implemented here (code from master, so no rename):
This seems potentially dangerous when combined with forced signalling, which IIRC has occasionally been proposed after Bitcoin Core already shipped activation code. Once something is locked in, there’s less utility in (correctly) signalling, so it could make sense to “lie”, especially since behavior (2) inevitably kicks at activation time:
On the other hand, perhaps a helpful community member notices the lack of signalling at this stage and alerts the miner of the impending doom. And SPV clients could use it to anticipate a bumpy period of small reorgs.
