How Bitcoin Multi-Signing Works
In this article, we will look at how multi-signature works in the Bitcoin protocol. Please note that in other cryptocurrencies and digital currencies, these mechanisms can be implemented differently - it depends on the transaction model. We will give a definition of a multi-signature, schematically analyze its structure using the example of a transaction, consider the options for its use and precautions when working with it. We will try to openly reveal the topic of the proposed improvements, P2SH, and also on the scheme we analyze the mechanism for sending a payment to an address with a multi-signature. We believe that the presented material will be interesting to readers whose activity or area of interest concerns digital currencies.
Multisignature address (multisig address, if abbreviated) is the Bitcoin address to which several pairs of ECDSA keys are attached at once. Each pair consists of private and public keys. The schemes of combinations according to which you can use these keys may be different. Moreover, you can set the conditions under which you will need to provide several signatures to spend coins from the address.
In more detail it can be displayed schematically. For now, it will be enough to imagine that multisignature address is formed by hashing several concatenated public keys at once. We will take a closer look at this in detail. The diagram shows a transaction that spends with multisignature address.
Gray indicates the header area. It contains two fields. Two inputs are marked in blue and two are marked in green. The first entry contains the filled fields: the hash value of the previous transaction is recorded, which spends the coin data, the exit number, etc. The scriptSig field contains the public key and the signature, which is typical of a normal transaction.
Pay attention to the second entry of the transaction. There is another data combination in the scriptSig field: two public keys and two signatures are listed. They should be verified with these public keys accordingly. This is the transaction entry that spends coins with multisignature address. This is what proof of ownership of coins will look like.
There are various key combinations when using multisignature address. The most used options are 2-of-2, 2-of-3, and 3-of-3. The maximum possible option - 15-of-15.
The simplest combination is 2-of-2. It implies that there is a multisignature address to which two pairs of keys are attached, in essence, two public keys are consecutively mixed and some address is received. To spend coins from this address, you must provide two signatures that will be verified by the two available public keys, the concatenation and hashing of which in the right order should give the same value of the address. To summarize, there are two predetermined keys and two signatures are needed, which will be checked by these keys, respectively.
The use of multisignature address 2-of-3 implies that any two keys from three pre-installed keys must be used to verify two signatures presented as proof of possession of coins. In other words, to spend coins, you must provide two signatures, which will be verified by two public keys from the preset three.
The 3-out-3 combination, as you already understood, requires three signatures, which will be verified by three pre-set keys. The maximum in terms of the number of required signatures and public keys will be the 15-of-15 scheme.
Let's go through the options for the use of these combinations.
Imagine that a husband and wife wanted to keep a total budget.
They agree that only with the consent of each of them will the budget funds be spent on specific needs. With the help of Bitcoin, this can be implemented quite simply. They create multisignature address according to this scheme, where one key is controlled by the wife, and the second - by the husband. Then the family will receive all the income for such addresses, and they will be able to spend money only by mutual agreement.
Anticipating your question about the scenarios when a husband and wife do not agree, imagine that a wife considers it necessary to purchase a washing machine, because she is tired of washing with her hands, and her husband believes that this is not such a hard work, but it would be better to spend all the coins on the latest PlayStation model and spend so leisure. The wife takes offense at her husband and eats a piece of paper with her private key, making it impossible to waste from this address at all.
How to avoid such a situation and protect the coins from the final loss of coins?
It is possible to create a transaction that spends all the money from the desired address, despite the fact that the amount is not known in advance. At the input is not the sum, but a link to the transaction, from where these coins can be spent. There is such a thing as hash type, Is a way to cover transaction signatures. It allows you to create a signature in advance, and some of these transactions, such as input, can be substituted later. Thus, you can create a transaction that spends coins from a transaction that does not yet exist, and apply it later, that is, when you need it.
Moreover, a LockTime restriction can be placed on this transaction. It allows you not to confirm the transaction immediately, but to postpone it for some time. So, the husband and wife immediately after creating the multisignature address, before receiving any payments, can create two LockTime transactions in which all future coins will be redirected to the usual addresses of the husband and wife, which they control independently. In this case, transactions will be delayed and can only be confirmed, for example, after two months. These transactions can be printed out on paper and stored in a safe with each individual. If a situation arises when the coins are on the balance of multisignature address, and the keys are lost (one or both), the coins become frozen. But there is a locktime transaction. The one who publishes such a transaction will be able to withdraw these funds to a valid external address. Coins will be saved. This was a simplified example, but more complex mechanisms are possible.
Suppose there is a group of people who have a common budget.
They create a multisignature address in which there are three keys, but two signatures are enough to sign a transaction. With the consent of the participants, who constitute the majority of the group, these funds can be spent. In other words, any two participants out of three can spend coins. For this, it is enough to spread the transaction to the network.
There is a more interesting way to use the 2-of-3 combination, and it is used in the so-called purse services. The service of the wallet in this context should not be confused with the usual Bitcoin wallet, which the user controls independently. The service does not provide full storage for coins and does not own them, but only provides services for convenient operation.
If we imagine this situation schematically, then one key belongs directly to the service, the second is generated only by the user (and only he knows), the third key is also generated and stored by the user, but separately. After that, the public keys corresponding to these private keys are computed, and the multisignature address is compiled. There are coins and now the conditions of spending are limited.
Imagine that we are dealing with a certain web service and you can enter its resource through a browser. The browser loads the Bitcoin wallet code, which at this address receives a list of unused coins, calculates their balance and is ready to spend. If the user wants to spend coins, he directly in the browser makes a transaction and signs it with his (one of the necessary) signature.
Note that a user’s private key can be obtained either from his password, or the key can be randomly generated, encrypted with a user password, and stored by the service. Then the user sends a request to the service, receives a container with an encrypted key, decrypts it with his password and already has access to his private key.
When a user signs a transaction, it is sent to the service side so that he signs the second necessary signature and sends the transaction. The service clarifies the need to sign a transaction through the second authentication channel, that is, through another pre-established channel, which can be a call to a mobile phone, SMS, e-mail and other alternative communication methods (up to a personal visit, if required by the security level) . When the service has made sure that the request for the signature of a transaction is actually initiated by the registered user, he puts the missing signature using his key. After that, the transaction becomes valid and can be distributed to the network for confirmation.
The third key is used in cases where the service fails to service. The software generates this key and offers to save it in a convenient way for you. The user usually keeps it in a safe place. If the service refuses to be serviced, the user can sign the transaction with his own keys (second and third). If the second key was stored on the service side, then the protected container with this key will be sent to the user in advance via an alternative data transmission channel, for example, via e-mail. The user decrypts the container with the key with his password.
The user receives the two necessary private keys and enters into the special software that the service has provided in advance. Further, this software works offline on the user's computer, without the participation of the service. It should be noted that this software should be used only in extreme cases when the service is denied service (i.e., it has been hacked, it is damaged or ceased to exist). Then the user signs the transaction with his keys and transfers the coins where necessary.
On the benefits of such Wallet services, we dwell in more detail. This is a secure way of storage, because the service does not own all the necessary set of keys - it owns only one part, which is not enough to seize the funds. Moreover, access to the funds has neither the service itself, nor the hacker, who can hack it.
The convenience of this approach is that the user does not need to have secure access to this service. It may have a conventional device that may be infected with viruses or controlled by fraudsters, and the data may be compromised or replaced. But the attacker is not enough to own only this device, because from it you can get only one of two signatures.
Another advantage is that if the service is denied service, then the user does not lose access to their coins. These were just some of the possible schemes for using multisignature addresses that are sufficient for dating.
And now it is worth talking about precautions regarding multi-signature. In the case of 2-of-2, you need to create LockTime transactions that will be able to transfer the blocked funds to a specific address. This is true when key loss occurs.
If you are using multisignature address 2-of-3, then it is very important to keep the keys in a safe place. In case of loss of one of the three keys, you must immediately transfer funds and not wait for the moment when 2 keys out of 3 are lost.
In order to understand in more detail how the multi-signature works, we need to talk a little about how Bitcoin Script works: how the rules for spending coins are set, how to satisfy them, what are the operations for describing the rules, what is Bitcoin Script and how its execution is arranged.
Consider an example of a simple case of spending coins, where there is a normal address to which the hash of one public key is tied, a corresponding script that specifies the conditions of spending, and a script that satisfies these conditions.
In the diagram on the left we see the data stack, and on the right the script itself. The first two parts of the script string are signature and the public key, the so-called unlocking script, that is, the script that is specified in the input of the transaction that spends coins. This is followed by a data set, which is indicated in the output of the transaction - this is called a locking script. In other words, the concatenation of two scripts is presented here: a script that unlocks coins, and a script that locks coins. In the case when the transaction is already validated by the host, these two scripts are combined to perform the verification of the conditions of the coins. Thus, unlocking script first goes, followed by locking script.
After that, the full set of operands and data is executed sequentially. The execution point goes sequentially through each operand and each data point. If the execution point falls on the data section, they are pushed onto the stack. As we see in the diagram, the script execution cursor in the upper part points to the signature data, which are then placed on the stack.
Further, the execution cursor points to the public key — it is also pushed onto the stack.
The third step is the duplicate operation, which involves copying the top of the stack and putting this data again onto the stack.
After that, the hash is performed using the Hash-160 hash function. This means that the top of the stack is hashed first by the SHA-2 algorithm at a length of 256 bits, and then with the RIPEMD-160 function at a length of 160 bits. The operation is exactly the same as when hashing the public key and getting the address. In fact, this is it.
We have a stack, a signature, a public key, and a hash of the public key. The script execution cursor points to the address that was specified at the exit of the transaction, that is, the hash value of the public key that was indicated when the coins were sent to it. This piece of data also goes on the stack.
The next operation is the verification of the identity equal verify.
The top two stack items are compared. If they are byte-by-one completely identical, then this data is removed from the stack and it is considered that the check was successful. After this, signature and public key remain on the stack. Accordingly, the check signature operation takes these two operands and verifies the signature with a public key. If the signature is correct with respect to the transaction that is currently being tested, because the signature covers part of the transaction, respectively, you need to take the hash value from certain fields of this transaction. This is specified by a separate byte of the hash type structure, that is, the hash value is taken and is fed to the signature verification input along with the signature and public key. If the check is performed correctly, then the result of the check is true, this value is pushed onto the stack. This completes the execution of the script. The data is transferred to the calling function and checked there. If the stack is true, then the verification of this transaction input was correct. If all transaction entries have been correctly verified, then the entire transaction is considered correct.
We got to know how Bitcoin Script works to test simple entries and exits of a transaction. Now we will talk about how multisignature is organized and how it works when using Bitcoin Script.
Once it was proposed BIP16, which sets a new concept in the Bitcoin protocol - the so-called pay to script hash (P2SH). This is an opportunity to set the rules for spending coins not with an open script, where you write operands and some data in a row, which are then executed in the way we considered, but as a hash value of the script you need, that is, the checksum of these operands. This allowed in the exit of the transaction to set large and complex conditions of spending coins, but at the same time the output itself remained short.
To spend these coins under such conditions, you need to specify the data satisfying this script and the original script as input to prove that you know what conditions were set when sending the coins, so that the hash value of the original script coincided with the addresses to which Coins were shipped. In other words, prove that you know the conditions, and satisfy these conditions.
This proposal to improve Bitcoin was adopted on January 3, 2012. Actually on Bitcoin's birthday. Now it is actively used to implement multisignature address.
Let's look at an example of how this works. To build a transaction, we need to have an idea of such concepts as Redeem Script, Locking Script and Unlocking Script.
Redeem Script contains public keys to which the multisignature address will be attached. In this case, we consider the key combination “2-of-5”. First comes the value 2, that is, we indicate that 2 signatures will be necessary, which will be verified by the corresponding public keys. After that, the public keys follow, in our case there are 5. Next, we indicate 5, since we specified 5 public keys, and when the data will be read in the reverse order, this value will be needed to understand how many keys need to be read. After that, the operation check multisignature is indicated.
Locking Script is a script that is specified in the output of a transaction that pays for multisignature address. Here the operation of obtaining a hash value will be performed, with which we have already got acquainted in detail. This is followed by the hash value Redeem Script, which occupies 20 bytes. After that, an operation is carried out to verify the compliance of the data with the actual hash value.
Unlocking Script is a concatenation of scripts at the input of a transaction with scripts in the output of a transaction that paid for this address. There are two signatures needed to waste coins, and a full Redeem Script, which will later be hashed and checked for compliance with the address to which the coins were sent. After that, the script will be executed entirely, including for checking the multi-signature.
It is important that there are restrictions on the maximum size for each of the listed scripts and it is 520 bytes. This number was calculated based on the fact that the Unlocking Script can fit a maximum of 15 signatures and 15 corresponding public keys, as well as several operations to verify these values. This is how a certain number was obtained, which, when rounded, yielded 520 bytes. It should be said that this number was obtained with the expectation that the multisignature address of the “15 out of 15” type is a reasonable enough limit for practical use. Redeem Script when using a large number of signatures becomes very large in volume. The user who uses multisignature address or other P2SH addresses, when spending coins from them, has very large transactions. It means,
Separately, consider the advantages of P2SH. The first of these is that such addresses can be encoded into a familiar look using Base58, in which their length is 34 characters. In accordance with BIP13, which defines the installation rules for the version byte for Bitcoin addresses encoded with Base58Check, the address will start with a triple, that is, a specific version byte is inserted there.
In the example, you can see the P2SH address.
3P14159f73E4gFr7JterCCQh9QjiTjiZrG
This may not necessarily be a multisignature address. Redeem Script can describe not only multisignature address, but also other complex coin spending rules.
We add that this is not the only way to organize a multi-signature in Bitcoin. It is possible not to use P2SH, but in the output that will pay to the multisignature address, not the hash value from the script, but the script itself, that is, list all the public keys directly in the output and set up the multisignature check operation. However, when sending coins to such an address, you immediately disclose the public keys, since they will be in the public domain and at that moment coins will be stored on them.
And another disadvantage is that the sender of coins to multisignature address has a high volume transaction, for which you have to pay a large commission. It is unlikely that the sender will want to overpay for the fact that the recipient wants to use multisignature. P2SH makes it possible to transfer the commission costs to the recipient. If the recipient wants to accept coins at multisignature address, he will pay for large transactions himself, which is a fairer approach.
Add that P2SH allows you to implement different combinations of such multisignature (2-of-2, 2-of-3, and others).
Schematically, consider sending to multisignature address.
Imagine that Alice wants to pay Bob, who uses only multisignature addresses. To do this, Bob, locally on his computer (by the way, instead of Bob, there can be some organization) generates several private keys, obtains the corresponding public keys from them, which are concatenated in a certain way. Most often, public keys are represented first encoded with Base58Check, and then they are sorted alphabetically, and then concatenated.
This approach justifies itself when recalculation of public keys from private ones is required. They need to be concatenated in exactly the same order, because the next step is to create a Redeem Script and hash it. If exactly the same keys fall into Redeem Script, but in a different order, we will get another hash value and another address. This will entail certain misunderstandings. Therefore, before concatenation, public keys must be sorted according to some rule. And most often they use alphabetical sorting in the Base58 number system.
So, Bob counted the hash value from Redeem Script. He can represent it in the form of 20 bytes and send it to Alice, saying that it is a multisignature address using P2SH. However, Bob can encode it with a version byte, like a normal address, and just send it to Alice. Alice will understand from the version byte that this is a multisignature address, make a transaction and fill its output accordingly so that Bob will receive his coins. Next, it distributes the transaction to the network. They wait for confirmation and Bob accepts the payment from Alice. Replacing Bob, for example, provides a service or transfers goods.
The moment comes when Bob wants to spend these coins. It should be understood that the full Redeem Script was not publicly disclosed while the coins were on its multisignature address. And even Alice didn’t see what kind of public keys Bob used, how many were there, etc. She doesn’t know at all what rules this P2SH address was made to, multisignature address or not, etc. Accordingly, the attack on the electronic -digital signature (on an elliptic curve) is still impossible.
Suppose Bob wants to send a payment to Eve.
She generates a new address and gives it to Bob. He creates a transaction stub, at the entrance of which he indicates the transaction in which he received the coins from Alice, and at the output - the address of Eve. Now he must provide proof of possession of the coins he spends. To do this, he takes two of his private keys (we mentioned above that his multisignature address implies the “2-of-5” variant), from which he calculates two signatures for this transaction. Next, it takes the full Redeem Script and adds it to the transaction input.
Please note that this Redeem Script must be stored on Bob’s computer entirely or he must remember the order in which he used the public keys to compose this script. If he applied certain sorting rules, he should remember them. He should also remember that multisignature address is attached to certain private keys. Without this knowledge, Bob would not know which of his private keys to operate and in what order they should be hashed to get the desired address.
So he has two signatures and a full Redeem Script. The transaction is considered correct and Bob distributes it to the network, and after waiting for confirmation. This is the main thing with regards to spending with multisignature address.
We now turn to your questions.
- Is it possible to run the same wallet simultaneously on three different computers and start synchronization?
Most likely, we are talking about some kind of network node: either an SPV node or a full node. Several different computers and the same wallet were used. And under the purse refers to personal keys. There are several complete nodes that implement the functionality of wallets. On these nodes, we insert the same private keys and begin synchronization. Most likely, with full network synchronization, we will see the same balance on each wallet that uses its node. If you see changes on one node, then after synchronization with the network you will see exactly the same changes on all other nodes. The transaction is not kept secret, it is distributed to all nodes that verify it and display the corresponding changes, if it concerns their addresses. In fact, yes, you can use one key on several nodes, but all transactions will also be synchronized automatically. Bitcoins will not exactly double this and, moreover, will not triple.
- How does P2SH work with Segregated Witness?
Segregated Witness is a transaction structure where evidence of ownership of coins is put into a separate structure, they do not fall into the blockchain, but when validating transactions they are distributed together, that is, all validators check the correctness of transactions on a separate evidence structure. After confirmation of the transaction, the evidence is not saved, since it does not make sense. There are also advantages in building such transaction chains, in which certain coins without actual confirmation in the current transaction are already spent in the next one, built on its basis, but they are not distributed to the network. Thus, transaction chains are formed that do not disclose evidence of ownership of coins. It facilitates data transfer and adds privacy. For Segregated Witness, a different type of address was used. it contains slightly different operands. It is possible to send coins that are stored at regular addresses, including P2SH addresses, to Witness P2SH addresses.
“Are the addresses from the top three starting at Lighting Network?”
BIP13 defines the rules by which the version byte is selected for Bitcoin addresses in the test net, other currencies, etc. Yes, the Lighting Network uses multisignature addresses, which also use the P2SH method of setting conditions.
- Why can not personalize the wallet, that is, bind it to a specific person?
Bitcoin as a protocol of a payment system does not require identification of a wallet, because it works according to the laws of mathematics, and mathematics does not allow one to describe a person as a person. Moreover, it is not a prerequisite for verifying transactions. There is enough digital signature. Who can generate such signatures, that is their owner - this does not apply to the Bitcoin protocol. Consequently, a person, a group of several people, a robot, etc. can own a signature.
As for personalization, if you connect a specific address with a specific person, then you violate privacy and can deanonymize part of the network with a certain probability. In general, the database is open, but there is no identity data on it.
- If the currency is not mine, and such currencies are 70-80%, can you trust them?
It is well written that it is a currency, not a cryptocurrency, because cryptocurrency works on the same principles as Bitcoin, that is, all processes are as decentralized as possible: issue, transaction verification, data storage, acceptance of changes, etc. But there are such currencies , we will call them digital currencies, in which not all of the listed processes are decentralized. One option may be centralized emission, that is, there is no such thing as mining, mining, that is, there is no solution to a complex problem. Ripple, Stellar, NXT, Cardano digital currency works according to this principle. Other principles of coin distribution among users were applied there, for example, through ICO, proof of identity, etc. Due to the fact that not all processes can be decentralized and independent, it is impossible to name any digital currencycryptocurrency . In addition, the issue of trust in one currency or another is personal. You decide the amount of this trust. It is necessary to take into account the purposes for which the currency is used, as well as its risks and limitations.
Multisignature address
Multisignature address (multisig address, if abbreviated) is the Bitcoin address to which several pairs of ECDSA keys are attached at once. Each pair consists of private and public keys. The schemes of combinations according to which you can use these keys may be different. Moreover, you can set the conditions under which you will need to provide several signatures to spend coins from the address.
Bitcoin transaction that uses multi-signature
In more detail it can be displayed schematically. For now, it will be enough to imagine that multisignature address is formed by hashing several concatenated public keys at once. We will take a closer look at this in detail. The diagram shows a transaction that spends with multisignature address.
Gray indicates the header area. It contains two fields. Two inputs are marked in blue and two are marked in green. The first entry contains the filled fields: the hash value of the previous transaction is recorded, which spends the coin data, the exit number, etc. The scriptSig field contains the public key and the signature, which is typical of a normal transaction.
Pay attention to the second entry of the transaction. There is another data combination in the scriptSig field: two public keys and two signatures are listed. They should be verified with these public keys accordingly. This is the transaction entry that spends coins with multisignature address. This is what proof of ownership of coins will look like.
Key combinations
There are various key combinations when using multisignature address. The most used options are 2-of-2, 2-of-3, and 3-of-3. The maximum possible option - 15-of-15.
The simplest combination is 2-of-2. It implies that there is a multisignature address to which two pairs of keys are attached, in essence, two public keys are consecutively mixed and some address is received. To spend coins from this address, you must provide two signatures that will be verified by the two available public keys, the concatenation and hashing of which in the right order should give the same value of the address. To summarize, there are two predetermined keys and two signatures are needed, which will be checked by these keys, respectively.
The use of multisignature address 2-of-3 implies that any two keys from three pre-installed keys must be used to verify two signatures presented as proof of possession of coins. In other words, to spend coins, you must provide two signatures, which will be verified by two public keys from the preset three.
The 3-out-3 combination, as you already understood, requires three signatures, which will be verified by three pre-set keys. The maximum in terms of the number of required signatures and public keys will be the 15-of-15 scheme.
Let's go through the options for the use of these combinations.
2-of-2
Imagine that a husband and wife wanted to keep a total budget.
They agree that only with the consent of each of them will the budget funds be spent on specific needs. With the help of Bitcoin, this can be implemented quite simply. They create multisignature address according to this scheme, where one key is controlled by the wife, and the second - by the husband. Then the family will receive all the income for such addresses, and they will be able to spend money only by mutual agreement.
Anticipating your question about the scenarios when a husband and wife do not agree, imagine that a wife considers it necessary to purchase a washing machine, because she is tired of washing with her hands, and her husband believes that this is not such a hard work, but it would be better to spend all the coins on the latest PlayStation model and spend so leisure. The wife takes offense at her husband and eats a piece of paper with her private key, making it impossible to waste from this address at all.
How to avoid such a situation and protect the coins from the final loss of coins?
It is possible to create a transaction that spends all the money from the desired address, despite the fact that the amount is not known in advance. At the input is not the sum, but a link to the transaction, from where these coins can be spent. There is such a thing as hash type, Is a way to cover transaction signatures. It allows you to create a signature in advance, and some of these transactions, such as input, can be substituted later. Thus, you can create a transaction that spends coins from a transaction that does not yet exist, and apply it later, that is, when you need it.
Moreover, a LockTime restriction can be placed on this transaction. It allows you not to confirm the transaction immediately, but to postpone it for some time. So, the husband and wife immediately after creating the multisignature address, before receiving any payments, can create two LockTime transactions in which all future coins will be redirected to the usual addresses of the husband and wife, which they control independently. In this case, transactions will be delayed and can only be confirmed, for example, after two months. These transactions can be printed out on paper and stored in a safe with each individual. If a situation arises when the coins are on the balance of multisignature address, and the keys are lost (one or both), the coins become frozen. But there is a locktime transaction. The one who publishes such a transaction will be able to withdraw these funds to a valid external address. Coins will be saved. This was a simplified example, but more complex mechanisms are possible.
2-of-3
Suppose there is a group of people who have a common budget.
They create a multisignature address in which there are three keys, but two signatures are enough to sign a transaction. With the consent of the participants, who constitute the majority of the group, these funds can be spent. In other words, any two participants out of three can spend coins. For this, it is enough to spread the transaction to the network.
Example with Wallet service
There is a more interesting way to use the 2-of-3 combination, and it is used in the so-called purse services. The service of the wallet in this context should not be confused with the usual Bitcoin wallet, which the user controls independently. The service does not provide full storage for coins and does not own them, but only provides services for convenient operation.
If we imagine this situation schematically, then one key belongs directly to the service, the second is generated only by the user (and only he knows), the third key is also generated and stored by the user, but separately. After that, the public keys corresponding to these private keys are computed, and the multisignature address is compiled. There are coins and now the conditions of spending are limited.
Imagine that we are dealing with a certain web service and you can enter its resource through a browser. The browser loads the Bitcoin wallet code, which at this address receives a list of unused coins, calculates their balance and is ready to spend. If the user wants to spend coins, he directly in the browser makes a transaction and signs it with his (one of the necessary) signature.
Note that a user’s private key can be obtained either from his password, or the key can be randomly generated, encrypted with a user password, and stored by the service. Then the user sends a request to the service, receives a container with an encrypted key, decrypts it with his password and already has access to his private key.
When a user signs a transaction, it is sent to the service side so that he signs the second necessary signature and sends the transaction. The service clarifies the need to sign a transaction through the second authentication channel, that is, through another pre-established channel, which can be a call to a mobile phone, SMS, e-mail and other alternative communication methods (up to a personal visit, if required by the security level) . When the service has made sure that the request for the signature of a transaction is actually initiated by the registered user, he puts the missing signature using his key. After that, the transaction becomes valid and can be distributed to the network for confirmation.
The third key is used in cases where the service fails to service. The software generates this key and offers to save it in a convenient way for you. The user usually keeps it in a safe place. If the service refuses to be serviced, the user can sign the transaction with his own keys (second and third). If the second key was stored on the service side, then the protected container with this key will be sent to the user in advance via an alternative data transmission channel, for example, via e-mail. The user decrypts the container with the key with his password.
The user receives the two necessary private keys and enters into the special software that the service has provided in advance. Further, this software works offline on the user's computer, without the participation of the service. It should be noted that this software should be used only in extreme cases when the service is denied service (i.e., it has been hacked, it is damaged or ceased to exist). Then the user signs the transaction with his keys and transfers the coins where necessary.
The advantages of Wallet services with the signature of 2-of-3
On the benefits of such Wallet services, we dwell in more detail. This is a secure way of storage, because the service does not own all the necessary set of keys - it owns only one part, which is not enough to seize the funds. Moreover, access to the funds has neither the service itself, nor the hacker, who can hack it.
The convenience of this approach is that the user does not need to have secure access to this service. It may have a conventional device that may be infected with viruses or controlled by fraudsters, and the data may be compromised or replaced. But the attacker is not enough to own only this device, because from it you can get only one of two signatures.
Another advantage is that if the service is denied service, then the user does not lose access to their coins. These were just some of the possible schemes for using multisignature addresses that are sufficient for dating.
Precautions when working with multi-signatures
And now it is worth talking about precautions regarding multi-signature. In the case of 2-of-2, you need to create LockTime transactions that will be able to transfer the blocked funds to a specific address. This is true when key loss occurs.
If you are using multisignature address 2-of-3, then it is very important to keep the keys in a safe place. In case of loss of one of the three keys, you must immediately transfer funds and not wait for the moment when 2 keys out of 3 are lost.
How Bitcoin Script works (by example)
In order to understand in more detail how the multi-signature works, we need to talk a little about how Bitcoin Script works: how the rules for spending coins are set, how to satisfy them, what are the operations for describing the rules, what is Bitcoin Script and how its execution is arranged.
Consider an example of a simple case of spending coins, where there is a normal address to which the hash of one public key is tied, a corresponding script that specifies the conditions of spending, and a script that satisfies these conditions.
In the diagram on the left we see the data stack, and on the right the script itself. The first two parts of the script string are signature and the public key, the so-called unlocking script, that is, the script that is specified in the input of the transaction that spends coins. This is followed by a data set, which is indicated in the output of the transaction - this is called a locking script. In other words, the concatenation of two scripts is presented here: a script that unlocks coins, and a script that locks coins. In the case when the transaction is already validated by the host, these two scripts are combined to perform the verification of the conditions of the coins. Thus, unlocking script first goes, followed by locking script.
After that, the full set of operands and data is executed sequentially. The execution point goes sequentially through each operand and each data point. If the execution point falls on the data section, they are pushed onto the stack. As we see in the diagram, the script execution cursor in the upper part points to the signature data, which are then placed on the stack.
Further, the execution cursor points to the public key — it is also pushed onto the stack.
The third step is the duplicate operation, which involves copying the top of the stack and putting this data again onto the stack.
After that, the hash is performed using the Hash-160 hash function. This means that the top of the stack is hashed first by the SHA-2 algorithm at a length of 256 bits, and then with the RIPEMD-160 function at a length of 160 bits. The operation is exactly the same as when hashing the public key and getting the address. In fact, this is it.
We have a stack, a signature, a public key, and a hash of the public key. The script execution cursor points to the address that was specified at the exit of the transaction, that is, the hash value of the public key that was indicated when the coins were sent to it. This piece of data also goes on the stack.
The next operation is the verification of the identity equal verify.
The top two stack items are compared. If they are byte-by-one completely identical, then this data is removed from the stack and it is considered that the check was successful. After this, signature and public key remain on the stack. Accordingly, the check signature operation takes these two operands and verifies the signature with a public key. If the signature is correct with respect to the transaction that is currently being tested, because the signature covers part of the transaction, respectively, you need to take the hash value from certain fields of this transaction. This is specified by a separate byte of the hash type structure, that is, the hash value is taken and is fed to the signature verification input along with the signature and public key. If the check is performed correctly, then the result of the check is true, this value is pushed onto the stack. This completes the execution of the script. The data is transferred to the calling function and checked there. If the stack is true, then the verification of this transaction input was correct. If all transaction entries have been correctly verified, then the entire transaction is considered correct.
We got to know how Bitcoin Script works to test simple entries and exits of a transaction. Now we will talk about how multisignature is organized and how it works when using Bitcoin Script.
P2SH
Once it was proposed BIP16, which sets a new concept in the Bitcoin protocol - the so-called pay to script hash (P2SH). This is an opportunity to set the rules for spending coins not with an open script, where you write operands and some data in a row, which are then executed in the way we considered, but as a hash value of the script you need, that is, the checksum of these operands. This allowed in the exit of the transaction to set large and complex conditions of spending coins, but at the same time the output itself remained short.
To spend these coins under such conditions, you need to specify the data satisfying this script and the original script as input to prove that you know what conditions were set when sending the coins, so that the hash value of the original script coincided with the addresses to which Coins were shipped. In other words, prove that you know the conditions, and satisfy these conditions.
This proposal to improve Bitcoin was adopted on January 3, 2012. Actually on Bitcoin's birthday. Now it is actively used to implement multisignature address.
How does P2SH work?
Let's look at an example of how this works. To build a transaction, we need to have an idea of such concepts as Redeem Script, Locking Script and Unlocking Script.
Redeem Script contains public keys to which the multisignature address will be attached. In this case, we consider the key combination “2-of-5”. First comes the value 2, that is, we indicate that 2 signatures will be necessary, which will be verified by the corresponding public keys. After that, the public keys follow, in our case there are 5. Next, we indicate 5, since we specified 5 public keys, and when the data will be read in the reverse order, this value will be needed to understand how many keys need to be read. After that, the operation check multisignature is indicated.
Locking Script is a script that is specified in the output of a transaction that pays for multisignature address. Here the operation of obtaining a hash value will be performed, with which we have already got acquainted in detail. This is followed by the hash value Redeem Script, which occupies 20 bytes. After that, an operation is carried out to verify the compliance of the data with the actual hash value.
Unlocking Script is a concatenation of scripts at the input of a transaction with scripts in the output of a transaction that paid for this address. There are two signatures needed to waste coins, and a full Redeem Script, which will later be hashed and checked for compliance with the address to which the coins were sent. After that, the script will be executed entirely, including for checking the multi-signature.
It is important that there are restrictions on the maximum size for each of the listed scripts and it is 520 bytes. This number was calculated based on the fact that the Unlocking Script can fit a maximum of 15 signatures and 15 corresponding public keys, as well as several operations to verify these values. This is how a certain number was obtained, which, when rounded, yielded 520 bytes. It should be said that this number was obtained with the expectation that the multisignature address of the “15 out of 15” type is a reasonable enough limit for practical use. Redeem Script when using a large number of signatures becomes very large in volume. The user who uses multisignature address or other P2SH addresses, when spending coins from them, has very large transactions. It means,
Benefits of P2SH
Separately, consider the advantages of P2SH. The first of these is that such addresses can be encoded into a familiar look using Base58, in which their length is 34 characters. In accordance with BIP13, which defines the installation rules for the version byte for Bitcoin addresses encoded with Base58Check, the address will start with a triple, that is, a specific version byte is inserted there.
In the example, you can see the P2SH address.
3P14159f73E4gFr7JterCCQh9QjiTjiZrG
This may not necessarily be a multisignature address. Redeem Script can describe not only multisignature address, but also other complex coin spending rules.
We add that this is not the only way to organize a multi-signature in Bitcoin. It is possible not to use P2SH, but in the output that will pay to the multisignature address, not the hash value from the script, but the script itself, that is, list all the public keys directly in the output and set up the multisignature check operation. However, when sending coins to such an address, you immediately disclose the public keys, since they will be in the public domain and at that moment coins will be stored on them.
And another disadvantage is that the sender of coins to multisignature address has a high volume transaction, for which you have to pay a large commission. It is unlikely that the sender will want to overpay for the fact that the recipient wants to use multisignature. P2SH makes it possible to transfer the commission costs to the recipient. If the recipient wants to accept coins at multisignature address, he will pay for large transactions himself, which is a fairer approach.
Add that P2SH allows you to implement different combinations of such multisignature (2-of-2, 2-of-3, and others).
Schematically, consider sending to multisignature address.
Imagine that Alice wants to pay Bob, who uses only multisignature addresses. To do this, Bob, locally on his computer (by the way, instead of Bob, there can be some organization) generates several private keys, obtains the corresponding public keys from them, which are concatenated in a certain way. Most often, public keys are represented first encoded with Base58Check, and then they are sorted alphabetically, and then concatenated.
This approach justifies itself when recalculation of public keys from private ones is required. They need to be concatenated in exactly the same order, because the next step is to create a Redeem Script and hash it. If exactly the same keys fall into Redeem Script, but in a different order, we will get another hash value and another address. This will entail certain misunderstandings. Therefore, before concatenation, public keys must be sorted according to some rule. And most often they use alphabetical sorting in the Base58 number system.
So, Bob counted the hash value from Redeem Script. He can represent it in the form of 20 bytes and send it to Alice, saying that it is a multisignature address using P2SH. However, Bob can encode it with a version byte, like a normal address, and just send it to Alice. Alice will understand from the version byte that this is a multisignature address, make a transaction and fill its output accordingly so that Bob will receive his coins. Next, it distributes the transaction to the network. They wait for confirmation and Bob accepts the payment from Alice. Replacing Bob, for example, provides a service or transfers goods.
The moment comes when Bob wants to spend these coins. It should be understood that the full Redeem Script was not publicly disclosed while the coins were on its multisignature address. And even Alice didn’t see what kind of public keys Bob used, how many were there, etc. She doesn’t know at all what rules this P2SH address was made to, multisignature address or not, etc. Accordingly, the attack on the electronic -digital signature (on an elliptic curve) is still impossible.
Suppose Bob wants to send a payment to Eve.
She generates a new address and gives it to Bob. He creates a transaction stub, at the entrance of which he indicates the transaction in which he received the coins from Alice, and at the output - the address of Eve. Now he must provide proof of possession of the coins he spends. To do this, he takes two of his private keys (we mentioned above that his multisignature address implies the “2-of-5” variant), from which he calculates two signatures for this transaction. Next, it takes the full Redeem Script and adds it to the transaction input.
Please note that this Redeem Script must be stored on Bob’s computer entirely or he must remember the order in which he used the public keys to compose this script. If he applied certain sorting rules, he should remember them. He should also remember that multisignature address is attached to certain private keys. Without this knowledge, Bob would not know which of his private keys to operate and in what order they should be hashed to get the desired address.
So he has two signatures and a full Redeem Script. The transaction is considered correct and Bob distributes it to the network, and after waiting for confirmation. This is the main thing with regards to spending with multisignature address.
Questions
We now turn to your questions.
- Is it possible to run the same wallet simultaneously on three different computers and start synchronization?
Most likely, we are talking about some kind of network node: either an SPV node or a full node. Several different computers and the same wallet were used. And under the purse refers to personal keys. There are several complete nodes that implement the functionality of wallets. On these nodes, we insert the same private keys and begin synchronization. Most likely, with full network synchronization, we will see the same balance on each wallet that uses its node. If you see changes on one node, then after synchronization with the network you will see exactly the same changes on all other nodes. The transaction is not kept secret, it is distributed to all nodes that verify it and display the corresponding changes, if it concerns their addresses. In fact, yes, you can use one key on several nodes, but all transactions will also be synchronized automatically. Bitcoins will not exactly double this and, moreover, will not triple.
- How does P2SH work with Segregated Witness?
Segregated Witness is a transaction structure where evidence of ownership of coins is put into a separate structure, they do not fall into the blockchain, but when validating transactions they are distributed together, that is, all validators check the correctness of transactions on a separate evidence structure. After confirmation of the transaction, the evidence is not saved, since it does not make sense. There are also advantages in building such transaction chains, in which certain coins without actual confirmation in the current transaction are already spent in the next one, built on its basis, but they are not distributed to the network. Thus, transaction chains are formed that do not disclose evidence of ownership of coins. It facilitates data transfer and adds privacy. For Segregated Witness, a different type of address was used. it contains slightly different operands. It is possible to send coins that are stored at regular addresses, including P2SH addresses, to Witness P2SH addresses.
“Are the addresses from the top three starting at Lighting Network?”
BIP13 defines the rules by which the version byte is selected for Bitcoin addresses in the test net, other currencies, etc. Yes, the Lighting Network uses multisignature addresses, which also use the P2SH method of setting conditions.
- Why can not personalize the wallet, that is, bind it to a specific person?
Bitcoin as a protocol of a payment system does not require identification of a wallet, because it works according to the laws of mathematics, and mathematics does not allow one to describe a person as a person. Moreover, it is not a prerequisite for verifying transactions. There is enough digital signature. Who can generate such signatures, that is their owner - this does not apply to the Bitcoin protocol. Consequently, a person, a group of several people, a robot, etc. can own a signature.
As for personalization, if you connect a specific address with a specific person, then you violate privacy and can deanonymize part of the network with a certain probability. In general, the database is open, but there is no identity data on it.
- If the currency is not mine, and such currencies are 70-80%, can you trust them?
It is well written that it is a currency, not a cryptocurrency, because cryptocurrency works on the same principles as Bitcoin, that is, all processes are as decentralized as possible: issue, transaction verification, data storage, acceptance of changes, etc. But there are such currencies , we will call them digital currencies, in which not all of the listed processes are decentralized. One option may be centralized emission, that is, there is no such thing as mining, mining, that is, there is no solution to a complex problem. Ripple, Stellar, NXT, Cardano digital currency works according to this principle. Other principles of coin distribution among users were applied there, for example, through ICO, proof of identity, etc. Due to the fact that not all processes can be decentralized and independent, it is impossible to name any digital currencycryptocurrency . In addition, the issue of trust in one currency or another is personal. You decide the amount of this trust. It is necessary to take into account the purposes for which the currency is used, as well as its risks and limitations.