Change "remove" to "disable or remove" committee parameter.

Author: christophersanborn

bsip-0069.md

@@ -158,13 +158,13 @@ struct head_block_time_ge_time_predicate
 
 ### Activation of new predicates and removal of max_predicate_opcode parameter:
 
-A hard-fork date shall be chosen for activation of these new predicates and shall be sufficiently future-dated to allow time for nodes to upgrade.  The outdated committee parameter `max_predicate_opcode` shall be removed, as it is not needed for safe upgrade (see next section for discussion).
+A hard-fork date shall be chosen for activation of these new predicates and shall be sufficiently future-dated to allow time for nodes to upgrade.  The outdated committee parameter `max_predicate_opcode` shall be disabled, and, if possible without impacting history, removed, as it is not needed for safe upgrade (see next section for discussion).
 
 # Discussion
 
 ### Removal of max_predicate_opcode parameter:
 
-The set of committee parameters currently includes a parameter called `max_predicate_opcode`, which in the current protocol must be increased in order to activate new predicates.  The parameter is not a necessary protection in the protocol upgrade procedure, as the hard-fork mechanism is already both sufficient and necessary, making this parameter redundant.  Nor is there any clear justification for involving the committee in the mechanics of protocol upgrade.  In fact, the parameter appears to have already been forgotten, as it was not incremented after the addition of the most recent assert predicate, with the result that `block_id_predicate`, while defined and supported in the protocol, is not in fact usable on the network.  It seems quite unlikely that this was an intentional decision.  Thus we think the removal of this parameter and the associated validation checks are justified.
+The set of committee parameters currently includes a parameter called `max_predicate_opcode`, which in the current protocol must be increased in order to activate new predicates.  The parameter is not a necessary protection in the protocol upgrade procedure, as the hard-fork mechanism is already both sufficient and necessary, making this parameter redundant.  Nor is there any clear justification for involving the committee in the mechanics of protocol upgrade.  In fact, the parameter appears to have already been forgotten, as it was not incremented after the addition of the most recent assert predicate, with the result that `block_id_predicate`, while defined and supported in the protocol, is not in fact usable on the network.  It seems quite unlikely that this was an intentional decision.  Thus we think the removal or disabling of this parameter and the associated validation checks are justified.
 
 # Summary for Shareholders