Geekly Articles each Day

Multisig contracts and addresses in Bitcoin and Ethereum


Multisig contracts in modern decentralized networks are a powerful tool that allows you to simply and reliably protect funds in collective accounts, as well as conduct transactions with several participants. If you are interested in how to use such addresses, then you simply have to understand the mechanics of owning them and are well aware of the order of transactions. To work with such addresses requires the participation of multiple accounts.


Despite the same name and similar logic of operation, internal algorithms and ways of interacting with addresses protected by multi-signature are quite different in Bitcoin and Ethereum. It is about this internal device and will be discussed in this article.


We will talk about two networks: Bitcoin and Ethereum. In other blockchains, multisig-access to cryptoactive assets can be implemented completely differently.


Introduction


Suppose we have the task to protect against unauthorized access funds at the address (account, if you are closer to banking terminology), where the money of the organization is stored. Access to the address (the ability to create a transaction from it to an external one) is available for several people, for example, Gender, Findir, and the chief accountant. To protect money, if someone from this trio is forced to sign a withdrawal, there is multisig. In Bitcoin and Ethereum, you can create an address, the withdrawal of funds from which requires not one, but several confirmations.


Now, each of the three participants, wanting to create a transaction for withdrawal, must provide his signature, confirming his agreement with the transaction. When enough signatures are gathered, the funds are transferred. This logic is called multisig: sending N from M signatures (M> N) to confirm the operation.


For decentralized networks, multisig is a native pattern, since any valid transaction sent to a certain address, by design contains an electronic signature created by the sender's secret key, so almost all the functionality needed for multisig addresses is on board most modern blockchains.


The most interesting is the simplest 2/3 multisig address, the output from which is possible only with the consent of two of the three participants. Such multisig is able to make convenient and safe many transactions with three parties and solve problems when two participants trust the third to judge them. Virtually any financial services that have a third trusted party are implemented using multisig 2/3. For example, let's take a letter of credit: the payer deposits money and cannot pick it up if he does not convince either the bank (where the purchase documents did not arrive) or the recipient (voluntarily) agree with this. The recipient will also not be able to pick up the money if either the seller does not give it back (on goodwill) or the bank does not report that the necessary documents reached him and he checked them. In the scheme, the bank service is obscenely simple: after seeing an agreement on the purchase of an apartment, instead of carrying the key of the cell in the vault, it simply sends the approve to the multisig address.


The tasks of accounting and payment services, too, to multisig 2/3: there it is often required that a third party decide whether a service is provided and in what extent. Multisig, where one of the three signatures belongs to an organization that ultimately decides whether the service was rendered or not (for example, to the court), means that the court, deciding in favor of one of the parties, simply signs its decision and sends the transaction, automatically unblocking the funds for the winning party. For B2C services such as Uber or AirBnB multisig, albeit implicitly, the main pattern of work: when the service is provided, it is the signature of the request that the service initiates sending the funds from the client to the driver or apartment owner.


In general, a conveniently implemented multisig is like a Kalashnikov assault rifle: cheap and cheerful, suitable for use at home and for millions of dollars in fees. And in the blockchain, all this is “without registration and SMS” (from the point of view of security, this, by the way, is a rather serious thesis, if you think about it).


We will consider two blockchains - Bitcoin and Ethereum. I must say that the internal structure of multisig in them is quite different, everything works differently. But let's not get ahead.


Bitcoin multisig


Bitcoin is actually not as simple as it may seem to many. Its design allows you to implement lightweight and at the same time very secure schemes for accessing funds. Well, add that, purely in my personal opinion, the structure and algorithms in Bitcoin are well thought out, optimal and simply beautiful. The standard translation of X bitcoins from address to address is just the default transaction type, the tip of the iceberg of Bitcoin's potential abilities. The default BTC transfer transaction is the simplest multisig 1/1 from the code point of view: to use X bitcoins from address a1, you need to attach an electronic signature to the transaction, created using a secret key that belongs to address a1. Let's look at the structure of the Bitcoin transaction and dig a little deeper how it works.


image


In Bitcoin there is a requirement: all BTC stored at some address is always spent entirely. That is, confirming its right to own the address, the transaction spends the entire balance, distributing it to several outputs. In real life, also leaving the difference between input'ami and output'ami miner as a commission, but for this article it is irrelevant.


Imagine the situation. Vasya received 50 BTC at the address. Vasya wants to send Petya 0,5 BTC. For this, he is obliged to spend all 50 bps. To get the "change", Vasya takes one input (50 BTC) and creates two outputs:



When they say "Vasya signs a transaction" - this is not entirely accurate for Bitcoin. Vasya signs all inputs in the transaction, and each input is a separate bitcoin address, and each of them needs a corresponding secret key. Suppose Vasya has three addresses to which three of his friends sent 0.1 BTC each. To spend 0.25 BTC, Vasya will have to sign three inputs (each with 0.1) and generate two outputs (0.25 for the recipient’s address and 0.05 for himself as change). Such a scheme allows, in particular, never to use the same address twice and return the change every time to a new one. Some wallets, such as Electrum, allow the owner to choose a strategy for re-using addresses, a more private (each time a new address) or a simpler one, but with permanent addresses (this scheme is more convenient if you resort to complex regular transactions). I remind you that the difference between the sum of inputs and outputs is at the same time a miner’s commission: simple and reliable.


Now, instead of “Vasya signs a transaction,” I say “Vasya signs input”. But I deliberately missed a few more points in order not to complicate the general scheme. The fact is that addresses in Bitcoin are not a public key in its pure form, but its hash (twice a hash with several service bytes and version, see Bitcoinwiki for details), that is, the sender does not even know the recipient's public key in a normal transaction. Therefore, Vasya, while signing input, aside from the signature itself, presents the public key to Bitcoin Script as well, thereby revealing it. Naturally, knowing the public key, you can easily generate a Bitcoin address.


