December 17, 2014 at 10:54Step-by-step instruction: deposit for transactions in bitcoin
- Tutorial
Bitcoin is very convenient and reliable for storing money, but how to conduct transactions in it? Traditional methods include engaging a trusted third party. It turns out that bitcoin is so powerful that it is not necessary. Below I will tell you how two people who do not trust each other can make a deal in bitcoin without involving third parties.
First, consider the existing methods.
Using this method, we rely on existing legal mechanisms to protect the seller and the buyer from fraud from each other. The principle of exclusion of third parties is violated, the possibility of anonymity is lost, transfer commissions are added. In addition, for the economy of bitcoins, it is better for transactions to be paid directly in bitcoin.
A guarantor is a third party trusted by both parties to a transaction. The buyer gives the money to the guarantor, the seller gives the goods to the guarantor, after which the guarantor gives the money to the seller, and the goods to the buyer. This scheme is also not particularly good. The reputation of the guarantor depends on the number of successful transactions, and the number of transactions grows with increasing reputation. It turns out a system with positive feedback, which leads to a reduction in the number of guarantors and centralization of the system, which I wanted to get rid of.
I lead to the fact that third parties in the transaction do not belong at all. There is a buyer and seller, there is a bitcoin system. On this self-sufficient system, banks, exchangers, lawyers, guarantors, etc., parasitize every now and then. But the bitcoin protocol already has everything you need to insure transactions.
The algorithm is very simple: both parties transfer money as collateral. If the transaction is successful, the pledge is returned, otherwise it disappears.
First we need to get acquainted with the concept of a multisig address . Charging money from a multisig address requires several signatures. Multisig addresses 2/2 and 2/3 are popular. In the case of address 2/2, two of the two signatures are needed, in the case of 2/3, two of the three signatures are needed.
The buyer and seller create a 2/2 multisig address and transfer the deposit there. None of them will be able to return the deposit without the consent of the other. After this, the transaction itself occurs (we assume that this is a purchase of goods or the provision of services for bitcoin). If the transaction is completed successfully (the buyer received the goods, the seller received payment), then the participants in the transaction withdraw the security deposit. If a conflict occurs during a transaction or one of the participants disappears, then both lose their bail.
The parties to the transaction depend on each other. The risk of losing collateral is no less powerful argument than the law on which ordinary transactions are held. Not everyone will stop before breaking the law, but no one will want to lose the pledge. In my opinion, money is the most powerful argument in the economy. It makes no sense to cheat if this obviously leads to losses.
For this scheme to work, the amount of the deposit must exceed the price of the goods. Otherwise, the party that will receive the goods or payment first may give up on the bail and the abyss. It seems to me that the amount of the pledge on each side should be 2 times the price of the goods .
Another pitfall: when one participant transferred the deposit to the multisig address 2/2, the second participant may disappear. It turns out an ugly situation: on the one hand losses, on the other nothing. Fortunately, bitcoin allows you to insure yourself against such unscrupulous customers or pranksters - transferring money to the 2/2 multisig address should be a single transaction signed by both participants. Either both will make a deposit, or no one will pay.
The final diagram looks like this:
Let the goods cost 1 BTC. Deposit: 2 BTC on each side.
This collateralized scheme is a “wrapper” for any transaction. Note that all overhead comes down to two bitcoin transactions (replenishment of collateral and return of collateral). If we take into account two more transactions replenishing the wallets involved in the transaction (see the “Preparation” section below), then all losses associated with the pledge are equal to 4 bitcoin commissions, that is, 0.0004 BTC (about 8 rubles at the current rate). If the transaction requires the personal presence of participants, then actions related to the pledge can be performed before and after a personal meeting. In addition, the parties to the transaction will be more comfortable at a personal meeting if they are already tied with a pledge, and not just strangers. The described method also works when the transaction does not require a personal meeting (example: a resident of one country transfers an intellectual product to a resident of another country).
The graphical programs that I checked do not provide a convenient interface for the two transactions described above (bitcoin-qt and Electrum programs). I decided to search for web solutions and almost immediately found a coinbin web client based on the BitcoinJS library . The client is independent of the developer's server and does not store keys remotely. In addition, coinbin can be downloaded and used locally or downloaded to your server. E-mail and password are used as seed to generate the address and are not remembered. To get several addresses, you need to use several pairs (E-mail, password). In order not to lose access to the wallet, you need to backup your E-mail and password, for example, in KeePassX .
I managed to complete the transactions necessary to insure the transaction. Below I will provide step-by-step instructions.
Now the money is pledged and you can proceed to the deal as such.
If the deal fell through, then both sides lose their bail. (This is the main idea - to force the other party to faithfully fulfill the terms of the transaction under pain of losing the pledge.) If the transaction was successful, then you need to return the pledge - this is possible only with the consent of both parties.
Money was transferred from the security deposit to the receiving addresses of Alice and Bob. The transaction is completed.
This algorithm helps to protect yourself from fraud, as in the case of this, both lose their bail. This protection does not introduce third parties, unlike traditional methods. There is almost no overhead, except for the need to understand the long algorithm and teach it the other side of the transaction. In fact, there is nothing complicated there: I needed to conduct a couple of “deals” with myself in order to fully get used to it.
Suggestions for improving the algorithm and software that automates the algorithm to a greater extent are welcome.
Developer GitHub: github.com/OutCast3k/coinbin
Bitcoin Developer Address: 1CWHWkTWaq1K5hevimJia3cyinQsrgXUvg
My Bitcoin Address: 1CsfihQGy5kg3nnTJLzfmNDiPGqiQgdeMz
UPD . Translation of this article into English.
UPD2 . P2P Bitcoin Exchange Project : www.coinffeine.com . Description of the work algorithm. As I understand it, the transfer is split into many small parts, which removes the risk of losing a lot of money, but has its drawbacks. Article about coinffeine in Russian. Thanks to danaki for the link.
First, consider the existing methods.
Convert bitcoin to regular money to buy
Using this method, we rely on existing legal mechanisms to protect the seller and the buyer from fraud from each other. The principle of exclusion of third parties is violated, the possibility of anonymity is lost, transfer commissions are added. In addition, for the economy of bitcoins, it is better for transactions to be paid directly in bitcoin.
Guarantor Attraction
A guarantor is a third party trusted by both parties to a transaction. The buyer gives the money to the guarantor, the seller gives the goods to the guarantor, after which the guarantor gives the money to the seller, and the goods to the buyer. This scheme is also not particularly good. The reputation of the guarantor depends on the number of successful transactions, and the number of transactions grows with increasing reputation. It turns out a system with positive feedback, which leads to a reduction in the number of guarantors and centralization of the system, which I wanted to get rid of.
How to conduct a transaction without a third party
I lead to the fact that third parties in the transaction do not belong at all. There is a buyer and seller, there is a bitcoin system. On this self-sufficient system, banks, exchangers, lawyers, guarantors, etc., parasitize every now and then. But the bitcoin protocol already has everything you need to insure transactions.
The algorithm is very simple: both parties transfer money as collateral. If the transaction is successful, the pledge is returned, otherwise it disappears.
First we need to get acquainted with the concept of a multisig address . Charging money from a multisig address requires several signatures. Multisig addresses 2/2 and 2/3 are popular. In the case of address 2/2, two of the two signatures are needed, in the case of 2/3, two of the three signatures are needed.
The buyer and seller create a 2/2 multisig address and transfer the deposit there. None of them will be able to return the deposit without the consent of the other. After this, the transaction itself occurs (we assume that this is a purchase of goods or the provision of services for bitcoin). If the transaction is completed successfully (the buyer received the goods, the seller received payment), then the participants in the transaction withdraw the security deposit. If a conflict occurs during a transaction or one of the participants disappears, then both lose their bail.
The parties to the transaction depend on each other. The risk of losing collateral is no less powerful argument than the law on which ordinary transactions are held. Not everyone will stop before breaking the law, but no one will want to lose the pledge. In my opinion, money is the most powerful argument in the economy. It makes no sense to cheat if this obviously leads to losses.
For this scheme to work, the amount of the deposit must exceed the price of the goods. Otherwise, the party that will receive the goods or payment first may give up on the bail and the abyss. It seems to me that the amount of the pledge on each side should be 2 times the price of the goods .
Another pitfall: when one participant transferred the deposit to the multisig address 2/2, the second participant may disappear. It turns out an ugly situation: on the one hand losses, on the other nothing. Fortunately, bitcoin allows you to insure yourself against such unscrupulous customers or pranksters - transferring money to the 2/2 multisig address should be a single transaction signed by both participants. Either both will make a deposit, or no one will pay.
The final diagram looks like this:
Let the goods cost 1 BTC. Deposit: 2 BTC on each side.
- Alice and Bob create a joint 2/2 multisig address that will be used to store the collateral.
- Alice and Bob together sign a transaction that transfers 2 BTC from Alice's wallet to a multisig address and 2 BTC from Bob's wallet to a multisig address.
- Actually deal:
- Alice provides Bob with services worth 1 BTC.
- Bob translates Alice 1 BTC.
- Alice and Bob take the security deposit from the multisig address to their wallets.
This collateralized scheme is a “wrapper” for any transaction. Note that all overhead comes down to two bitcoin transactions (replenishment of collateral and return of collateral). If we take into account two more transactions replenishing the wallets involved in the transaction (see the “Preparation” section below), then all losses associated with the pledge are equal to 4 bitcoin commissions, that is, 0.0004 BTC (about 8 rubles at the current rate). If the transaction requires the personal presence of participants, then actions related to the pledge can be performed before and after a personal meeting. In addition, the parties to the transaction will be more comfortable at a personal meeting if they are already tied with a pledge, and not just strangers. The described method also works when the transaction does not require a personal meeting (example: a resident of one country transfers an intellectual product to a resident of another country).
Practical implementation
The graphical programs that I checked do not provide a convenient interface for the two transactions described above (bitcoin-qt and Electrum programs). I decided to search for web solutions and almost immediately found a coinbin web client based on the BitcoinJS library . The client is independent of the developer's server and does not store keys remotely. In addition, coinbin can be downloaded and used locally or downloaded to your server. E-mail and password are used as seed to generate the address and are not remembered. To get several addresses, you need to use several pairs (E-mail, password). In order not to lose access to the wallet, you need to backup your E-mail and password, for example, in KeePassX .
I managed to complete the transactions necessary to insure the transaction. Below I will provide step-by-step instructions.
Training
- Alice and Bob open coinbin wallets
- They look at the keys, write down their private keys, tell each other public keys and addresses
- Make a deposit amount to their coinbin addresses (0.01 BTC each)
- Alice creates a multisig 2/2 address
- Selects MultiSig Address from the menu.
This form opens:
- Enters the public keys of himself and Bob into the form
- Writes down the received address and Redeem Script and passes them to Bob
- Bob checks Redeem Script
- Selects Verify Section
- Enters Redeem Script and checks public keys, address and Required Signatures = 2
Explanation : Bob knows his public address, and Alice received the public address in step 2. Bob receives the multisig wallet address from Alice simultaneously with Redeem Script. Required Signatures is the number of signatures required to complete an outgoing transaction from a multisig address. In this case, this number is 2 (participants in the transaction 2, the signatures of both of them are needed).
Deposit of money
- Alice prepares a transaction to multisig 2/2 (deposit replenishment)
- Select Transaction from the menu.
- Goes into additional options, unchecks Clear existing inputs ...
- Enters the first paying address (Alice) in Inputs
- Enters the second paying address (Bob) in the Inputs
- Enters multisig 2/2 address and the total amount of deposit minus bitcoin commission in Outputs
- Receives a Transaction Script and passes it to Bob for verification
- Bob checks Transaction Script
- Selects Verify Section
- Enters a Transaction Script and finds the multisig address and sum in Outputs
- Alice and Bob take turns signing Transaction Script
- Alice selects the Sign section
- Alice introduces Transaction Script and her private key
- Alice receives a partially signed transaction and forwards it to Bob
- Bob checks the transaction again and makes sure the destination address and amount have not changed
- Bob signs transaction(actions are similar to Alice's actions, but introduces a partially signed transaction)
- Bob checks the transaction again and makes sure the Signed column is checked everywhere.
- Bob selects the Broadcast section
- Bob enters Transaction Script and clicks Submit
Now the money is pledged and you can proceed to the deal as such.
Refund of money from a deposit
If the deal fell through, then both sides lose their bail. (This is the main idea - to force the other party to faithfully fulfill the terms of the transaction under pain of losing the pledge.) If the transaction was successful, then you need to return the pledge - this is possible only with the consent of both parties.
- Alice prepares a transaction from multisig 2/2 (deposit refund)
- Select Transaction from the menu.
- Deletes all inputs and outputs left from a previous transaction
- Enters Redeem Script in the first field (see the Preparation section)
- Enters the receiving addresses of Alice and Bob and the sums in the Outputs
- Receives a Transaction Script and passes it to Bob for verification
- Bob checks the Transaction Script (finds his receiving address and amount)
- Alice signs Transaction Script and hands Bob
- Bob checks the Transaction Script again (finds his receiving address and amount)
- Bob signs the Transaction Script and the result is broadcast
Money was transferred from the security deposit to the receiving addresses of Alice and Bob. The transaction is completed.
conclusions
This algorithm helps to protect yourself from fraud, as in the case of this, both lose their bail. This protection does not introduce third parties, unlike traditional methods. There is almost no overhead, except for the need to understand the long algorithm and teach it the other side of the transaction. In fact, there is nothing complicated there: I needed to conduct a couple of “deals” with myself in order to fully get used to it.
Suggestions for improving the algorithm and software that automates the algorithm to a greater extent are welcome.
Developer GitHub: github.com/OutCast3k/coinbin
Bitcoin Developer Address: 1CWHWkTWaq1K5hevimJia3cyinQsrgXUvg
My Bitcoin Address: 1CsfihQGy5kg3nnTJLzfmNDiPGqiQgdeMz
UPD . Translation of this article into English.
UPD2 . P2P Bitcoin Exchange Project : www.coinffeine.com . Description of the work algorithm. As I understand it, the transfer is split into many small parts, which removes the risk of losing a lot of money, but has its drawbacks. Article about coinffeine in Russian. Thanks to danaki for the link.
