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

add enabled flag

Browse source
This commit is contained in:
Stefan Schießl 2018-08-02 21:55:41 +02:00 committed by GitHub
parent 8893727844
commit 5d92967586
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 6 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

7
bsip-0040.md
View file

@ -26,7 +26,7 @@ Any successfull hacking or phishing attempt on any of the web wallets that are p
BitShares Blockchain is bad publicity. The user needs to be educated in account security, and this BSIP BitShares Blockchain is bad publicity. The user needs to be educated in account security, and this BSIP
aims to ensure all technical possibilities are met while being flexible to allow many use-cases. aims to ensure all technical possibilities are met while being flexible to allow many use-cases.
With this BSIP any user can create keys with specific purpose (everything else is prohibited). We list some possibilities below: With this BSIP any user can create additional keys with specific purpose (everything else is prohibited). We list some possibilities below:
- Witness Key: Only allows update signing key and publish price feed - Witness Key: Only allows update signing key and publish price feed
- Trading Key: Only allows limit orders (arguments restricted to desired markets), update margin position and transfers (arguments restricted to certain accounts) - Trading Key: Only allows limit orders (arguments restricted to desired markets), update margin position and transfers (arguments restricted to certain accounts)
- Proposal Update Key: Approve proposals (2FA comes to mind) - Proposal Update Key: Approve proposals (2FA comes to mind)
@ -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.
Note: The user can still use the active authority just like used to, no change in existing behavior. The named keys only give an additional possibility. For example: The user can login the UI using the private key of such a named key. Then he only as access to the operations that this named key grants. He can still login with the existing password to gain full access (similar a local wallet can be created that only contains the named key).
This BSIP will be split into three parts that will be voted on separately (see Milestones section). All of the above keys are possible with Milestone 1. Milestone 2 allows stateful 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. This BSIP will be split into three parts that will be voted on separately (see Milestones section). All of the above keys are possible with Milestone 1. Milestone 2 allows stateful 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
@ -56,6 +58,7 @@ custom_active_permission = {
authorities = list of custom_active_authority objects authorities = list of custom_active_authority objects
} }
custom_active_authority = { custom_active_authority = {
enabled, // status of this authority, true or false. true when created
valid_from, // timestamp when this is active valid_from, // timestamp when this is active
valid_to, // timestamp when this is invalid valid_to, // timestamp when this is invalid
operation_id, // operation id of the target operation, operation_id, // operation id of the target operation,
@ -162,7 +165,7 @@ Normal accounts can only create custom active authoritites with a duration of ma
### Modification to the backend ### Modification to the backend
* Add a new index or extend the account object to store custom active permission are assigned to an account and contain a list of custom active authorities. Multiple custom active authority entries are possible for one operation * Add a new index or extend the account object to store custom active permission are assigned to an account and contain a list of custom active authorities. Multiple custom active authority entries are possible for one operation
* If the active authority of the account is updated, all custom active authorities need to be confirmed in the update. Every unconfirmed one is deleted otherwise * If the active authority of the account is updated, all custom active authorities are disabled and must be enabled again with using `update_custom_active_authority`
* Provide operations: `install_custom_active_authority`, `update_custom_active_authority`, `delete_custom_active_authority` to allow changing the custom active permission (3 operation to allow custom transaction fees and avoid having to send the complete list of all authorities for every update) * Provide operations: `install_custom_active_authority`, `update_custom_active_authority`, `delete_custom_active_authority` to allow changing the custom active permission (3 operation to allow custom transaction fees and avoid having to send the complete list of all authorities for every update)
* Operation-specific authorities (if present) must be evaluated in incoming transactions * Operation-specific authorities (if present) must be evaluated in incoming transactions
* Remove expired custom_active_authorities on maintenance * Remove expired custom_active_authorities on maintenance