Multisig
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 highersecurity, 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.
Address generation
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 security.
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.
Multisig Address
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 index, and 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=2 and security=3 two co-signer’s multisignature, and two security=2 and one security=1 three co-signer’s multisignature.
Validate Multisig
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.
About Author
@abmushi on twitter, Discord
Translated from my original article written in Japanese here
Donation is always welcome and appreciated!
BTC: 1ACGpgpAMgaAKbGpPq2sDa467MnRNdW4wX
IOTA: G9XNCNYYHRKNPKLXFKUSINZ9OIAQGSNGJVODC9TNWQMILXZH9PNHXDGNEUFLEQNNVJUCIWWKZBTJLDXAYOZHZEZSN9
Originally published at gist.github.com.
