From 6a00164534bc7be75518f6b27822914e6ad04e64 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Stefan=20Schie=C3=9Fl?= Date: Wed, 8 Aug 2018 16:48:25 +0200 Subject: [PATCH] Update bsip-0040.md --- bsip-0040.md | 34 ++++++++++++++++++++++++++++++---- 1 file changed, 30 insertions(+), 4 deletions(-) diff --git a/bsip-0040.md b/bsip-0040.md index 70f2518..9ce13f7 100644 --- a/bsip-0040.md +++ b/bsip-0040.md @@ -46,7 +46,12 @@ This BSIP will be split into three parts that will be voted on separately (see M # 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 @@ -153,10 +158,10 @@ When a signed transaction arrives and before the backend evaluates if all necess - 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 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: -- 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 - 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 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 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 @@ -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. 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. +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`, the transaction is executed.