From 0c43bfd8bab11e72fdb6ee002d4f91efd3c4ecaa Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Stefan=20Schie=C3=9Fl?= Date: Fri, 10 Aug 2018 07:26:10 +0200 Subject: [PATCH] Update bsip-0040.md --- bsip-0040.md | 29 +++++++++++++++-------------- 1 file changed, 15 insertions(+), 14 deletions(-) diff --git a/bsip-0040.md b/bsip-0040.md index 17793a6..ea935ec 100644 --- a/bsip-0040.md +++ b/bsip-0040.md @@ -186,20 +186,6 @@ Note: - The actual active authority of a required account can still be given as before, existing behavior is not to be changed - This for illustration, not actual implementation instructions -### 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`: 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, `duration` refers to the time that is still left, not the actual duration - (i.e. `date_to - max(now, date_from)`) -- `update_custom_active_authority`: Base fee similar to `account_update` plus dynamic one for any duration changes, no payback if duration in decreased. -- `delete_custom_active_authority`: Cheap similar to `limit_order_cancel` - -This logic forces the user to think about the desired duration and enforces to put it rather too short than too long. -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. - ### 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 @@ -213,6 +199,21 @@ After expired, the custom active becomes disabled and can still be enabled again 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`: 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, `duration` refers to the time that is still left, not the actual duration + (i.e. `date_to - max(now, date_from)`) +- `update_custom_active_authority`: Base fee similar to `account_update` plus dynamic one for any duration changes, no payback if duration in decreased. +- `delete_custom_active_authority`: Cheap similar to `limit_order_cancel` + +This logic forces the user to think about the desired duration and enforces to put it rather too short than too long. +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. + # 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).