We open the cycle of publications about the device of various blockchains and begin research with Monero. This is a fairly well-known cryptocurrency, it implements a number of interesting algorithmic and cryptographic solutions. A few months ago, support for multi-signatures was added to Monero Core, and in today's article we will look at this technology in detail.
Multi-signatures are a mechanism for creating and using public access wallets. The concept itself is not new, it has already been implemented in some cryptocurrencies, such as Bitcoin, Ethereum and others. Its essence lies in the joint possession and disposal of the funds of the wallet. There are some restrictions on the disposal of funds: to conduct a transaction, you must collect a certain number of votes, which is set when the wallet is created and depends on the number of its owners.
These parameters characterize the so-called "scheme" of the wallet, for example, 3/3 - a wallet for three owners with the necessary three signatures to send a transaction, or 2/3 - a wallet for three owners with the necessary two signatures of any of its owners. It should be noted that in the multisignature wallet there is no concept of "your share" and "my share", all funds belong to all participants simultaneously.
Cryptography in Monero
Cryptography in Monero (as in most other cryptocurrencies) is built on elliptic curves. You can read about them
on Wikipedia . In short, the advantages of this encryption system are higher cryptographic strength compared to classical cryptographic systems, small key sizes and higher speed of cryptographic operations.
Each wallet in the monero network has two pairs of (private and public) keys - view and spend. A pair of public keys view and spend is called the wallet address. You can use it as an address for receiving funds. If you want to provide information on the number and amount of receipts to your wallet to third parties, you can, in addition to the address, provide a private view key as well. A pair of private view key and public spend is called a tracking key. With it, you can see the receipt of funds on the wallet (but not expenses) and it is absolutely safe - owning such a pair of keys will not be able to spend your money.
Perhaps the most secret key is private spend - they can not be shared with anyone, because owning it and a private view key, you can dispose of the funds of the wallet.
Further in the article, we will denote public keys in capital letters (for example, B - public spend key), and private - lower case (b - private spend key). To understand some of the calculations below, we show in the article how the public key is inherited from a private key:
where
G is a fixed point, when multiplying a private key (scalar), it produces a public key, which is also a point on an elliptic curve.
Multi signatures on the Monero network
The idea behind the technology is simple: each participant in the wallet stores only part of the private spend key, and when generating and signing transactions, all these parts are summed up to form a single key.
Of course, at no point in time can any one of the participants collect the entire key entirely. The public spend key is kept entirely with each participant. Also, each of the participants stores the full version of the private and public key view, which, together with the public spend-it, allows you to see incoming receipts to the common address.
Creating a multisig wallet in Monero
The current release version of Monero only supports N / N and N - 1 / N schemes.
The creation process takes place in 1 or 2 stages for the N / N and N - 1 / N schemes, respectively. At the first stage, participants in the process exchange with each other private view and public spend keys and calculate the amounts of these keys - all view and all spend. Thus, the sum of the view keys for all schemes becomes the private view key of the wallet, and the public spend key for the N / N scheme is the amount of public spend keys of all participants. This is where the N / N generation of the wallet ends.
For N - 1 / N wallets, another set of keys appears. This set is an array of private keys, calculated as the product of its current private spend key for each of the other participants' public spend keys, that is (without taking into account the hashing function for simplicity):
And similarly for each of the participants.
The private spend key of each participant will be the sum of its multisig keys, that is:
Each participant performs this operation. It should be noted one important property of such works, for example:
From this equality, it follows that each wallet has one (in our example with a 2/3 scheme) multisig key that another participant has.
After generation, participants exchange public multisig keys:
In the final, the public spend key of the wallet is calculated by summing the unique values of the public multisig keys, that is, for our example, this would be:
As we see, to calculate the spend key (both private and public) in the case of 2/3, we need information from any two participants.
This completes the creation of the wallet, and it can be used in accordance with the selected scheme.
Transactions in Monero
To explain how multisig transactions are created, let's briefly look at how a Monero transaction works. Simply (without ring signatures and RingCT) you can imagine it like this:
Figure 1. Simplified transaction view
Here, on the right, the transaction outputs are shown - the money that it generates (direct analogy: the bills in the wallet), and on the left, the inputs - the money that it burns.
Thus, when Alice wants to send 1 XMR to Bob, she dials a total of 1 XMR plus commission among her unspent outputs, puts them in place of the transaction inputs, calculates a key image for each of them, generates 1 XMR outputs and calculates for each of these output key.
After receiving the transaction, Bob for each of the outputs restores the output key using a private view and public spend keys, and if the keys recovered and received in the transaction match, consider this output intended for him.
Despite the fact that multisig-transaction is no different from any other transaction from the point of view of the network, its creation is a bit more complicated and in several stages:
- Participants exchange partial key images for known exits (or simply exchanging exits)
- Participants resynchronize their wallets in order to get the exact balance with the full key image
- The sender prepares the transaction, signs it and sends it to the next participant.
- Each subsequent member adds their own part of the RingCT signature
- Last signer completes RingCT creation
And now the transaction is ready to be sent to the network.
Generating key image and sharing outputs
During the blockchain scan (synchronization), the wallet cannot determine that specific inputs are spent on its outputs, since it does not have the ability to calculate a key image for them. Therefore, he sees only incoming transactions (for them, only a pair of tracking key is enough).
To form a correct transaction, you need to restore the key image for each of the outputs, re-scan the blockchain and determine which of them are spent, and only then start generating it.
Consider the process of forming a key image. It is calculated by the formula:
where
Hp is a predetermined hash function,
P is the public exit key (see Figure 1),
x is the private exit key, which we restore to the recipient of this output, it is calculated as follows:
where
Hs is some previously known cryptographic hash function,
a is the private view key,
R is the public key of the transaction (Tx pub key, see Figure 1) and
b is the private spend key. Substituting one expression into another and opening the brackets, we get:
But since we do not have a one-piece spend key, it is necessary to restore it. In the case of N / N, everything is simple (take for example 3/3):
Here
H p (P) b i is a
partial key image received from the i-th participant.
For schemes N - 1 / N (2/3 on behalf of the first participant without the participation of the third):
in this case,
H p (P) b i B j is a
partial key image.The essence of the process of exchanging exits is precisely that the required number of signatories to the transaction sends its partial key image for each of the exits to the other participants of the wallet. At the same time, the participants do not disclose their private keys, thus a third-party observer or an unscrupulous participant does not have the opportunity to restore the full spend key and take possession of the purse alone.
With this data, the initiator of the transaction can form it and prepare it for signature. The generated transaction is sent to all willing to sign it to generate Ring CT signatures, all necessary signatures are created and the transaction is sent to the network.
Automation of data exchange
The above describes the procedures for exchanging parts of keys and key images that need to be performed either once or after each transaction sent. In the current implementation of Monero Core Wallet, it is proposed to perform these actions manually by exchanging the necessary data via secure channels of communication with their correspondents manually (by exporting the necessary data from the wallet and sending it via instant messengers or otherwise).
You can demonstrate this by the example of creating a wallet using the 2/3 scheme and signing the transaction. Each participant executes the following commands using the monero-wallet-cli utility:
[Wallet 9uKCgo]: prepare_multisig MultisigV1baCWviNomMXe271W8HW4imh8SsnNEWP2bCswQfoB9MGzNZ8FUG3e8UCNm5toKQzSQH2e8rUWUCGazaCcvej1ToCQYBMovJZYaYiYWQvzsvyWruXycZdVDSsyugjEzwQNK3FUEkug2LXiH91NmekGb7kp9gK9kuoxDDhGn1nLKXUpnXR5 Send this multisig info to all other participants, then use make_multisig <threshold> <info1> [<info2> ...] with others' multisig info This includes the PRIVATE view key, so needs to be disclosed only to that multisig wallet's participants [wallet 9uKCgo]: make_multisig 2 MultisigV1XQugvU4JwcwTQbKdH5qGFnavxUX54wGxNis2iN6zoLD94DahnXbyNxH1NQBp2rYRFFJCT2uiJbssHLJYEAb8X1tS5UCqTXYu3FkgRNSZt5mRNgE58iXZHPj839Pbm3ozGcXmRT6GcRMMxMjRonfYKpnPq1UyZSMN7Qr9AYin1gYyoJSh MultisigV1HVqTW8P4UNWUE8QfBaEdwDWJuXBWEPnTrKqVJiUudGG14cHREk9TKmeR9xzSs4wf4jd22mV94C2ehSViApawnpp2SpRqp19eKXLHz2JmNp7eGR6TJMt4VsDTqANRwb1FtD9weef342f5KXDRZK7iQT1MTubyHhEcFyV5aLCjjQ8owMkH Another step is needed MultisigxV1PQwytRuYGkB6UEVJ7v2S7q492cwNTdwySXyasToAuQQq73TvM1rBrog5bcYz5w2P6Z4jwKtzrHr7shRGo5mAShvLVbYtBdQNhQs izMb51K7iaWQB4te5mQaiB1cok84CbvA9WKnVpTJGyb7SbS7NwAgmpEhU812RTdzrdHp5sD41duYtRNW6qna5mTMYmtTjAEdKpKCvM6EwhV4ncWscpvoBfyYP Send this multisig info to all other participants, then use finalize_multisig <info1> [<info2> ...] with others' multisig info [wallet 9uKCgo]: finalize_multisig MultisigxV1PdeMJo5rxcWTXDJ7rbyuacBseugsn2djZKKEdwvFYVmz73TvM1rBrog5bcYz5w2P6Z4jwKtzrHr7shRGo5mAShvLUxykuq5gho7gGQBCEa3JmBaY7rNHqqUaCUs1WWQi9tojZTMmCJJ4evwJzcXEDqcAd7ShwxsJtJtXdiATs54BbBfyCbwXbnDRKAtagJF36z74KJA58NgEmnHv23ZQeePCoacM MultisigxV1RTwyE53FjKPQaAn4ZMWM5hc8C92eJndpyKby4L9HpF2TUxykuq5gho7gGQBCEa3JmBaY7rNHqqUaCUs1WWQi9tojVbYtBdQNhQsizMb51K7iaWQB4te5mQaiB1cok84CbvA928U2yJFK86jNxtMopxHkcnYjjeYfp8TAB53Y1CukBiHfL2M4EztDALXLReXjJxkMry65Jw6vVePJp2T5CW8T8QE5
Before sending a transaction, the parties must exchange partial key images:
[wallet 9uKCgo]: export_multisig_info ki1
Multisig info exported to ki1
[wallet 9uKCgo]: import_multisig_info ki2 ki3
Height 1103873, txid <f7e648915287fafca1dc67eb26267e09f92bba7ab7fd52a12600c3e6440db0eb>, 2.000000000000, idx 0/0
Height 1103882, txid <2e3a5591c741c0943a47a2bcbd1ec26493158088c88308bcbfc97423ea95c491>, 0.009000000000, idx 0/0
Multisig info imported
Next, the wallet is resynchronized with full keys and, having received data on outgoing payments, the participant can prepare a transaction:
wallet 9uKCgo
No payment id is included with this transaction. Is this okay? (Y / Yes / N / No): Y
There is currently a 2 block backlog at that fee level. Is this okay? (Y / Yes / N / No) Y
Transaction 1/1:
Spending from address index 0
Sending 1.000000000000. The transaction fee is 0.012000000000
Is this okay? (Y / Yes / N / No): Y
Unsigned transaction (s) written to multisig_monero_tx
You need to transfer the generated file to another member to sign and send to the network:
[wallet 9twQxU]: sign_multisig multisig_monero_tx
Loaded 1 transactions, for 1.031762770000, fee 0.012000000000, sending 1.000000000000 to 9vUnTucAioDHD4ZqrFHXAgfLqrsC3LkZ6JFr5axBLhDiFMaHuEk33aqXimoZEMtQh5ibdYxcNSBw2hBZLAsCnuw4B4rBeZX, 0.019762770000 change to 9uKCgopHzXrQLnph1ZNFQgdxZZyGhKRLfaNv7EEgWc1f3LQPSZR7BP4ZZn4oH7kAbX3kCd4oDYHg6hE541rQTKtHB7ufnmk, with min ring size 7, no payment ID. Is this okay? (Y / Yes / N / No): Y
Transaction successfully signed multisig_monero_tx, txid 1d28af64bc78d05b625c4f7af7c321d4c8943c4c2692f57aa53e303387f40db6
[wallet 9twQxU]: submit_multisig multisig_monero_tx
Loaded 1 transactions, for 1.031762770000, fee 0.012000000000, sending 1.000000000000 to 9vUnTucAioDHD4ZqrFHXAgfLqrsC3LkZ6JFr5axBLhDiFMaHuEk33aqXimoZEMtQh5ibdYxcNSBw2hBZLAsCnuw4B4rBeZX, 0.019762770000 change to 9uKCgopHzXrQLnph1ZNFQgdxZZyGhKRLfaNv7EEgWc1f3LQPSZR7BP4ZZn4oH7kAbX3kCd4oDYHg6hE541rQTKtHB7ufnmk, with min ring size 7, no payment ID. Is this okay? (Y / Yes / N / No): Y
Transaction successfully submitted, transaction <1d28af64bc78d05b625c4f7af7c321d4c8943c4c2692f57aa53e303387f40db6>
You can check out the show_transfers command.
Obviously, although this approach allows using a multisig wallets with a strong desire, it cannot be used by inexperienced users or, for example, by users of mobile wallets.
Therefore, we are developing our own solution that would automate the exchange of this data without disturbing the privacy of the parties and the security of transactions in order to make the technology of multi-signatures in Monero available to more people. The solution is based on applications that support both standard and multisig-wallets, and an open server part that provides data exchange and transfer to the corresponding wallets.
You can learn more about this project on the
wallet.exan.tech page, and about the resources we support for the Monero network in the section
exan.tech/en/projects/monero .
Conclusion
We considered the mechanism for creating multisig-wallets and forming transactions with multi-signatures in Monero. Currently, only a limited set of signature schemes is supported, but it will be expanded to arbitrary 2/5 formulas, etc. The existing mechanism for exchanging data necessary for the functioning of the wallet is rather inconvenient, but thanks to the openness of the Monero ecosystem with the help of third-party solutions, it can be brought to the usual quality of ordinary users.
In the following articles we will talk about other aspects of the Monero device: RingCT and ring signatures, the wallet architecture and the libwallet library, as well as the development prospects of this blockchain.
Ask your questions, suggest topics for new articles about cryptocurrency technologies, and subscribe to our group on
Facebook to keep up with our events and publications.