54. On Escrow and Multi-Signature Transactions
54
On Escrow and Multi-Signature Transactions
TRANSACTIONS requiring multiple signatures are built in to the Bitcoin protocol and can be used by escrow services. For example, three keys are involved, but only two of these are required to sign the transaction. In such case, one key is owned by the payer, the second by the payee, and the third by the escrow agent. When there are no disputes or conflicts, the payer and the payee sign the transaction so that the payee can receive the funds.
If there is a dispute, the escrow agent reviews the dispute and, after deciding for either the payer or the payee, signs the transaction over to whichever party the escrow agent has decided in favor of. This is analogous to a bank check that requires two signatures from any of three persons, in this case the payer, payee, and the escrow agent. Escrow services for Bitcoin transactions do exist today. The following three threads contain discussions related to how escrow could be handled and the implications of escrow to Bitcoin.
A proposal for a semi-automated Escrow mechanism
Posted by Olipro, July 30, 2010, 07:29:08 PM
So, the basic escrow works by two people working through a third party to exchange (usually money) for some other form of goods or services.
In a transaction where both people are honest, the escrow business can essentially be automatic since the buyer gets his goods and approves release of funds, only when there is a dispute does human interaction become necessary. Therefore, I propose the following system:
1) you create an escrow transaction for the amount, authorised by your key and containing the recipientâs key/ data etc this block cannot be claimed until a subsequent block is issued by the buyer to approve it, itâs also impossible for the buyer to reclaim it without the seller approving it to be returned.
2) it enters the network, gets verified and the seller sends the goods, once the buyer gets them, he creates a release transaction and the seller gets his bitcoins.
3) if a dispute occurs and both parties are refusing to release the money one way or the other, clearly itâs now necessary to get a third party to arbitrate in this situation, a signature from both the buyer and seller authorising a third party is required which will give that third party ownership of the original escrow transaction and they can then arbitrate the matter.
Re: A proposal for a semi-automated Escrow mechanism
Posted by satoshi, August 05, 2010, 06:08:30 PM
A transaction can be written that requires two signatures to spend it next. You write a payment that requires the signature of boththe recipient and the sender to spend it. To release the escrow,you give the recipient the signature for your half, or the payee can return it by giving you his signed half. Thereâs no mediator in this simple case. The recourse is to refuse to ever release it, essentially burning the money.
Re: A proposal for a semi-automated Escrow mechanism
Posted by satoshi, August 07, 2010, 08:04:59 PM
Quote from: jgarzik on August 05, 2010, 07:00:30 PM
Due to that recourse, it is unlikely to be used as an escrowmechanism : )
Really? Do you think people wonât be able to understand the benefit? (If your response is an argument that thereâs no benefit at all, I guess that will reinforce the case that people wonât be able to understand it.)
Here, Satoshi creates a specific thread regarding escrow handling.
Escrow
Posted by satoshi, August 07, 2010, 08:13:52 PM
Hereâs an outline of the kind of escrow transaction thatâs possible in software. This is not implemented and I probably wonât have time to implement it soon, but just to let you know whatâs possible.
The basic escrow: The buyer commits a payment to escrow. The seller receives a transaction with the money in escrow, but he canât spend it until the buyer unlocks it. The buyer can release the payment at any time after that, which could be never. This does not allow the buyer to take the money back, but it does give himthe option to burn the money out of spite by never releasing it. The seller has the option to release the money back to the buyer.
While this system does not guarantee the parties against loss, it takes the profit out of cheating.
If the seller doesnât send the goods, he doesnât get paid. The buyer would still be out the money, but at least the seller has no monetary motivation to stiff him.
The buyer canât benefit by failing to pay. He canât get the escrow money back. He canât fail to pay due to lack of funds. The seller can see that the funds are committed to his key and canât be sent to anyone else.
Now, an economist would say that a fraudulent seller could start negotiating, such as ârelease the money and Iâll give you half of it backâ, but at that point, there would be so little trust and so much spite that negotiation is unlikely. Why on earth would the fraudster keep his word and send you half if heâs already breaking his word to steal it? I think for modest amounts, almost everyone would refuse on principle alone.
Re: Escrow
Posted by jgarzik, August 07, 2010, 09:25:40 PM
Buyer not having recourse except burning the money will limit the utility, I think.
Re: Escrow
Posted by aceat64, August 08, 2010, 02:55:59 AM
Quote from: jgarzik on August 07, 2010, 09:25:40 PM
Buyer not having recourse except burning the money will limit the utility, I think.
Perhaps we could work in a way to do arbitration. If both the buyer and seller agree, the money can be diverted to a 3rd party. That person could then arbitrate and either return the money to the buyer, give it to seller or steal it (obviously youâd want to choose a trustworthy arbitrator).
Re: Escrow
Posted by jgarzik, August 08, 2010, 03:58:03 AM
Quote from: aceat64 on August 08, 2010, 02:55:59 AM
Quote from: jgarzik on August 07, 2010, 09:25:40 PM
Buyer not having recourse except burning the money will limitthe utility, I think.
Perhaps we could work in a way to do arbitration. If both the buyer and seller agree, the money can be diverted to a 3rd party. That person could then arbitrate and either return the money to the buyer, give it to seller or steal it (obviously youâd want to choose a trustworthy arbitrator).
Thatâs how online escrow operates today. Buyer and seller agree to let a 3rd party physically hold the money. Buyer and seller both agree to rules that the neutral 3rd party will follow, for transaction resolution / redemption. The neutral third party is the one who disburses funds to one party or the other.
This is a pretty decent overview: https://www.escrow.com/solutions/escrow/process.asp
Some people might choose to use the bitcoin-specific signed escrow method... but I think the âburn the moneyâ recourse serves as a incentive to avoid bitcoin escrow entirely, rather than an incentive to use bitcoin escrow honestly.
Re: Escrow
Posted by aceat64, August 08, 2010, 05:49:44 AM
I like Oliproâs suggestion is this thread: http://bitcointalk.org/index.php?topic=645.0
The buyer and seller both an equal amount of bitcoins into escrow and the seller canât retrieve both sets until the buyer signs off on it. Optionally if both parties agree the funds are returned to their original owners or both sets are transfered to an agreed upon arbitrator. I deviate from his suggestion that the arbitrator only have control over the buyers half, I think they should have control of both so that both parties still have a bitcoin stake in the issue.
Re: Escrow
Posted by jgarzik, August 10, 2010, 06:53:57 PM
Quote from: nimnul on August 10, 2010, 05:51:49 PM
The Satoshi solution is good, because if customer can take money back, it will be a big problem to sellers. See current situation with internet credit card payments and chargebacks. Chargebacks are major PITA for sellers, bitcoin must avoid that at all cost : )
Ask some real-world business owners if they want to tell their customers about the chance of the money being lost forever, unrecoverable by either party.
Re: Escrow
Posted by nelisky, August 10, 2010, 08:20:36 PM
Regardless of what the technical options are, I think that anescrow will always need to be, by definition, a trusted entity. I can see the automated workflow being easy enough when things go well:
⢠Buyer sends btc to escrow, stating the recipient address
⢠Seller sees btc in escrow, marked to send to his address
⢠Buyer can release funds to seller
⢠Escrow will automatically do so after x days
⢠Both parties can open a complaint
And thatâs all I would automate. When things go bad, both parties should have a fee to pay to the escrow (that fee may be paid in advance to open account there?) so everyone looses something. Then the escrow will just have to mediate.
Because thereâs a fee *and* a human intermediary, the chances of successful fraud will probably not be economically interesting in the long run. Someone already trusted would make the ideal person for this, and maybe for a small fee some of us âcommon guysâ could help assert allegations from either side, if we are local to them.
But the money burning solution, while great at preventing economically viable fraud, does nothing to prevent revenge and actually makes everyone loose if one side is dishonest. I would certainly not endorse that.
Re: Escrow
Posted by satoshi, August 11, 2010, 01:30:02 AM
Quote from: jgarzik on August 10, 2010, 06:53:57 PM
Ask some real-world business owners if they want to tell their customers about the chance of the money being lost forever, unrecoverable by either party.
That makes it sound like it might somehow get lost and the parties canât get it even if they want to cooperate.
When you pay for something up front, you canât get it back either. Consumers seem comfortable with that. Itâs no worse than that.
Either party always has the option to release it to the other.
Quote from: nelisky on August 10, 2010, 08:20:36 PM
But the money burning solution, while great at preventingeconomically viable fraud, does nothing to prevent revenge and actually makes everyone loose if one side is dishonest. I would certainly not endorse that.
Then you must also be against the common system of payment up front, where the customer loses.
Payment up front: customer loses, and the thief gets the money. Simple escrow: customer loses, but the thief doesnât get the money either.
Are you guys saying payment up front is better, because at least the thief gets the money, so at least someone gets it?
Imagine someone stole something from you. You canât get it back, but if you could, if it had a kill switch that could be remote triggered, would you do it? Would it be a good thing for thieves to know that everything you own has a kill switch and if they steal it, itâll be useless to them, although you still lose it too? If they give it back, you can re-activate it.
Imagine if gold turned to lead when stolen. If the thief gives it back, it turns to gold again.
It still seems to me the problem may be one of presenting it the right way. For one thing, not being so blunt about âmoney burningâ for the purposes of game theory discussion. The moneyis never truly burned. You have the option to release it at any time forever.
Re: Escrow
Posted by ribuck, August 11, 2010, 11:13:12 AM
Quote from: Inedible on August 11, 2010, 01:52:53 AM
. . . Itâs just a shame thereâs nothing that can be done to mitigate malicious intent by offering to sell something, only to âburnâ the payment and never send the goods (assuming they even existed).
This would just be a case of spite but a very real threat none the less.
E.g.
A offers to sell laptop B offers to buy and escrows 2000 bitcoins A confirms that item is sent but never sends it B never receives it so never release the bitcoins A doesnât care because their intent was to make B âspendâ their bitcoins with no recompense
How about this:
A offers to sell laptop for 2000 bitcoins, and escrows 2500 bitcoins as security B offers to buy and escrows 2500 bitcoins A confirms that item is sent but never sends it B never receives it so never release the bitcoins A now cares because he has 2500 bitcoins in escrow as security
In this scenario, itâs in Aâs interest to send the laptop, otherwise he loses his BTC 2500 security. Itâs also in Bâs interest to confirm receipt of the laptop, otherwise he loses his BTC 500 âexcessâ.
The awkward situations are going to arise if both A and B are honest, but an uninsured delivery service loses or breaks the laptop, or if one of the participants dies before releasing the escrow.
And another thread surfaced later:
How to Make a Distributed Bitcoin Escrow Service
Posted by harding, September 26, 2010, 01:16:18 AM
Summary: Giving BitCoin a decentralized escrow would give it an advantage over all other exchange mediums, which might increase its adoption rate. Details follow.
For a decentralized currency, centralized escrows seem to be the norm for BitCoin today. An example:
Alice wants to buy $5 USD worth of BitCoins from Bob, but neither Alice nor Bob fully trust the other, so they go to a site they both trust--say Mt. Gox. There they deposit their respective monies and there they have Mt. Gox make the exchange for them.
No offense to Mt. Gox (a site I like), but can we do without its escrow service?
An almost distributed alternative:
Charlie, a trusted third-party, generates a BitCoin private key.
Charlie then uses the Unix command splitto split the private key in half--giving one half to Alice and one half to Bob.
Bob deposits $5 USD worth of BitCoins into the split BitCoin account;
Alice verifies the transaction using the public block; Alice sends $5 USD to Bob by PayPal;
Bob verifies the PayPal transaction;
Bob sends Alice his half of the split private key so Alice can access the BitCoins he deposited earlier.
(For simplicity I omit part of the PayPal details like who pays the transaction fee and how long you should wait to avoid chargeback fraud. I also omit any incentive for Bob to perform the final step.)
More advanced almost-distributed examples can be made if we substitute something more sophisticated for the Unix command split. For example: a Shamirâs secret sharing scheme implementation like ssss[1]. A utility like ssss allows Alice and Bob to appoint an arbiter in case they get in a disagreement.
The problem with all of this, of course, is that we must trust Charlie to not abuse the full copy of the private key he creates.
The ideal solution would be for Alice and Bob to each generate half of the private key on their own. I donât fully understand the math used in modern keypairs, but I doubt this is possible with the current algorithm.
Is there an alternative way for Alice and Bob to each acquire half of a private key without giving the whole key to any party?
âDave
[1] See: http://en.wikipedia.org/wiki/Shamirâs_Secret_Sharing
Re: How to Make a Distributed Bitcoin Escrow Service
Posted by satoshi, September 26, 2010, 05:34:26 PM
Itâs not implemented yet, but the network can support a transaction that requires two signatures. Itâs described here: http://bitcointalk.org/index.php?topic=750.0
Itâs absolutely safer than a straight payment without escrow, but not as good as a human arbitrated escrow, assuming you trust the human enough.
In this kind of escrow, a cheater canât win, but itâs still possible for you to lose. It at least takes away the profit motive for cheating you. The seller is assured that the money is reserved for him, while the buyer retains the leverage that the seller hasnât been paid yet until completion.
Last updated