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

more cleaning up

bsip53
Stefan Schießl 2018-07-30 16:16:18 +02:00 committed by GitHub
parent b1864f8a8a
commit 03f24f0fb3
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 11 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
bsip-0040.md
View File

@ -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 =
[
{