From 12355d607a3109b85a66adab9069edd433d5508d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Stefan=20Schie=C3=9Fl?= Date: Mon, 30 Jul 2018 15:29:19 +0200 Subject: [PATCH] clarify milestone procedure --- bsip-0040.md | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/bsip-0040.md b/bsip-0040.md index 9075c52..df75900 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 give finer control of how to combine restrictions and will also allow statefull restrictions (e.g. allow market orders up to some amount for every month). +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. # Rational @@ -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 | stateless | +| `logical` | 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) @@ -136,10 +136,9 @@ Statefull assert, only `int` type arguments. Analogue to `limit`, but `interval_ #### `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`. -#### `logical` -Stateless assert, only for dictionary type objects. The data is a list of restrictions, `argument` defines the logical link -- `OR`: If one of the restrictions in data passes, this restriction passes -- `AND`: If ALL restrictions in data pass, this restriction passes +#### `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. #### Example: Nested arguments like `options` Assume `asset_update_operation`. All attributes of its `options` must be filled on update call. This assert can not be used to realize a "may only change attribute xzy of `options`". This would require that the logic knows which of the arguments are reflected on-chain and it knows how to query it for every operation that contains `options`. If `options` are to be restricted with this assert, all values that should not change would need be fixated by defining an `any` assert for those attributes, while having e.g. a `lt` assert for the one attribute that is allowed to change. @@ -186,8 +185,7 @@ custom active authority = { cut_out = [ { - function: logical, - argument: OR, + function: logical_or, data: [ either_list, or_list ] } ] @@ -298,7 +296,8 @@ Normal accounts can only create custom active authoritites with a duration of ma 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` and `logical` +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).