In addition to the signature of the inputs, Vasya also sets a condition for each output, how to spend BTC from this particular output. But the “requirements” were given to him by the one who will receive bitcoins: it is his concern how he will spend his BTC. This is a very important point. The Bitcoin address contains a hash of the code that will decide whether to allow BTC to be spent from this address.


If you still look for analogies, then Vasya attaches data to each output'u (which was reported to him by those who receive BTC) that answer the question "What code and what data should return true for the signer to be considered the owner of this output?" . Here is another analogy for pythonists: you can imagine that each output contains a lambda function, which, executed by Petya, who provided the arguments, returns true or false. If true, then Peter can use output as input for subsequent transactions. In the default version, the program can take two arguments provided by Petya - the output signature and the public key - and verify the signature. If true returns, then Petya has the right to output and can spend it; therefore, the transaction is valid. Deeper within the scope of this article in Script, diving is optional, but highly desirable. By the way, the redeem script is the very smart contract, that is, the formal rule that the right to BTC passes from one address to another. Clients of the network process transactions, execute each script in each transaction, checking whether it is valid. If valid - valid and indisputable waste of bitcoins from a certain address.


Here is the first excellent article on this topic, I highly recommend reading it, the whole raw mechanism with examples on python is very well written there: Bitcoins the hard way: Using the raw Bitcoin protocol . And here's another one: Bitcoin in a nutshell - Transaction .


Let us return to the 2/3 multisig, noting that the usual transaction with bitcoin translation can also be considered as multisig 1/1. Suppose Petya wants Vasya to simply transfer BTC to him. Petya gives Vasya an address where the default script script has been stitched, and Petya can pick up bitcoins from this address by providing a standard signature verification code and the signature itself. Such "traditional" addresses in Bitcoin begin with the number 1 (one). Addresses in which the “unconventional” code is sewn up (checking multisig script) are called pay-to-script and start with 3 (triples).


Bitcoin allows us to create an address that will contain the hash of OUR OWN redeem script. After all, this is our problem, as we will later spend our BTC, rather than sending. We do not care who will transfer the bitcoins to the address, and it is important that when we want to spend them, we will have to provide the code corresponding to the address. That is, having asked to transfer my BTC to a pay-to-script address, I undertake to provide the script itself later, in a transaction using this input.


According to the documentation, for multisig, the following code is used:


----------------------------------------------------------- Pubkey script: OP_HASH160 <Hash160(redeemScript)> OP_EQUAL Signature script: <sig> [sig] [sig...] <redeemScript> -----------------------------------------------------------

( Continued article on script and multisig )


We need such a script so that all the necessary signatures are immediately represented in the waste transaction. If, for example, our multisig 2/3 contains the addresses of three participants (CEO, chief accountant and sysadmin) and secret keys for signatures are on their computers separately, then the sysadmin will have to form a spending transaction:



This is not a very simple way, but it allows you to use a computer as one of the signers, which is completely disconnected from the network and is guaranteed not to merge the secret key. In this case, the withdrawal of funds is quite “manual”, which is quite good for large amounts. XXI century, friends, it is now fashionable to put in a safe a null laptop without connecting to the network and with the only software installed - a Bitcoin wallet.


Ethereum multisig


The implementation of multisig in Ethereum is very different from that in Bitcoin due to the different design of the internal algorithms of the client network, but there are also parallels. In Ethereum, a special transaction of the type "create_contract" creates in the network an address to which a specific contract code is attached. This address also has an ether balance. If you send a broadcast there - the address "will take it to the balance." And vice versa, if you send a broadcast from the address, that one will be “removed from the balance”.


I immediately distribute several fairly accurate analogies for understanding a very simple and logical kitchen. If we forget about consensus and how nodes update the block chain, and consider the blockchain as an abstract repository, the contract placement can be compared, for example, with object instantiation, that is, the transformation of a class into a real object in RAM. In analogy, memory is the blockchain, and the class code is the contract code. After instantiation, the object (contract) receives its own address in the “memory”, and the network knows the interface to it, represented as methods described in the class.


Transactions arriving at the address in such a scheme are writer methods, they change the internal state of the contract object. Methods-readers, which simply read data from the state of the contract, any client of the network performs locally, because it is sure that its copy of the object is correct and is confirmed by the consensus of block-producers. It is also very important to understand that the contract code is executed when the miner “applies” the incoming transaction to an existing contract, and in our version simply calls one of the contract methods with the arguments nested in the transaction.


Well, since the contract has an internal state (the object fields in our analogy), it can implement multisig without the need to send signatures in one transaction. We create a contract, in it hardcodes the addresses of the signatories, when transactions arrive at the withdrawal - we transfer the contract consistently to the state of waiting for the required number of confirmations. If we are talking about multisig 2/3, everything might look something like this:



Depending on the implementation of the multisig contract, many things can be implemented in different ways. This applies to the storage of unfulfilled withdrawal orders, the timeout for withdrawal, convenient restrictions. For example, you can allow output of amounts up to a certain limit without a multi-signature and require confirmation if the limit is exceeded.


There are several options for the code of contracts multisig-wallets, you can easily find them. The most official of them is this . There are many more modifications of multisig-contracts, as well as contracts that are multisig, but do not even know about it, because any contract with several roles in the philosophical sense is multisig.


Conclusion


We reviewed the operation scheme of one of the most important building blocks for building complex contract systems and organizing multilateral transactions. Where is the easiest way to find multisig addresses live:



As you can see, on the blockchain these schemes are very technological and simple, so use them for your own pleasure and protect your crypto-wealth correctly.

Source: https://habr.com/ru/post/412675/

More articles:


All Articles