Milestone 4 in separate section

bsip-0040.md

@@ -46,6 +46,8 @@ Note: The user can still use the active authority just like used to, no change i
 
 This BSIP will be split into parts that will be voted on separately (see Milestones section). All of the above keys are possible with Milestone 1. Milestone 2 allows stateful restrictions (e.g. allow market orders up to some amount for every month), Milestone 3 gives finer control of how to combine restrictions and Milestone 4 allows to set a number of allowed executions per authority (introduces an additional on-chain dependency). Milestone 2, 3 and 4 will be put up for voting if Milestone 1 proves successful.
 
+Note: The impact of Milestone 4 is explained in its own section to not hinder the reading flow
+
 # Rational
 
 Custom active permission is a list of `custom active authorities`. A `custom active authority` contains an `operation_id`, 
@@ -56,9 +58,6 @@ for each operation if there is a `custom active authority` for any of its requir
 account of the transaction if all its belonging operations have at least one positively matched `custom active authority` 
 (see Specifications for definition of "matching"), and if so behave as if the active authority of the corresponding account is present (recursive authorities are excluded, see Examples).
 
-Note: If Milestone 4 is implemented, a `custom active authority` can be valid in the above-mentioned time period and/or 
-for a number of executions defined by `remaining_executions`. The user can choose to restrict both or only the number of executions, but the number of executions can only be unlimited (not set) only if a time period is specified. 
-
 # Specification
 
 All descriptions in this section are on a pseudo/prosa level and no recommendation how it can best be implemented or serialized. They are meant to facilitate the understanding. If anything in the looping process or order of evaluation is unsuitable for actual implementation, changes can be made accordingly as long the same functionality is achieved.
@@ -75,7 +74,6 @@ custom_active_authority = {
     enabled,                // status of this authority, true or false. true when created
     valid_from,             // timestamp when this is active
     valid_to,               // timestamp when this is invalid
-    remaining_executions,   // number of allowed executions 
     operation_id,           // operation id of the target operation,
     authority,              // same as for the existing authotities (multisig with weighted accounts or keys),
     restrictions            // see below
@@ -88,7 +86,6 @@ A `custom active authority` is matched against operations of an incoming, signed
 - `account_id` is in the required accounts of the operation
 - the `authority` of the `custom_active_authority` is given by the signatures of the transaction
 - timestamp `now` is within `valid_to` and `valid_from` 
-- `remaining_executions` is either not set or > 0 (only Milestone 4)
 - all `restrictions` assert positively
 
 ### Restrictions
@@ -187,7 +184,7 @@ When a signed transaction arrives and before the backend evaluates if all necess
 - iterate over `required accounts`
   - iterate over all `operations` (child operations of proposal are not included) within the transactions that require the active authority of this account
     - iterate the `custom_active_authorities` of this account, and if it matches, remember that and continue with next `operation`
-  - if a `custom active authority` match was found for every operation in the loop, behave as if the `active authority` of this account is present for the corresponding operations. Decrease `remaining_executions` by one if set (only Milestone 4)
+  - if a `custom active authority` match was found for every operation in the loop, behave as if the `active authority` of this account is present for the corresponding operations.
 
 Note:
 - A `custom_active_authority` can only grant the `active authority` of the required account of the corresponding operation, nothing more
@@ -207,6 +204,17 @@ Note:
 
 Notes: The implementation must not differentiate on which operation the custom active authority is applied, all operations are treated in same fashion
 
+### Milestone 4: Number of executions
+
+If Milestone 4 is implemented, a `custom active authority` receives an additional field `remaining_executions` to 
+specify the allowed number of executions. 
+The user can choose to restrict the valid time period and/or the number of executions, but the number of executions can only 
+be unlimited (not set) if a time period is specified. A `custom active authority` then matches if the time period is 
+valid or not set, and `remaining_executions` is either not set or > 0. When a `custom active authority` successfully grants 
+the active authority for the corresponding operation and the whole transaction is executed, `remaining_executions` is 
+decreased by one. If it becomes zero, the `custom active authority` becomes disabled. 
+If the `custom active authority` does not get replenished by the user within one month, it will be deleted.
+
 # 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:
@@ -221,6 +229,8 @@ This logic forces the user to think about the desired duration and enforces to p
 If a custom active is expired, or considered to be too short, extending it is easily doable. 
 After expired, the custom active becomes disabled and can still be enabled again with a new period, paying the fee for that new period.
 
+Note: For Milestone 4 the install fee would be dependent on the number of executions if no time period is set.
+
 # Discussion
 
 To be found in the [issue](https://github.com/bitshares/bitshares-core/issues/1061) and [pull request](https://github.com/bitshares/bsips/pull/86).
@@ -399,9 +409,6 @@ We propose do split the implmentation into two milestones. Each milestone will b
 3. Implement `logical_or`
 4. Implement `remaining_executions`
 
-This approach allows as well to add other asserts at a later stage (with a new BSIP).
-
-
 # Summary for Shareholders
 
 Bad publicity in terms of security can have very negative effect on the BTS value. This BSIP allows that traders can e.g. use a trading key, witnesses can use their witness key and a faucet can use a faucet key. If then for some reason the key or witness/faucet server becomes compromised, such a key can do little harm to the account holders, minimizing the risk.