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

Update bsip-0040.md

bsip53
Stefan Schießl 2018-07-29 00:16:52 +02:00 committed by GitHub
parent 8207e24721
commit e2d902290a
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 10 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
bsip-0040.md
View File

@ -115,7 +115,7 @@ Statefull assert, only `int` type arguments. Analogue to `limit`, but `interval_
#### `contains_only`
Stateless assert, only for dictionary type objects like `options`. The `argument` of the operation is a dictionary type objects and is only allowed to contain the attributes in the data list.
### Simple Example
### Example: Simple transfer
Assume account A and B and some unrelated key K. Furthermore A has a custom active authority in the following way:
```
custom active authority = {
@ -151,6 +151,15 @@ When a signed transaction arrives and before the backend evaluates if all necess
Note:
- A `custom_active_authority` can only grant the `active authority` of the corresponding account, nothing more
### Example: Checking for custom active authorities
Assume Account A, B and C. Now A has two `custom active authorities`:
- `custom active authority 1`: Allow Account B to transfer asset X to D
- `custom active authority 2`: Allow Account C to transfer asset X to D
The incoming transaction now contains `transfer 100 asset X from A to D, signed by all signatures required for active authority of C`. The required accounts (meaning required active authority) for the transaction is Account A. Backend would start considering `custom active authority 1` and check if active authority of account B is present through signatures. It is not, thus continue by checking if authority of `custom active authority 2` is present, which it is. Acive authority of Account A is granted and normal authority checks are continued. Since the required accounts is Account A, and the given accounts is also Account A through `custom active authority 2`, the transaction is executed.
### Modification to the backend
* 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
* 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