Multi-signature accounts
techcoderx opened this issue · comments
Currently, all Avalon transactions are signed with only one private key, which makes it impossible to split account authorities across multiple keys potentially owned by different people.
We can add the ability to turn an account into a multisig account where a threshold is assigned to each transaction type, plus a default threshold if not defined. Each public key can have a weight assigned, which can be custom or master keys. Transactions signed by multisig accounts will contain more than one signatures in an array (containing signature data and secp256k1 signature recovery id), instead of a plain string.
This is a must :) And clearly needed.
Specially master account should probably be a multi-sig account. Let's try it out on the testnet as we were discussing.
Along with this idea, which I agree with, we should have a way to declare any account as a managed account, meaning that we could have tx approved by a set of the elected leaders, instead of individual keys of the account.
I suggest that the account master key could be set to a special key, like "111111111..." so that it is impossible to use it to sign txs, and then transactions thresholds would apply to each tx type, defining how many leaders are enough to approve it.
This enables the creation of accounts that hold funds, for development for instance, that would move funds for development works when approved by enough leaders, or even control accounts like @dtube.verified that allow any leader to follow any user that submitted the verification video in @tibfox terms, so that any UI could just get the verified users list from that account followings. These are just two ideas for managed accounts, many more exist... :)
In order to facilitate multi-signature tx management, I also suggest that we could implement a proposed txs pool, that any user can use to propose txs for other users to sign, and when there are enough signatures any user can execute them. This requires a few conditions to avoid spam and to prevent growing this pool unlimited, so each tx should expire after a set time and proposing or executing should decrease bandwidth of the user. This way a UI could be built to allow governance tasks to be performed asynchronously by each leader, possibly showing a brief tx title and description to complement each tx to be approved. This would enable a new level of governance in dtube.