From 8dce3724c530deb6deb84debfc523883f8f90c2a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Stefan=20Schie=C3=9Fl?= Date: Thu, 2 Aug 2018 16:37:31 +0200 Subject: [PATCH] change typos --- bsip-0040.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/bsip-0040.md b/bsip-0040.md index 7b9fa6d..45c456c 100644 --- a/bsip-0040.md +++ b/bsip-0040.md @@ -37,7 +37,7 @@ With this BSIP any user can create keys with specific purpose (everything else i The above list of named keys is nothing that is known to the backend as the backend should have an abstract implementation. The UI could provide a button "Create Trading Key" that properly configures the respective custom active permission entry. -This BSIP will be split into two parts that will be voted on serparately (see Milestones section). All of the above keys are possible with Milestone 1. Milestone 2 allows statefull restrictions (e.g. allow market orders up to some amount for every month), Milestone 3 gives finer control of how to combine restrictions. Milestone 2 and 3 will be put up for voting if Milestone 1 proves successful. +This BSIP will be split into two 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. Milestone 2 and 3 will be put up for voting if Milestone 1 proves successful. # Rational @@ -56,10 +56,10 @@ custom_active_permission = { authorities = list of custom_active_authority objects } custom_active_authority = { - valid_from, // timestamp when this is active, defaults to now - valid_to, // timestamp when this is invalid, defaults to 1 year + valid_from, // timestamp when this is active + valid_to, // timestamp when this is invalid operation_id, // operation id of the target operation, - authority, // same as for the existing authortities (multisig with weighted accounts or keys), + authority, // same as for the existing authotities (multisig with weighted accounts or keys), restrictions // see below } ``` @@ -98,7 +98,7 @@ List of possible restrictions are: | `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) +- if there is no value given (e.g. an optional argument, or nested value not given), the restrictions is passed (even if the underlying operation understands the absence of a key as instructions to delete it on-chain, see bitshares/bitshares-core#838) - if the expected type of the argument does not match the given type (no implicit type conversion), the restriction is violated - if the function of the restriction asserts negatively, the restriction is violated @@ -115,7 +115,7 @@ Stateless assert, all argument types. `Argument value` must be equal to one of v Stateless assert, all argument types. `Argument value` must NOT be equal to any of the values in the list. #### `lt, le, gt, ge` -Stateless assert. Allows explicit type converstion: +Stateless assert. Allows explicit type conversion: - `int` type: use as is - `string` type: use `length` of string as `argument value` @@ -126,12 +126,12 @@ The different asserts read as: - `ge`: `Argument value` must be greater than or equal to `comparative` #### `limit` -Statefull assert, only `int` type arguments. When the authority is created, `interval_began` is set to `valid_from` from its custom active authority and `max_cumsum` to `0`. Incoming operations are first tried to match all stateless asserts, -and if all passes continue with statefull asserts. If `now > interval_began + interval_in_sec`, then set `max_cumsum = 0` and set `interval_began = now`. +Stateful assert, only `int` type arguments. When the authority is created, `interval_began` is set to `valid_from` from its custom active authority and `max_cumsum` to `0`. Incoming operations are first tried to match all stateless asserts, +and if all passes continue with stateful asserts. If `now > interval_began + interval_in_sec`, then set `max_cumsum = 0` and set `interval_began = now`. The assert that needs to pass is now `current_cumsum + incoming value <= max_cumsum`. If all `asserts` of this `custom_active_authority` pass, update `current_cumsum = current_cumsum + incoming value`. #### `limit_monthly` -Statefull assert, only `int` type arguments. Analogue to `limit`, but `interval_began` is initially set to `month(valid_from)` and set to `month(now)` on update, additionally the time assert is `month(now) >= interval_began + interval_in_months` (include logic for month overflow when year changes). +Stateful assert, only `int` type arguments. Analogue to `limit`, but `interval_began` is initially set to `month(valid_from)` and set to `month(now)` on update, additionally the time assert is `month(now) >= interval_began + interval_in_months` (include logic for month overflow when year changes). #### `attribute_assert` Stateless assert, only for dictionary type objects. The data list contains restrictions that all must pass, the reference for the `argument` of the child restriction is nested into the attributes of the parent dictionary type object. Allows nesting of `attribute_assert`.