Beginning with this post, we are starting a new ARK Core Series that will cover all the new transaction types included in the latest Core v2.6 upgrade. This new Core blog series will go over the details of how these new transactions work, present their use cases and explain their implementation into ARK Core.
First on the list, multisignatures. The basics of how they work, why they are an important part of blockchain solutions and how they can be utilized in ARK.
Multisignature (multisig) refers to requiring more than one key to authorize a transaction. It is generally used to divide up responsibility for possession of coins held in an address. Example: You and 2 others have a startup, with your startup funds in a multisig account. In order for any funds to be transferred out of that account, it would require 2 out of 3 of you to sign any transactions in order for funds to be transferred.
Each multisig wallet in ARK can have as few as 2 participants all the way up to 16, and can at minimum have one co-signer.
ARK is one of the first blockchain projects to incorporate multisig using Schnorr’s multisig scheme. Currently, this topic is quite big in the greater bitcoin community as bitcoin uses ECDSA multisig and there is also a technical BIP written up for bitcoin to use Schnorr as well.
Schnorr signatures solve many problems exposed in ECDSA signatures as they allow aggregation of multiple signatures and their corresponding keys into a single one. This opens up new ways to optimize the signature size and verification speed.
This recent Hackernoon article goes deeper into the difference between ECDSA and Schnorr.
ARK distinguishes between multisig registrations and transactions sent from a multisig wallet. The former is used to create a new multisig wallet and the latter is any other transaction type with multiple signatures from the multisig wallet. Part of a multisig registration includes all participants in the form of their public key and a number to denote the minimum participants that are required to make an outgoing transaction from the multi-signature wallet. This is also called m-n multisig where *n *is the total number of participants and *m a *minimum number of signatures required to create a valid outgoing transaction from the multisig wallet.
**Example: **We create a “3 out of 5” ARK multisig address. The number 5 represents a total number of keys associated with one specific ARK address and the number 3 represents the number of minimum required signatures (signed by at least 3 of those 5 private keys) to send out a transaction from a multisig address. Once 3 signatures are obtained for a specific transaction, the transaction can successfully be verified and broadcasted to the network.
So in short multisig addresses require another participant or participants to sign a transaction before it can be successfully broadcasted and included onto the blockchain.
The primary use of multisig is to increase the difficulty of getting access to coins associated with a specific wallet.
It can also be used for redundancy to protect against loss — with a 2-of-3 address, not only does theft/moving of coins require obtaining 2 different keys, but you can still use the coins if you forget or lose any single key. This allows for more flexible options than just backups. It can also be used for more advanced scenarios such as an address shared by multiple people, where a majority vote is required to use the funds (escrow, company funds, …).
Let’s go over a few use cases and real-life scenarios of different multisig setups we can run (m = minimum number of cosigners, n = total number of cosigners):
When m is 1, and n is more than 1 (eg. 1 out of 3 signatures needed). This is the least secure multi-signature setup you can make (any individual of this multisig can put at risk the entire multisig as this isn’t a multifactor wallet as only one signee is required), but it still has some use cases. **Examples would include a group of friends creating a multisig wallet for going out or on vacation, as well as family members sharing some spending wallet where they all have access to it. This can be very convenient, but as said it is the riskiest setup anyone can have. One of the benefits of this setup is that as long as one of the participants holds their key all others can be lost and funds could still be recovered or spent.
**When m equals n **(eg. 2 out of 2 signatures needed). This setup is a hardcore multifactor as it requires all of the signers to successfully sign a transaction, as no keys can be lost. With a 2-of-2 address, you can keep the two keys on totally separate machines/locations and as such, theft will require compromising both private keys, which is a much more difficult task than getting your hands on just one of the private keys. As the number of total signatures required increases, the risk of losing or being locked out due to lost keys also increases. Without all of signatures funds are lost/locked forever.
When m is less than half of n (eg. 3 out of 7 signatures needed). This is a more convenient multisig wallet. For example, a joint fund where at least three members need to sign a transaction in order for it to be successful. With the increase in the number of total signees, we increase the risk of colluding. The fallout for the colluding minority needs to be greater than the possible benefits.
When m is more than half of n (eg. 2 out of 3 signatures needed). This is a standard example of the multifactor signature wallet, where one compromised party doesn’t compromise the access to funds. A single key can be lost or stolen and the funds can still be recovered without it. A simple example would be an escrow account, where two parties make a deal while having a third party act as an escrow if both agree to terms deal can go through normally, but in case there is a dispute between escrow can be a decisive factor. The balance of influence with this setup can be altered by having one-party control more keys than the other parties. If one party controls multiple keys, there is a greater risk of those keys not remaining as multiple factors.
When m is half of the number n (eg. 3 out of 6 signatures needed). This is a great use case for a personal family savings account, where one person holds 3 keys and 3 other people hold 1 key each. This allows for the primary person to control their own money, but the funds could still be recoverable, even if the primary key holder were to disappear with all 3 of his keys (this does pose a problem if person is compromised and all 3 of his keys are stolen, an attacker could obtain all of the funds without any interaction of the other 3 people). This is a great way for an inheritance account set up in a case where the primary owner would die, the other group of 3 could still recover the funds.
Multisigs in ARK Core are a part of the AIP 18 proposal, where we implemented the so-called Schnorr’s Multisignature scheme. All multisig transactions in ARK require Schnorr signatures (it is not possible to sign them using the ECSDA algorithm).
One of the obvious improvements over ECSDA is that each Schnorr signature is guaranteed to be 64 bytes, and an extra byte is allocated to store the corresponding participant index making each signature of a multisig transaction (signatures field) 65 bytes long. (ECSDA can vary and can be from 70–72 bytes).
The theoretical maximum number of participants in any multisig wallet is 255, but in ARK it will be initially capped to 16. This should cover even the most robust multisig setups.
The registration fee of a multisig wallet is 5 ARK per participant. For example, to register a 3 out of 5 multisig wallet (meaning 5 participants) the fee is 25 ARK. Following registration, the wallet transaction fees are similar to any standard wallet.
At the moment it is not possible to upgrade (add or remove participants) or resign a multisig wallet after registration. Technically this is possible, but will not be available in the initial version of our multisig scheme.
Now for some technically savvy people - let's create a very simplified example to show the process of creating and signing a multisig registration.
Creating a 2–3 multisig wallet
BuilderFactory.multiSignature()
.senderPublicKey(“someSenderPublicKey”)
.participant(publicKey1)
.participant(publicKey2)
.participant(publicKey3)
.min(2)
//Second parameter is the index which matches the participants //public key from above. The first byte of each multisignature is
//mapped to a participant.
//The normal signature still needs to be from the sender of
//the registration which can be anyone the participants agreed on.
.multiSign(“participantSecret1”, 0)
.multiSign(“participantSecret2”, 1)
.multiSign(“participantSecret3”, 2)
.sign(“someSenderPassphrase”)
.build()
.toJson();
The public key/address of a multisig wallet is derived from the asset of the multisig registration. Namely, the participants and min.
Example payload of a multisig registration:
{
“version”: 2,
“network”: 23,
“type”: 4,
“nonce”: “1”,
“senderPublicKey”: “0318fcac6cd16617340ce11fb7f33c2fb9861dfff8dc5304a7a55b6672154b7cf1”,
“fee”: “2000000000”,
“amount”: “0”,
“asset”: {
“multiSignature”: {
“publicKeys”: [
“037eaa8cb236c40a08fcb9d6220743ee6ae1b5c40e8a77a38f286516c3ff663901”,
“0301fd417566397113ba8c55de2f093a572744ed1829b37b56a129058000ef7bce”,
“0209d3c0f68994253cee24b23df3266ba1f0ca2f0666cd69a46544d63001cdf150”],
“min”: 2
}
},
“signature”: “e97f7fe7e54fe1bc55a3a15b342f20f849173f17416113362d5217826abd2bb034b5a07a4baf61488b019d7d7178041b5692b412da5b7abe7c15638438b8261c”,
“signatures”: [
“009157e3b2a02678067009b444f1136e6b095b65a7f7147b1dac872a06846efd2f9aaf6ed5bc5319b114b139e176361ac70c21dfb10177accb0a8b1651993adeae”,
“015633f9cfe50969cdeb389450fb1c2a70d55e30717436b6072a6b7e9342a108b7b4392ad61cdd73c252a06401658385b9c3f61e546a8a2fd7f2937b4507f27989”,
“028ff0e70b2d7a98b5b8382b0a635efa54ca9d5a7ec720ec891de57670dad8342c51fef2fcabcfac5d10a80647816d3b980d342e455295e21175575567d7e52f78”
],
“id”: “7baf46c7843d054ce457f70eb7064a60ca96eddfdd4a38d9c7dbdcccfb756b87”
}
Making a multisig transfer
In the following simplified example we demonstrate how to make a multisig transfer after having created a multisig wallet in the previous example:
// The interface definition of the multisignature asset.
export interface IMultiSignatureAsset {
min: number;
publicKeys: string[];
}
// Get multisignature wallet public key using the same asset of the previous registration:
const publicKey: string = Identities.PublicKey.fromMultiSignatureAsset({
publicKeys: [publicKey1, publicKey2, publicKey3],
min: 2
});
// Creating multisignature transfer with only 2 out of 3 signees.
BuilderFactory.transfer()
.senderPublicKey(publicKey)
.multiSign(“participantSecret1”, 0)
.multiSign(“participantSecret2”, 1)
.build()
.toJson();
Example payload of a multisig transfer:
{
“version”: 2,
“network”: 23,
“type”: 0,
“nonce”: “1”,
“senderPublicKey”: “03e8d4175126a39ed7ba803f31705b6f5fb78cbf46455ba778c5f39a32c6adfbd9”,
“fee”: “10000000”,
“amount”: “1”,
“expiration”: 0,
“recipientId”: “AGM9gtzYeVTVqgwnW2mgs3GqEeQhstuLQf”,
“signatures”: [
“00ed89125634a3b207d342c4884c2bda246990a6dfb6ee562ce1dab27b5fa0647bae2726e57835dab0f1844c4f9fe0e85efe38ae98db7497e607e3b2160a1acbf6”,
“01e8faebd5d1c496612cbbf7825432c4384c54a532e3b66b5da776c2e789a936a00c1491e6381506a9bed9bbe00216f2ed56c4c927b23cc495d19488b5b8a26bd2”,
“02c0167e06222e429d2b13e6130823790396c349f4fff8dd8e8ccce1ef1226893fc3e011abf6e88175991d7df1eabc4ec45f3339ad9ae3548b45e40c1e40c02c73”
],
“id”: “080bb3e3a6d0821a51a7d93c6b32d9b492a2735b5e8da6534fe408cbf9ec18cc”
}
However, in practice this does not really work since the passphrase of each participant is supposed to not be revealed. A bit more sophisticated setup is required to create and sign a multisig transaction. Therefore, we created a Multisig Server CLI that collects signatures of participants and pieces them together into a valid multisig transaction.
The repository will be open source and will become public and available the day after this blog post is published (along with a new blog post).
We have prepared a simple **Core TX Tester script**, where you can start experimenting and playing with multisigs on our Devnet.
But as said, we have also developed a Multisig Server CLI which will allow verifying, storing and obtaining multisig signatures from a specific server and will be used in the Desktop Wallet for better user experience. More info about the Multisig Server will be pushed in the blog post that immediately accompanies this one — stay tuned!
Read our new whitepaper, follow us on social media ( Twitter|Facebook|Reddit ), join our community ( Slack | Discord ) and stay tuned to our blog on Medium and on Steemit.