Update bsip-0040.md

This commit is contained in:
Stefan Schießl 2018-08-08 16:48:25 +02:00 committed by GitHub
parent 552b5c4bfa
commit 6a00164534
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23

View file

@ -46,7 +46,12 @@ This BSIP will be split into three parts that will be voted on separately (see M
# Rational # Rational
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 `restrictions` than can be used to restrict arguments and is only valid a certain time period (`valid_from` and `valid_to`). When handling incoming signed transactions, the backend checks for each operation if there is a `custom active authority` for any of its required accounts. Check for every required account of the transaction if all its belonging operations have at least one positively matched `custom active authority` (match means its `authority` is granted through present signatures, same `operation_id`, now is within `valid_to` and `valid_from` and none of the `restrictions` is violated), and if so grant the active authority of the corresponding account. 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 `restrictions` than can be used to restrict arguments and is only
valid a certain time period (`valid_from` and `valid_to`). When handling incoming signed transactions, the backend checks
for each operation if there is a `custom active authority` for any of its required accounts. Check for every required
account of the transaction if all its belonging operations have at least one positively matched `custom active authority`
(see Specifications for definition of "matching"), and if so behave as if the active authority of the corresponding account is present (recursive authorities are excluded, see Examples).
# Specification # Specification
@ -153,10 +158,10 @@ When a signed transaction arrives and before the backend evaluates if all necess
- iterate over `required accounts` - iterate over `required accounts`
- iterate over all `operations` (child operations of proposal are not included) within the transactions that require the active authority of this account - iterate over all `operations` (child operations of proposal are not included) within the transactions that require the active authority of this account
- iterate the `custom_active_authorities` of this account, and if it matches, remember that and continue with next `operation` - iterate the `custom_active_authorities` of this account, and if it matches, remember that and continue with next `operation`
- if a `custom active authority` match was found for every operation in the loop, grant the `active authority` of this account - if a `custom active authority` match was found for every operation in the loop, behave as if the `active authority` of this account is present for the correspoding operations
Note: Note:
- A `custom_active_authority` can only grant the `active authority` of the corresponding account, nothing more - A `custom_active_authority` can only grant the `active authority` of the corresponding account for the matching operation, nothing more
- The actual active authority of a required account can still be given as before, existing behavior is not to be changed - The actual active authority of a required account can still be given as before, existing behavior is not to be changed
- This for illustration, not actual implementation instructions - This for illustration, not actual implementation instructions
@ -237,6 +242,27 @@ The transaction contains a transfer from A to account D. Required active authori
- Signed by L and C: Denied. The custom active authority of B does not match, only applies for transfers with B as sender - Signed by L and C: Denied. The custom active authority of B does not match, only applies for transfers with B as sender
- Signed by K: Accepted, basically bypassing multisig. This is intended, as the multisig needs to approve the installment of the custom active authority in the first place - Signed by K: Accepted, basically bypassing multisig. This is intended, as the multisig needs to approve the installment of the custom active authority in the first place
#### Recursive active authority
Suppose Alice has a custom active authority with key K for transfers to Charlie. Bob has Alice as his active authority account. Suppose a transaction containing two operations
1. transfer 1 BTS from Alice to Charlie
2. transfer 1000 BTS from Bob to some other account
Cases:
- Transaction is signed by K
- Operation 1. requires Alice as active authority, and there is a matching custom active authority, thus this operation would be allowed to execute
- Operation 2. requires Bob as active authority. Even though Bob has Alice as active authority, K can NOT grant recursively the active authority of Bob
- The whole transaction is denied
- Transaction is signed by K and A
- Operation 1. requires Alice as active authority and is also directly present, is allowed
- Operation 2. requires Bob as active authority, which is indirectly present through A, execution is allowed (existing logic)
- The whole transaction is denied because too many signatures are present (existing logic)
- Transaction is signed by K and B
- Operation 1. requires Alice as active authority, and there is a matching custom active authority, thus this operation would be allowed to execute
- Operation 2. requires Bob as active authority and is also directly present, is allowed
- Transaction may execute
#### Example: Either or #### Example: Either or
Assume account A, B and C and asset X and asset Y. The custom active authority should now achieve Assume account A, B and C and asset X and asset Y. The custom active authority should now achieve
that a transfer transaction sending funds away from A can be signed with with active authority of account B if that a transfer transaction sending funds away from A can be signed with with active authority of account B if
@ -326,7 +352,7 @@ The incoming transaction now contains `transfer 100 asset X from A to D, signed
The required accounts (meaning required active authority) for the transaction is Account A. 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. 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. 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. Behave as if active authority of Account A is present for the matched operation and continue with normal authority checks.
Since the required accounts is Account A, and the given accounts is also Account A through `custom active authority 2`, 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 transaction is executed.