Following the reading of our Overview of Multisig and Permissions on EOSIO and Using eosc to Update Your Account’s Authority Structure, you should now be comfortable with altering the authority structure of your account. If you have chosen to leverage the native multisig features for additional security, we must now discuss how to collect the required signatures to satisfy it.
Let’s look at an account that has the following
To satisfy the
active permission, you need to have both of the listed keys sign the transaction. If you hold both of those keys in a single vault file, then there is no need to pass a transaction around: a tool like
eosc will simply craft two signatures in one swift. This, however, doesn’t increase security (other than perception of security). What does increase security is holding those keys in a different place, each secured in a different way.
Let’s review the case where you hold one key and someone else holds the other, and you use the signing feature within
eosc. We first craft the transaction that we’d like to execute:
eosc transfer [ACCOUNT1] [ACCOUNT2] 0.5 --expiration 3600 --skip-sign --write-transaction collect.json
This command is creating a transaction that will transfer 0.5 EOS from
ACCOUNT2, and has an expiration time of 1 hour (3600 seconds). It is instructing the application to not sign the transaction, and just write it into a file named
collect.json, which we will now use to collect the necessary signatures.
We would then pass this file to both of the keyholders and have them sign it using this command:
eosc tx sign collect.json --offline-sign-key [PUBLIC_KEY] --write-transaction collect-signed.json
This will have them each sign with their key into a new file that holds their signature.
By using the
--offline-sign-key flag, and an
eosc-produced transaction, that operation can be done completely offline, further lowering the risks of compromising the keys.
When we inspect the json, part of it will have changed from:
Once we have both signed files, we can just copy and paste a signature from one of the files into the other so that the array contains the necessary signatures:
Since both of the required keys have been used to sign the transaction, we can now push the transaction file to the chain.
eosc tx push collect-signed-both.json
Now let’s look at an account called
msigexample1 that has the following
To satisfy its
active permission, it will need to recoup signatures that satisfy the
active permissions of both the accounts listed. This is what the
eosio.msig contract was designed to help with. You will no longer have to pass around a file that will be signed and joined together. Rather, the signatures can be requested and collected into a temporary row in the
eosio.msig contract table.
In this case, the account
msigexample1 has delegated its
active permission to require the signatures from the
active permission of both
msigexample3. The first step is to craft a transaction file similar to the previous example:
eosc transfer msigexample1 [RECIPIENT] 0.1234 --expiration 3600 --skip-sign --write-transaction msig.json
You would then propose this transaction as an msig, while requesting signatures from both
eosc multisig propose msigexample1 collectsigs msig.json --request msigexample2,msigexample3
Now the two requested accounts would have to approve the msig within the expiration time defined when the transaction was created. They would do this by each using the command:
eosc multisig approve msigexample1 collectsigs [ACCOUNT_NAME]
To review what the requested multisig will execute once signed, you can run the command:
eosc multisig review msigexample1 collectsigs
And if you want to track the signatures as they come in, you can use:
eosc multisig status msigexample1 collectsigs
In the first screenshot, you will see the
Requested approvals listed. Once one of the accounts has signed the proposal, you will see it populating the
Provided approvals section in the second screenshot. Once both signatures have been collected, it is now time to execute the proposal.
Note that even if you had requested signatures from other accounts, you only require enough approvals to satisfy the original transaction’s authorization (in this case for
To execute the msig, it’s as simple as running:
eosc multisig exec msigexample1 collectsigs [ACCOUNT_NAME]
Interestingly, any account is able to call the
exec command on a fully approved msig. The account does not need to be part of the requested permissions.
We’ve now learned to configure and set custom permission structures on an account, and how to use
eosc along with the power of the
eosio.msig contract to satisfy those permissions. In the next article, we will look at nested permissions and how to take advantage of them.