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

Comments from pmconrad

Browse source
This commit is contained in:
Stefan Schießl 2018-07-27 13:14:48 +02:00 committed by GitHub
parent 28f96bafcc
commit 10fa5ad679
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 5 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
bsip-0040.md
View file

@ -32,19 +32,19 @@ Examples:
- Proposal Update Key: Approve proposals (2FA comes to mind) - Proposal Update Key: Approve proposals (2FA comes to mind)
- Faucet Key: Allow only to create accounts - Faucet Key: Allow only to create accounts
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 should 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.
# Rational # Rational
The description here is more on a superficial level and no recommendation how it can best be implemented. The description here is more on a superficial level and no recommendation how it can best be implemented.
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 `assert`s than can be used to restricted arguments. When a transaction is signed with such an authority the backend checks if the contained operation has a corresponding custom active authority entry and if so acts as if the active authority of the corresponding account is given. It also checks if the arguments are in the allowed range. 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 `assert`s than can be used to restrict arguments. When a transaction is signed with such an authority the backend checks if the contained operation has a corresponding custom active authority entry and if so acts as if the active authority of the corresponding account is given. It also checks if the arguments are in the allowed range.
A Custom Active Permission looks like follows (in JSON for clarification, backend serializes and stores in a different way): A Custom Active Permission looks like follows (in JSON for clarification, backend serializes and stores in a different way):
``` ```
custom_active_permission = list of custom_active_authority items custom_active_permission = list of custom_active_authority items
custom_active_authority = { custom_active_authority = {
operationid, operationid,
auhtority, authority,
assert assert
} }
``` ```
@ -68,7 +68,7 @@ That has the consquence now that a a transfer transaction sending funds away fro
# Specifications # Specifications
Requirements to modify the backend includes Requirements to modify the backend includes
* Extend the account object to store custom active permission * Extend the account object to store custom active permission that includes a list of custom active authorities. Multiple custom active authority entries are possible for one operation
* Extend `account_update` or create a new operation to allow changing the custom active permission * Extend `account_update` or create a new operation to allow changing the custom active permission
* Operation-specific authorities (if present) must be evaluated in incoming transactions * Operation-specific authorities (if present) must be evaluated in incoming transactions
* Additional committee parameters may be needed to limit the extend of usage of this feature * Additional committee parameters may be needed to limit the extend of usage of this feature