IOTA: Multisig Explained
Transferring large amount of money, especially the ones that involve exchange level of security, it is worrisome to have only one seed be solely responsible for the transfers. Multisignature is used to send secure transfers by asking for several co-signers.
Even though multisig transfers are created in a way different than that of ordinary individual transfers, when attached to tangle, it appears to be no different, and people cannot distinguish multisig-ly attached transfer(=bundle) from others. Thanks tangle! You are flexible.
Address generation in depth
The most essential idea in creating multisig transfer comes from the very basic of address generation mechanism. Below is instant overview of generating address. Recently explained here.
Address is only the final product that comes from Seed、Private Key、through digests.
Private Key & digest
Seed is arbitrary 81 tryte length string that users freely can choose. But, Private Key is not. It’s just a result of complicated calculation of hashing Seed. Simple experiment that generates different private key with different
security from the same seed is here.
Digest is a next byproduct by hashing private key. Experiments here.
Because long seemingly random string is hard for human to read, below is a figure that visualizes what is happening.
Apparently, the higher
security, the longer length. And by changing
security, only what changed are newly appended next chunk. There exists partial overlap in private key between different security.
Note that every address has 81 tryte length. However, private key and digest are of different length, and length depends on the level of
security. It implies that address is generated by the mechanism, with which any length of digest results in the address of length of 81 trytes. For example, if
security=10,Private Key is
21870(=2187*10) trytes, digest is
810(=81*10)trytes but address is
81 trytes. And importantly, completely different addresses with no partial overlap are randomly produced from different
Multisig makes use of this nature that final address generated is always of length of 81 trytes no matter how long the original digest was.
For instance, let’s say Alice and Bob want to create an account, which both of them are responsible of the balance. They have own unique seed neither of them know the other’s.
First of all, they generate the address called Multisig Address, which looks like a normal address of 81 trytes from any tangle viewers, but is generated in different way. When generating multisig address(of two people in this case), two digests of each Alice’s and Bob’s are used. And for each of them, they can individually choose their own
security level then submit owns digest.
Note that they can share their digests publicly. But, never share seeds as always. Next, concatenate these submitted two digests to get one longer digest. This new digest looks like a digest of
security=5. Then using same method as used in normal address generation, hash the digest to create an address. Remember that final address generated is always of length of 81 trytes no matter how long the original digest was.
This address is Multisig Address. In summary, Two different digests, each of which created from two different seeds, concatenated together is seen as one digest. And they generate address from the digest.
If you concatenate more than two digests, you can generate the address that requires more than two co-signers.
Signing Multisig Address
Assume that we send 100[Gi] (large amount!) to this address. Sending to multisig address is just as same as ordinary sending. The difference is in sending(spending) from multisig address. Spending from any address requires signature. And multisig address literally requires multiple signatures.
Let’s create transfer bundle. In this short example receiver address is “xxx”. And we send 50[Gi] to “xxx”. And this 50[Gi] comes from the multisig address (BID…) with balance(=100[Gi]). And remainder that an address which is used to receive change is not generated automatically in multisig transfer, because to generate next address one needs to have several digests from different people. So, before transfer from multisig address input, make sure that all next digests with next
index of co-signers are ready to create next address. Also, if you no longer need your change to be sent to multisig address, you can also choose any ordinary address.
Multi-Signature is generated from own private key. This procedure is no different from that of normal signing, which is explained in this article. Signed data is generated bundle hash(strictly speaking, normalized bundle hash). Co-signers create signature of same bundle hash.
Now we have co-signers’ signature, two signatures in total. In this example, Alice is
security=2 and Bob is
security=3, so Alice's signature is of
4372 trytes, and
6561 trytes for Bob's. Totally,
10935 (=4372+6561) trytes are stored in five
signatureFragment of transaction objects in the bundle. (five comes from
5 =10935/2187, where each
signatureFragment of one transaction object is 2187 trytes.)
Below is a brief overview of the final bundle.
And an ORDER MATTERS. In this example, digest of Alice comes prior to digest of Bob, so signature in the bundle should follow the order.
The figure above, each signature is colored just for visual friendly purpose. On actual tangle, viewers cannot distinguish
security=5 single signature from
security=3 two co-signer’s multisignature, and two
security=2 and one
security=1 three co-signer’s multisignature.
Validating is easy. On tangle, multisig bundle being attached seems just as same as the one created from single signature. Only differences are the length of the signature part. As seen in single signature, where different
security level creates different length of the signature(
security*2187 Trytes), multisig bundle of, let's say, three people of
security=(3,3,2) can be validated as single signature of
security=8(=3+3+2) bundle when being validated.
@abmushi on twitter, Discord
Translated from my original article written in Japanese here
Donation is always welcome and appreciated!
Originally published at gist.github.com.