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

Update bsip-0040.md

Browse source
This commit is contained in:
Stefan Schießl 2018-07-29 00:18:01 +02:00 committed by GitHub
parent e2d902290a
commit fccca20761
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 9 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

12
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.
### Example: Simple transfer
#### 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,14 +151,20 @@ 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
#### 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.
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