Update bsip-0040.md
This commit is contained in:
parent
7a13f4de7c
commit
aed7556df5
1 changed files with 4 additions and 2 deletions
|
@ -20,7 +20,7 @@ permission contains a list of operationid-to-authority mappings that each grant
|
|||
operation as if it were the active permission of the account. Additionally, the arguments of said operation
|
||||
can be restricted.
|
||||
|
||||
# Motivation and Rational
|
||||
# Motivation
|
||||
|
||||
Any successfull hacking or phishing attempt on any of the web wallets that are powered by the
|
||||
BitShares Blockchain is bad publicity. The user needs to be educated in account security, and this BSIP
|
||||
|
@ -34,7 +34,7 @@ Examples:
|
|||
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.
|
||||
|
||||
# Specifications
|
||||
# Rational
|
||||
|
||||
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 authorities` contains an `operation_id`, an `authority` (just like with active permission) and a list of `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.
|
||||
|
@ -52,6 +52,8 @@ custom active authority = {
|
|||
```
|
||||
That has the consquence now that a a transfer transaction sending funds away from A can be signed with key K as long as the receiver is B.
|
||||
|
||||
# Specifications
|
||||
|
||||
# Discussion
|
||||
|
||||
To be found in the [issue](https://github.com/bitshares/bitshares-core/issues/1061).
|
||||
|
|
Loading…
Reference in a new issue