Account and Key Security at Algorand Part III: Multisignature Accounts
Part III: Multisignature Account Tutorial
How do I securely create a multisignature account?
In Part I, we described ways to manage keys securely, explained how run a node on an offline machine, and outlined how to recover accounts on different machines. In Part II we showed how to create and transact from a single-key account. Now, we will described how to perform the same operations from a more secure, multisignature account.
Multisignature accounts can be created online or offline, as they do not have secret key mnemonics and do not expose the mnemonics of any of the associated accounts. There are some benefits to generating multisignature accounts online when it comes to generating transactions.
Single-key account creation and multisignature account creation differ in security since single-key accounts have secret key mnemonics, while multisignature accounts do not have secret keys at all, and rely on multiple single-key account mnemonics to sign transactions. This means that it is secure enough to create multisignature accounts online, since there is not potential for secret key exposure. This may be preferable, due to potential issues with importing a multisignature account incorrectly to an offline machine.
To generate multiple keys in step 1 to use for a multisignature account, it is advised for maximum security not to use the same offline machine for each key, and instead to start a new session for each key.
For step 2, refer to Part I to learn about different options to store keys securely.
For step 3, the command to set up a multisignature account with m associated accounts and a threshold of n accounts is
./goal account multisig new <public keys of m accounts> -T <n> -d <path to data directory>
Be sure to remember how you have ordered the public keys, as a different order results in a different multisignature account address.
How do I decide on the threshold for a multisignature account?
A threshold is the minimum number of signatures needed for a transaction to be valid. For example, if I have a multisignature account with 3 associated keys and a threshold of 2, then it is required for two of the three associated accounts to sign a transaction from the multisignature account in order for that transaction to be valid.
The threshold on the multisignature account is dependent on the use. In general, higher thresholds allow to meet higher security at the expense of ease of signing transactions. To keep a single-user account secure without generating so many keys that they become difficult to recover, a threshold of 3/5 may be sufficient. In this case, if an attacker was trying to complete a transaction, they would need to learn 3 sets of keys before being able to complete any transactions from the account. In addition, if the owner of the account loses 2 of the keys, they can still access the account. However, this means that there are now 5 different sets of keys to store and protect for one account, as well as 3 to recover anytime you want to complete a transaction.
Some uses, however, may lend themselves to certain thresholds. For example, if two users share an account and want to be protected in case the other becomes malicious, they may entrust a key to a trusted third-party and have a threshold that allows the trusted party to take action, like 2/3.
How do I securely generate transactions?
For step 4, transactions can be generated both offline or online. In either case, the sending account does not need to be in the wallet to generate a transaction.
To generate a transaction offline, use the command
./goal clerk send -o <name-of-transaction-file.tx> -a <amount> -f <sending account public key> -t <receiving account public key> --firstvalid <round number> --lastvalid <round number> --fee <fee> -d <path to data directory>
During normal operation, while the transaction rate is not higher than the blockchain’s capacity, the minimum fee of 0.001 Algos should be sufficient. Otherwise, you must compete with the market and offer a high enough fee for the transaction to be included in a block.
To check what the current round number is for the firstvalid flag, visit algoexplorer.io. Then, use the average seconds per round to estimate a lastvalid round for a transaction.
To generate a transaction from an online machine, the command is:
./goal clerk send -o <name-of-transaction-file.tx> -a <amount> -f <sending account public key> -t <receiving account public key> -d <path to data directory>
One advantage to online generation has to do with ease of use, since you do not manually have to input the valid rounds and fee. Instead, the node can get that information from the network.
How do I sign a transaction?
Signing should always be done on an offline machine. After generating the transaction, in step 5 save the .tx file to the same storage USB with the installer file on it. Then for step 6, on your offline machine, move that .tx file into your node.
For each signing account, you must import the account into an offline wallet. To import, use the command
./goal account import -m “ <secret key mnemonic> “ -d <path to data directory>
To add a signature to the transaction in step 7, use the command
./goal clerk multisig sign -t <transaction-filename.tx> -a <signing key address> -d <path to data directory>
For step 8, save the signed transaction to the USB. You can replace the original .tx file, or you can name the signed file something else and keep both on the USB. The goal is to eventually have a .tx file with enough signatures to meet the threshold.
For example, if you choose the former option of replacing the file, be sure to continue replacing the .tx files with the accumulating signatures. If you choose the latter, you will have to merge all of the partially-signed .tx files generated from different signing accounts in step 9.
How do I merge the signatures from different machines?
Merging can be done safely both online and offline. If there are multiple signing parties using the transaction file at the same time, it is likely that one machine may have a transaction file with one signature, and another machine may have a transaction file with a different signature. In order to get a transaction file with the signature of both keys, these files must be merged.
First, move all of the partially-signed transaction files onto one machine via USB. Then use the command
./goal clerk multisig merge -o <name-of-merged-file.tx> <partially-signed-file1.tx> <partially-signed-file2.tx>
How do I validate my transaction details before submitting?
Step 10, or verification that the transaction details are correct, should be done on an offline machine, as it is much less likely that the machine itself is compromised.
To check that the transaction has not been compromised before submitting the transaction, use the command
./goal clerk inspect <.tx filename> -d <path to data directory>
You should see the details of the .tx file. If any details are changed, like the amount number or receiving account, do not submit the transaction.
How do I submit a transaction?
Once you have reached step 11 and have the transaction file with enough signatures on it to meet the threshold, move that transaction file onto a USB. Then for step 12, move that fully signed .tx file back onto the online machine. In step 13, the command to submit a transaction is
./goal clerk rawsend -f <transaction-file-with-signatures.tx> -d <path to data directory>
You now have all the necessary information to securely create and operate an account on the Algorand network. If you would like to refer back to the background or single key tutorial, read Part I and Part II.