include new comments

bsip-0040.md

@@ -101,8 +101,9 @@ List of possible restrictions are:
 | `logical_or`     | list of restrictions lists | stateless |
 
 Following cases must hold for a restriction:
+- when the `custom_active_authority` is installed, the basic argument types (without nesting) are checked, and installing denying if not matching
 - if there is no value given (e.g. an optional argument, or nested value not given), the restrictions is passed (even if the underlying operation understands the absence of a key as instructions to delete it on-chain, see bitshares/bitshares-core#838)
-- if the expected type of the argument does not match the given type (no implicit type conversion), the restriction is violated
+- if the expected type of the argument does not match the given type (no implicit type conversion), the restriction is violated (needed for nested `attribute_assert`)
 - if the function of the restriction asserts negatively, the restriction is violated
 
 Note: 
@@ -157,18 +158,21 @@ Note:
 ### Economics
 
 Adding a custom active authority means increased effort for the backend, and with a stateful one also the need for more storage. Proposed transaction fees:
-- `install_custom_active_authority`: Tied to the duration of the custom active authority. 
-Normal accounts can only create custom active authoritites with a duration of maximum 1 year. LTM can do any duration and also unlimited, but the transaction fee is capped at duration of 2 years.
+- `install_custom_active_authority`: Normal accounts can only create custom active authoritites with a duration of maximum 1 year, LTM can do any duration. Two options come to mind:
+  - A fixed high fee independent of authorities content
+  - Tied to the duration and complexity of the custom active authority. Transaction fee is then `fee = flat_fee + basic_fee * duration` where `basic_fee` is calculated according to complexity (e.g. size of authority, number of restrictions and etc.). Fee is capped at 1 year for LTM.
 - `update_custom_active_authority`: Base fee similar to `account_update` plus dynamic one for any duration changes
 - `delete_custom_active_authority`: Cheap similar to `limit_order_cancel`
 
 ### Modification to the backend
 
 * Add a new index or extend the account object to store custom active permission are assigned to an account and contain a list of custom active authorities. Multiple custom active authority entries are possible for one operation
-* If the active authority of the account is updated, all custom active authorities are disabled and must be enabled again with using `update_custom_active_authority`
 * Provide operations: `install_custom_active_authority`, `update_custom_active_authority`, `delete_custom_active_authority` to allow changing the custom active permission (3 operation to allow custom transaction fees and avoid having to send the complete list of all authorities for every update)
+* If the active authority of the account is updated, all custom active authorities are disabled and must be manually specified / re-enabled. User can either
+  1. keep the authorities enabled by specifying them in a list of `custom_active_authorities` in `extensions` of `account_update_operation`
+  2. enable them again afterwards by using `update_custom_active_authority`
 * Operation-specific authorities (if present) must be evaluated in incoming transactions
-* Remove expired custom_active_authorities on maintenance
+* Remove expired custom_active_authorities on maintenance if they are expired for longer than one month
 * Additional committee parameters may be needed to limit the extend of usage of this feature
 
 Notes: The implementation must not differentiate on which operation the custom active authority is applied, all operations are treated in same fashion