From 0e8e9ad705e2fe3663e656ebf29194cbe4ba3d92 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Stefan=20Schie=C3=9Fl?= Date: Sun, 29 Jul 2018 15:39:59 +0200 Subject: [PATCH] add economics --- bsip-0040.md | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/bsip-0040.md b/bsip-0040.md index 4ef2eb0..31e8885 100644 --- a/bsip-0040.md +++ b/bsip-0040.md @@ -52,7 +52,7 @@ A `custom_active_permission` looks like follows (in JSON-like/pseudo for clarifi custom_active_permission = list of custom_active_authority items custom_active_authority = { valid_from, // timestamp when this is active, defaults to now - valid_to, // timestamp when this is invalid, defaults to 1 month + valid_to, // timestamp when this is invalid, defaults to 1 year operationid, // operationid of the target operation, authority, // same as for the existing authortities (multisig with weighted accounts or keys), asserts // see below @@ -144,6 +144,12 @@ That has the consquence now that a transfer transaction sending funds away from Note: This is just an illustration of a possible serialization, not a specification of the serialized format. +### Economics + +Adding a custom active authority means increased effort for the backend, and with a stateful one also the need for more storage. +We propose that the transaction fee for the creation is tied to the duration of the custom active authority. +Furthermore, normal accounts can only create custom active authoritites with a duration of maximum 1 year. LTM can do any duration and also unlimited, but the transaction fee is capped at duration of 2 years. + ### Outline of handling incoming transactions When a signed transaction arrives and before the backend evaluates if all necessary authorities are present through the signatures, do the following: @@ -180,7 +186,7 @@ the transaction is executed. Notes: The implementation must not differentiate on which operation the custom active authority is applied, all operations are treated in same fashion # Milestones -We propose do split the implmentation into two milestones: +We propose do split the implmentation into two milestones. Each milestone will be voted on as a separate BSIP: 1. Implementation of basic functionaliy to allow custom active permissions and authorities, including `any`, `none` and `lt, le, gt, ge` and `attribute_assert` `asserts`. If deemed necessary by developpers, reduce to only allow one key or one account for every `custom active authority` 2. Evaluation of stateful asserts `limit` and `limit_monthly` in terms of performance. If positively evaluated, implement