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

include milestone differentation

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

8
bsip-0040.md
View file

@ -37,6 +37,8 @@ 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).
# Rational # Rational
Custom active permission is a list of `custom active authorities`. A `custom active authority` contains an `operation_id`, an `authority` (just like with active permission) and `restrictions` than can be used to restrict arguments and is only valid a certain time period (`valid_from` and `valid_to`). When handling incoming signed transactions, the backend checks for each operation if there is a `custom active authority` for any of its required accounts. Check for every required account of the transaction if all its belonging operations have at least one positively matched `custom active authority` (match means its `authority` is granted through present signatures, same `operation_id`, now is within `valid_to` and `valid_from` and none of the `restrictions` is violated), and if so grant the active authority of the corresponding account. Custom active permission is a list of `custom active authorities`. A `custom active authority` contains an `operation_id`, an `authority` (just like with active permission) and `restrictions` than can be used to restrict arguments and is only valid a certain time period (`valid_from` and `valid_to`). When handling incoming signed transactions, the backend checks for each operation if there is a `custom active authority` for any of its required accounts. Check for every required account of the transaction if all its belonging operations have at least one positively matched `custom active authority` (match means its `authority` is granted through present signatures, same `operation_id`, now is within `valid_to` and `valid_from` and none of the `restrictions` is violated), and if so grant the active authority of the corresponding account.
@ -182,7 +184,7 @@ custom active authority = {
restrictions: cut_out restrictions: cut_out
} }
cut_out =[ cut_out = [
{ {
function: logical, function: logical,
argument: OR, argument: OR,
@ -244,7 +246,9 @@ That has the consquence now that a transfer transaction sending funds away from
- it sends less than 10000 of asset X to account C - it sends less than 10000 of asset X to account C
- it sends less than or equal to 20000 of asset Y to account C - it sends less than or equal to 20000 of asset Y to account C
Note: This is just an illustration of a possible serialization, not a specification of the serialized format. Note:
- This is just an illustration of a possible serialization, not a specification of the serialized format.
- This is not included in the first Milestone
### Outline of handling incoming transactions ### Outline of handling incoming transactions