From 03f24f0fb36f0ca144d0a77a7b938266bc2b5c1c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Stefan=20Schie=C3=9Fl?= Date: Mon, 30 Jul 2018 16:16:18 +0200 Subject: [PATCH] more cleaning up --- bsip-0040.md | 23 +++++++++++------------ 1 file changed, 11 insertions(+), 12 deletions(-) diff --git a/bsip-0040.md b/bsip-0040.md index c734a61..7b9fa6d 100644 --- a/bsip-0040.md +++ b/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 = [ {