agorise/bsips
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

clarify milestone procedure

Browse source
This commit is contained in:
Stefan Schießl 2018-07-30 15:29:19 +02:00 committed by GitHub
parent 9b07069a8f
commit 12355d607a
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 8 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

17
bsip-0040.md
View file

@ -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 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. 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 # Rational
@ -95,7 +95,7 @@ List of possible restrictions are:
| `limit` | [`max_cumsum`, `interval_in_sec`] | [`current_cumsum`, `interval_began`] | | `limit` | [`max_cumsum`, `interval_in_sec`] | [`current_cumsum`, `interval_began`] |
| `limit_monthly` | [`max_cumsum`, `interval_in_months`] | [`current_cumsum`, `interval_began`] | | `limit_monthly` | [`max_cumsum`, `interval_in_months`] | [`current_cumsum`, `interval_began`] |
| `attribute_assert` | list of restrictions | stateless | | `attribute_assert` | list of restrictions | stateless |
| `logical` | list of restrictions | stateless | | `logical` | list of restrictions lists | stateless |
Following cases must hold for a restriction: 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 (no change, no violation)
@ -136,10 +136,9 @@ Statefull assert, only `int` type arguments. Analogue to `limit`, but `interval_
#### `attribute_assert` #### `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`. 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` #### `logical_or`
Stateless assert, only for dictionary type objects. The data is a list of restrictions, `argument` defines the logical link Stateless assert, only for dictionary type objects. The data is a list of restrictions lists, i.e.
- `OR`: If one of the restrictions in data passes, 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.
- `AND`: If ALL restrictions in data pass, this restriction passes
#### Example: Nested arguments like `options` #### 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. 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 = [ cut_out = [
{ {
function: logical, function: logical_or,
argument: OR,
data: [ either_list, or_list ] 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: 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` 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). This approach allows as well to add other asserts at a later stage (with a new BSIP).