Fix flags/permissions, positive logic

Author: jmjatlanta

bsip-0048.md

@@ -32,31 +32,31 @@ The ability to change the precision of a created asset adds flexibility in the a
 
 # Rational
 
-`disable_modify_max_supply` will be added to `asset_issuer_permissions`. The permission can be activated to forbid the modification of the `max_supply` (`asset_object.options`). The related flag can only be set to `false` if `current_supply` is zero.
+`enable_modify_max_supply` will be added to `asset_issuer_permissions`. The permission can be activated to permit the modification of the `max_supply` (`asset_object.options`).
 
-`disable_issue` will be added to `asset_issuer_permissions`. The permission can be activated to forbid issuance of additional tokens. Once the related flag is set to `true`, it can not be changed.
+`enable_issue` will be added to `asset_issuer_permissions`. The permission can be set to `false` to permit the related flag to be set to `false`, which will not permit issuance of tokens. Once the flag is set to `false`, it can not be changed.
 
 Changing the precision of an asset should be easily accomplished with an `asset_update_operation`. This causes no harm while the asset is not issued.
 
 # Specifications
 
 This BSIP comes with changes to the protocol, hence requires a propotocol upgrade. However the changes to the code are minor.
 
-For `disable_modify_max_supply`:
+For `enable_modify_max_supply`:
 
-1. Add `disable_modify_max_supply` to the issuer permissions
-2. Set `disable_modify_max_supply` to false for existing assets at hardfork time
+1. Add `enable_modify_max_supply` to the issuer permissions
+2. Set `enable_modify_max_supply` to `true` for existing assets at hardfork time
 3. Add a `can_modify_max_supply()` to the `asset_object`
-4. Change the `asset_update_evaluator::do_evaluate` method to assert false for
-    1. the setting of the `disable_modify_max_supply` flag to `false` if `current_supply` is not zero or
-    2. the modification of the `max_supply` when the `disable_modify_max_supply` is `true`
+4. Change the `asset_update_evaluator::do_evaluate` method to assert false when
+    1. the setting of the `enable_modify_max_supply` flag to `true` if `current_supply` is not zero or
+    2. the modification of the `max_supply` when the `enable_modify_max_supply` is `false`
 
-For `disable_issue`:
+For `enable_issue`:
 
-1. Add `disable_issue` to the issuer permissions
-2. Set `disable_issue` to `false` for existing assets at hardfork time
+1. Add `enable_issue` to the issuer permissions
+2. Set `enable_issue` to `true` for existing assets at hardfork time
 3. Add a `can_issue()` to the `asset_object`
-4. Change the `asset_update_evaluator::do_evaluate` method to assert false for the setting of the `disable_issue` flag to `false` if it is currently `true`
+4. Change the `asset_update_evaluator::do_evaluate` method to assert false for the setting of the `enable_issue` flag to `true` if it is currently `false`
 5. Change the `asset_issue_evaluator::do_evaluate` method to assert false if `can_issue()` returns false
 6. Change the `call_order_update_evalutator::do_evaluate` method to assert false if `can_issue()` returns false
 
@@ -69,13 +69,13 @@ To change the precision:
 
 # Risks
 
-It is believed that the addition of `disable_modify_max_supply` and `disable_issue` will add security for asset holders.
+It is believed that the addition of `enable_modify_max_supply` and `enable_issue` will add security for asset holders.
 
 There is the risk to parties interested in acquiring the asset if the precision is changed after due diligence and before issuance.  
 
 # Discussion
 
-Using `disable_` as names for boolean values is not advisable and can lead to confusion. However, these names were chosen for compatibility reasons. See the comments [of a similar situation here](https://github.com/bitshares/bitshares-core/pull/1375#pullrequestreview-164580457).
+Using `disable_` as names for boolean values is not advisable and can lead to confusion. See the comments [of a similar situation here](https://github.com/bitshares/bitshares-core/pull/1375#pullrequestreview-164580457). Rather than continue the legacy behavior, this BSIP will take a different tack and use positive logic. While it may be confusing for a time, future permissions and flags will use positive logic, and previous negative logic permissions will be changed to use positive logic (not part of this BSIP).
 
 # Summary for Shareholders