In this video series different topics will be explained which will help you to understand IOTA. It is recommended to watch each video sequentially as I may refer to certain IOTA topics explained earlier.
The main objective of this video is to explain what the purpose is of multisignatures and how to use IOTA multisignatures.
Then follow us on Google News!
Multisignature (multisig) refers to requiring multiple signatures to authorise a transaction. There are two types of multisignature schemes: N-of-N scheme: All co-signers (N) needs to provide their signatures in order for a transfer to be successful. M-of-N scheme: M co-signers of a total of N co-signers needs to provide their signatures in order for a transfer to be successful.
In this tutorial lets assume Alice is the notary, Bob and Charlie are business companions buying an office space worth 2 IOTAs. Alice uses a 3-of-3 scheme, which means 3 signatures (Alice, Bob and Charlie) are required for a successful transaction. Alice is the organiser and will handle the multisignature process.
- For educational purpose you can use the Multisig Wallet: https://www.mobilefish.com/services/c…
Alice, Bob and Charlie each creates a digest using their seed and an unused key index. They can all use a different security level. The sum of the security levels (sumSecurityLevels) = 2 + 1 + 3 = 6 https://www.mobilefish.com/download/i…
Bob and Charlie can safely send their digest to Alice because Alice can not reconstruct their private keys using their digests. Alice, in her role as organiser, uses all three digests (3-of-3 scheme) to create a multisignature address.
The digest order is very important! See digestArr. Later, when the bundle needs to be signed the same order must be used. In this example the order is: Alice, Bob and Charlie. There is no difference between a multisignature address and an ordinary address. The size of a multisignature address and an ordinary address are both 81 trytes or 90 trytes with checksum.
Alice has created the multisig address and sends this address to Bob and Charlie. Bob and Charlie can now each deposit 1 IOTA to this multisig address. Alice verifies if the multisig address contains 2 IOTAs. After the verification Alice creates an initial bundle (initialBundle). In this particular example, the complete amount in the multisig address will be sent to the recipient address which means no remainder address is needed.
The initial bundle can now be signed. The signing order (Alice, Bob and last Charlie ) is the same as the digest array order. First Alice adds her signature to the initial bundle. The modified bundle is now called firstSignedBundle. Alice sends the firstSignedBundle to Bob and he adds his signature to the bundle. The modified bundle is called secondSignedBundle. Bob sends the secondSignedBundle to Alice. Alice checks if the relevant signatureMessageFragment fields are modified. Alice sends the secondSignedBundle to Charlie and he adds his signature to the bundle. The modified bundle is called thirdSignedBundle. Charlie sends the thirdSignedBundle to Alice. Alice checks if the relevant signatureMessageFragment fields are modified. The thirdSignedBundle is the final bundle and Alice sends this bundle to the Tangle.
What if Alice decided to use a 2-of-3 signature scheme? You always need the signatures of ALL participants in the scheme. This means, according to the documentation https://github.com/iotaledger/wiki/bl… an M-of-N scheme can be setup by sharing private keys.
So, if Alice wants to use of 2-of-3 scheme: Alice gives her private key to Bob (A-B). Bob gives his private key to Charlie (B-C). Charlie gives his private key to Alice (C-A). This means in a 2-of-3 scheme, 2 participants will have all the necessary signatures in order for a transfer to be successful.
When setting up an M-of-N scheme keep an eye on the following: The whole process must be transparent to ALL its participants, meaning each participant must receive and understand the complete M-of-N private key sharing scheme. Sending the private key to participants must happen securely. Users must share their private key with only the assigned participant(s) and no one else.