This document is intended to provide a high-level overview of multi-signatures in IOTA. More specifically, this will provide a description of how multi-signatures work and most importantly, do's and don'ts that you have to follow in order to not lose access to your tokens while using multi-signatures.
The official Wikipedia page tells us that "Multisignature (multi-signature) is a digital signature scheme which allows a group of users to sign a single document.". What this basically means is that you can have a group of people (often referred to as "co-signers") which have to formally agree in order to spend money from a wallet. As such, if you are part of a multi-signature, the only way for you to successfully spend tokens is if the signature of the other co-signers is provided as well.
There are various ways to use multi-signatures: You can have N-of-N schemes (meaning that all co-signers need to sign for a transfer to be successful), or you can have M-of-N (meaning that only a subset of all co-signers needs to provide their signatures in order to make a transaction). This makes multi-signature a perfect solution to hold tokens in a trustless and secure manner. Exchanges, wallets, and individuals are encouraged to use multi-signatures to secure their holdings.
IOTA uses Curl, which is a trinary cryptographic hash function. Coming from other Blockchain projects, IOTA has similar principles and advantages / disadvantages when it comes to multi-signatures. Multi-signatures and their validation are supported by the core clients by default. To actually utilize multi-signatures, you need to use the provided client-side libraries.
At the time of writing (first week of January 2017), the Javascript library has implemented and made available multi-signature. Please go to the official documentation to find out how to use them in your environment.
Generating a multi-sig address involves a simple generation process, where each of the co-signers adds their key digest in an agreed upon order. Adding each individual key digest basically modifies the Curl state trits. Once the last co-signer has added their digest, these Curl state trits can be converted into trytes - which is the new multi-signature address.
In order to ensure that the multi-signature address was correctly constructed, and in order to provide independent validation, the co-signers in the multi-signature can safely share their key digests with each other. This means that each co-signer can independently regenerate the multi-sig address and ensure that it's correct. Sharing the digests is presumed to be safe, as it's not possible to derive the private key from it.
Spending of inputs includes the signing of the transfers bundle with the private keys of each co-signer. The signing has to be done in the exact same order as was followed when generating the multi-signature address. Each co-signer has 2 bundle entries reserved for their signature, assuming 162 trit (~256 bit) security was used, as is the current standard.
When spending inputs, it's important to keep in mind what happens with the remainder. As is currently the case, if there is a remainder, the co-signers need to define a new multi-signature address to which the remainder balance gets sent to. This means that this new multi-signature address needs to be generated before making a transaction.
Example Bundle
Lets say that we have a multi-signature between 3 parties in the following signing order: Alice, Bob and Carol
| Index | Purpose | Balance |
|---|---|---|
| 0 | Output of bundle. Defines where the tokens are of the input are sent to. | >0 (as defined) |
| 1 | First bundle entry that spends the entirety of the multi-sig input. This bundle entry also contains the first part of the multi-signature (in the example case, it'll be the first half of Alice's signature) | < 0 (spending of input) |
| 2 | Second half of Alice's signature | 0 |
| 3 | First half of Bob's signature | 0 |
| 4 | Second half of Bob's signature | 0 |
| 5 | First half of Carol's signature | 0 |
| 6 | Second half of Carol's signature | 0 |
| 7 | New multi-signature address, as was generated by Alice, Bob and Carol | >0 (input - output) |
The collective of these signatures (Alice's, Bob's and Carol's signature), create the full multi-signature that is necessary for spending the input.
One of the key differences between IOTA multi-signatures is that M-of-N (e.g. 3 of 5) works differently. What this means is that in order to successfully spend inputs, all of the co-signers have to sign the transaction. As such, in order to enable M-of-N we have to make use of a simple trick: sharing of private keys.
This concept is best explained with a concrete example:
Lets say that we have a multi-signature between 3 parties: Alice, Bob and Carol. Each has their own private key, and they generated a new multi-signature address in the aforementioned order. Currently, this is a 3 of 3 multisig. This means that all 3 participants (Alice, Bob and Carol) need to sign the inputs with their private keys in order to successfully spend them.
In order to enable a 2 of 3 multisig, the cosigners need to share their private keys with the other parties in such a way that no single party can sign inputs alone, but that still enables an M-of-N multsig. In our example, the sharing of the private keys would look as follows:
Alice -> Bob
Bob -> Carol
Carol -> Alice
Now, each participant holds two private keys that he/she can use to collude with another party to successfully sign the inputs and make a transaction. But no single party holds enough keys (3 of 3) to be able to independently make the transaction.
Multi-signatures need to be utilized with care, else you can end up in a situation where you are no longer able to successfully generate the signatures, and thus spend your inputs.
When creating a multi-signature address and when signing a transaction for that address, it is important to follow the exact order that was used during the initial creation. If we have a multi-signature address that was signed in the following order: Alice -> Bob -> Carol. You will not be able to spend these inputs if you provide the signatures in a different order (e.g. Bob -> Alice -> Carol). As such, keep the signing order in mind.
Probably the most important rule to keep in mind: absolutely never re-use private keys. IOTA uses one-time Winternitz signatures, which means that if you re-use private keys you significantly decrease the security of your private keys, up to the point where signing of another transaction can be done on a conventional computer within few days. Therefore, when generating a new multi-signature with your co-signers, always increase the private key index counter and only use a single private key once. Don't use it for any other multi-signatures and don't use it for any personal transactions.
Under no circumstances - other than wanting to reduce the requirements for a multi-signature (see section How M-of-N works) - should you share your private keys. Sharing your private keys with others means that they can sign your part of the multi-signature successfully.