moving around

bsip-0040.md

@@ -151,6 +151,13 @@ When a signed transaction arrives and before the backend evaluates if all necess
 Note:
 - A `custom_active_authority` can only grant the `active authority` of the corresponding account, nothing more
 
+### 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.
+- `update_custom_active_authority` and `delete_custom_active_authority`: Similar to `account_update`
+
 ### 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
@@ -161,23 +168,6 @@ Note:
 
 Notes: The implementation must not differentiate on which operation the custom active authority is applied, all operations are treated in same fashion
 
-### 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.
-- `update_custom_active_authority` and `delete_custom_active_authority`: Similar to `account_update`
-
-# Milestones
-
-We propose do split the implmentation into two milestones. Each milestone will be voted on as a separate BSIP:
-
-1. Implementation of basic functionaliy to allow custom active permissions and authorities, including `any`, `none` and `lt, le, gt, ge` and `attribute_assert` `asserts`. If deemed necessary by developpers, reduce to only allow one key or one account for every `custom active authority`
-2. Implement stateful asserts `limit` and `limit_monthly`
-3. Implement `logical_or`
-
-This approach allows as well to add other asserts at a later stage (with a new BSIP).
-
 # 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).
@@ -310,6 +300,17 @@ Acive authority of Account A is granted and normal authority checks are continue
 Since the required accounts is Account A, and the given accounts is also Account A through `custom active authority 2`, 
 the transaction is executed.
 
+# Milestones
+
+We propose do split the implmentation into two milestones. Each milestone will be voted on as a separate BSIP:
+
+1. Implementation of basic functionaliy to allow custom active permissions and authorities, including `any`, `none` and `lt, le, gt, ge` and `attribute_assert` `asserts`. If deemed necessary by developpers, reduce to only allow one key or one account for every `custom active authority`
+2. Implement stateful asserts `limit` and `limit_monthly`
+3. Implement `logical_or`
+
+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.