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

add economics

Browse source
This commit is contained in:
Stefan Schießl 2018-07-29 15:39:59 +02:00 committed by GitHub
parent ab5500dfda
commit 0e8e9ad705
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 8 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

10
bsip-0040.md
View file

@ -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