Replace "rules/force" mutation with a "cannot be ignored" prefix to rule names

1 files changed, 5 insertions, 9 deletions

diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki
index 95dd740..0e1d7bd 100644
--- a/bip-0009.mediawiki
+++ b/bip-0009.mediawiki
@@ -191,15 +191,11 @@ The "version" key of the template is retained, and used to indicate the server's
 If versionbits is being used, "version" MUST be within the versionbits range of [0x20000000...0x3FFFFFFF].
 Miners MAY clear or set bits in the block version WITHOUT any special "mutable" key, provided they are listed among the template's "vbavailable" and (when clearing is desired) NOT included as a bit in "vbrequired".
 
-The mutable key defined by BIP 23 is expanded to optionally include one new mutation:
-
-{| class="wikitable"
-!colspan=4| mutations
-|-
-! Value !! Significance
-|-
-| rules/force || the miner may ignore rules it does not understand, if the template is to be used as-is (not modified by the client)
-|}
+Softfork deployment names listed in "rules" or as keys in "vbavailable" may be prefixed by a '!' character.
+Without this prefix, GBT clients may assume the rule will not impact usage of the template as-is; typical examples of this would be when previously valid transactions cease to be valid, such as BIPs 16, 65, 66, 68, 112, and 113.
+If a client does not understand a rule without the prefix, it may use it unmodified for mining.
+On the other hand, when this prefix is used, it indicates a more subtle change to the block structure or generation transaction; examples of this would be BIP 34 (because it modifies coinbase construction) and 141 (since it modifies the txid hashing and adds a commitment to the generation transaction).
+A client that does not understand a rule prefixed by '!' must not attempt to process the template, and must not attempt to use it for mining even unmodified.
 
 Servers should only signal this mutation when they have verified a client behaving this way will not produce invalid blocks.
 This includes verifying the client's supported rules (listed in the template request) are not lacking of a rule that would change serialisation.