more cleaning up

bsip-0040.md

@@ -79,7 +79,7 @@ A dictionary-type object like
 ```
 restriction = {
    function,     // argument_identifier
-   argument,     // constant value, or pointer to a dynamic value (argument of the operation, or attribute when nested)
+   argument,     // pointer to a dynamic value (argument of the operation, or attribute when nested)
    data,         // data specific to the function
 }
 ```
@@ -95,7 +95,7 @@ List of possible restrictions are:
 | `limit` | [`max_cumsum`, `interval_in_sec`]      | [`current_cumsum`, `interval_began`] |
 | `limit_monthly` | [`max_cumsum`, `interval_in_months`]      | [`current_cumsum`, `interval_began`] |
 | `attribute_assert` | list of restrictions | stateless |
-| `logical`     | list of restrictions lists | stateless |
+| `logical_or`     | list of restrictions lists | stateless |
 
 Following cases must hold for a restriction:
 - if there is no value given (e.g. an optional argument, or nested value not given), the restrictions is passed (no change, no violation)
@@ -138,7 +138,7 @@ Stateless assert, only for dictionary type objects. The data list contains restr
 
 #### `logical_or`
 Stateless assert, only for dictionary type objects. The data is a list of restrictions lists, i.e. 
-`data = [ [restriction 1, restriction 2], [restriction 3, restriction 4], ... ]`. If one of the restrictions sub-lists in data passes as whole, this restriction passes.
+`data = [ [restriction 1, restriction 2], [restriction 3, restriction 4], ... ]`. If one of the restrictions sub-lists in data passes as whole, this restriction passes. In above miniexample that would mean if `restriction 1` and `restriction 2` pass, the whole `logical_or` restriction is considered to be passed as well.
 
 ### Outline of handling incoming transactions
  
@@ -156,7 +156,8 @@ Note:
 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.
-- `update_custom_active_authority` and `delete_custom_active_authority`: Similar to `account_update`
+- `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
 
@@ -222,16 +223,14 @@ custom active authority = {
        key_auth: []
        account_auth: [account B, 1]
     },
-    restrictions: cut_out
+    restrictions: [  
+        {
+            function: logical_or,
+            data: [ either_list, or_list ]
+        }  
+    ]
 }
 
-cut_out = [  
-    {
-        function: logical_or,
-        data: [ either_list, or_list ]
-    }
-]
-    
 either_list =
 [  
     {