Escrow

[ribuck]

Returning to satoshi's outline scheme:

...The buyer can't benefit by failing to pay.

The buyer can't benefit by failing to pay, that's true, but it's also true that the buyer has no incentive to "get around to" releasing the payment.

Suppose you send a laptop to a buyer. The buyer receives the laptop and forgets to release the payment, so you have to chase them up. Or the buyer says "yeah I got the laptop, but I need to check that it works OK before I release the payment". Then later they say "I'll release the payment if the laptop is still OK at the end of the guarantee period".

The seller is pretty-much powerless in this case, and the buyer has no reason to want to release the payment, other than their repuation. But if we're successfully tracking reputation, then why not cut the escrow out of this situation?

[1715071886]

1715071886

[1715071886]

1715071886

[1715071886]

1715071886

[1715071886]

1715071886

[imnichol]

I'm moving (slowly) towards setting up an escrow service.  I'm planning on building a database that will allow people to advertise how many successful transactions they have made.

[hippich]

Am I right in saying after step 3, both parties are committed and if either defaults, BOTH parties are on the hook for 2500?

Yes that assumption is correct. Both parties have a financial incentive to complete the transaction successfully. Forfeited escrowed coins could be burned, or could be used to fund the operation of the escrow service.

But yes, the ability to put your opposition out of business in a leveraged way makes the system unusable as I described it.

Let's see if this tweak works:

1. A offers to sell laptop for 2000 coins, and escrows 2500 coins as security.
2. B offers to buy and escrows 2500 coins as security.
3. B pays 2000 coins to A.
4. If A refuses to send the laptop, both A and B have lost 2500 coins. Therefore, A has an
     incentive to send the laptop, and B can't use this system to put A out of business.
5. A sends the laptop to B.
6. If B refuses to acknowledge receipt of the laptop, both A and B have lost 2500 coins.
     Therefore, B has an incentive to acknowledge receipt of the laptop.

What will happen if laptop is lost in transit and B do not believe A really sent it? =))

[trenton]

1. A offers to sell laptop for 2000 coins, and escrows 2500 coins as security.
2. B offers to buy and escrows 2500 coins as security.
3. B pays 2000 coins to A.
4. If A refuses to send the laptop, both A and B have lost 2500 coins. Therefore, A has an
     incentive to send the laptop, and B can't use this system to put A out of business.
5. A sends the laptop to B.
6. If B refuses to acknowledge receipt of the laptop, both A and B have lost 2500 coins.
     Therefore, B has an incentive to acknowledge receipt of the laptop.

It'd work, but it'd be tough to fit into commerce. You'd require businesses to have as much cash on hand as products shipped in a given day. Many small businesses don't have that cash cushion.

Even individuals could feel the pinch -- I'm not sure I'd want to convert $2000 USD to BTC to buy a $1000 computer ($1k used for escrow).

My personal opinion would be to keep any notion of trust away from bitcoin. It's cash. It can be spent, stolen, lost, defrauded, etc. The world has volumes of law to deal with issues of trust, fraud, and theft. If you don't trust someone to send what you buy, you probably shouldn't be doing business with them.

[sebastian]

I think its better to have the network vote about it instead.
So either the sender gets the cash back or the receiver gets the cash. Like a "real" escrow.

I wrote a thread about it: http://bitcointalk.org/index.php?topic=4856.0

Then its not possible to use the money as a "threat tool" either:
For example:

A sells a laptop without power adapter because A needs the power adapter to a new laptop.
B buys this laptop and in the business deal, its specific that power adapter is NOT included.
B then says "If you dont send the power adapter I will never release the money."

Now B is forced to send a power adapter to get the money for the laptop at all.
B will still lose the money even if A don't send any power adapter, but he still can force many extras from the seller for same money. And in this way fraud the seller.


With my solution with secure chargeback, it will never happen. B buys something from A. A sends the freight number as a reply to the transaction. If B now protest, everyone will be able to check at the freight'ers website that the parcel has really been sent and vote the transaction to A's favor. If the weight of the package seem illocigal, like a laser printer that weights 0,1 g, of course people will vote the transaction to B's favor.

[carp]

I think its better to have the network vote about it instead.
So either the sender gets the cash back or the receiver gets the cash. Like a "real" escrow.

I wrote a thread about it: http://bitcointalk.org/index.php?topic=4856.0

Then its not possible to use the money as a "threat tool" either:
For example:

A sells a laptop without power adapter because A needs the power adapter to a new laptop.
B buys this laptop and in the business deal, its specific that power adapter is NOT included.
B then says "If you dont send the power adapter I will never release the money."

Now B is forced to send a power adapter to get the money for the laptop at all.
B will still lose the money even if A don't send any power adapter, but he still can force many extras from the seller for same money. And in this way fraud the seller.


With my solution with secure chargeback, it will never happen. B buys something from A. A sends the freight number as a reply to the transaction. If B now protest, everyone will be able to check at the freight'ers website that the parcel has really been sent and vote the transaction to A's favor. If the weight of the package seem illocigal, like a laser printer that weights 0,1 g, of course people will vote the transaction to B's favor.

Neat idea but, in the end, it doesn't matter how you implement it, what matters is what the end properties are. In this case, as I understand it, you are proposing that an escrow transaction specify a number of "voters" who will arbitrate any dispute by voting for or against either side.

The incentive to vote with all the other voters is a bit of a perverse incentive, since, its not so much an agreement to do right, but to do what others do. There is actually a penalty for voting your conscience if you believe that that vote will be a losing vote. Whats the value in that?

Now it just comes down to he said vs she said. Bob can't prove that he gave Alice a laptop. He can show serial numbers, he can prove he bought one, he can even show video of him putting it in a box, putting her address on the box, and dropping it off at a shipping store front. Any of that could be faked, and none of it proves the full end to end transaction. For most transactions, this is simply not possible.

What I find nice about this 2 party escrow is the more level playing field. It puts the seller at a slight disadvantage, but, without putting the buyer at an advantage since they still have to spend the coins in the first place.

I wonder if a two way escrow makes sense... where one party escrows both to the seller and back to themselves, both of which can be verified, but you would have to have the second "insurance" escrow be at the seller's command to confirm.

Of course, that just opens up for the seller to scam, and pressure his victim to release the funds in order to cut his losses and at least get his secondary escrow returned.... but in the end, I don't think there is a true technological solution to the problem of cheats.

[sebastian]

carp: No, not in the transaction. Either you create a secure transaction or a normal transaction.
If you create a secure transaction, the receiver has to accept it and affix evidence of having sent the product.

Then if you select to dispute the transaction, *everyone* in the bitcoin network who has opted to do voting will vote. Its not a requirement to vote, even if you have opted to do so.

To give a incentive for unknown indivuals to investigate transactions, a reward will be given to those that vote correct in a secure transaction (where correct are defined as majority). To prevent that people vote at a random just to gain extra money, a little cost must be paid for each vote sent out. If you then vote correct, you get back this cost PLUS the reward. If you vote wrong, your cost gets into the reward pool to be shared to other voters who voted correct.

To prevent people just voting like majority, the votes could be hidden in some way until the vote is end, then they are revealed. Maybe someone can come up with a solution to this.

Its like http://www.phishtank.com which gives "reputation" to those that votes like the majority and gives dis-reputation to those who not votes like the majority.

And you can't fake the shipment number. Thats the power of the system. The trusted third party will in this case be the freight company in this case, since this is the only who can verify that a parcel has been sent. And almost 99% of shipment companies has a website where you can input a parcel number and find out if it has been shipped or not.

Fake sites like those people setting up phishing sites that looks like some freight company's site will of course be spotted and voted down.

[devrandom]

I wrote up a low-trust third-party escrow system in bitcoin, here:

http://bitcointalk.org/index.php?topic=4723.msg68804#msg68804

I think you are trying to create a reputation system.  Such a system would be nice, but is too much additional baggage for solving just this one problem.  If you already had a general p2p reputation system, applying it here would be appropriate.

[sebastian]

No not a reputation system.
Instead more CPU-power = more votes.
More correct votes = more money.
More incorrect votes = less money.

And the system is not based on reputation, rather that all nodes that have selected to partipicate in votes, gets the option to vote the transaction in favor to the receiver or in favor to the sender.


The reason is that using a escrow requires parties to atleast trust the escrow (in case óf devrandom's escrow system) not to release the funds if the seller is fraudulent (eg the escrow is not cooperating with fraudsters).
The vote system does not require any trust at all. And the vote system is protected by the same fundamentals that prevents double-spending. (Eg you need to control more than 50 % of the network to get through a fraudulent secure transaction)

[finway]

Since MultiSig and P2SH are enabled,
hope we can use this escrow transaction asap. 

[cbeast]

Are there any MultiSig tools or sites working yet?

[k99]

MultiSig page: https://coinb.in/multisig/

Our P2P Fiat-BTC Exchange is based on 2of2 MultiSig and that game theoretical approach:
https://bitcointalk.org/index.php?topic=462236

Basically the concept is sound, but there are a few weak points which are hard to solve:
- Blackmail
- Irrational attackers
- Unintended failure (hard disc crash, death,...)
- System attacker who does not care about costs

Reputation is probably inevitable as identity is leaked due the trade and will open up a blackmail attacks as well (defame other trader as scammer in forum,....).

[cbeast]

MultiSig page: https://coinb.in/multisig/

Our P2P Fiat-BTC Exchange is based on 2of2 MultiSig and that game theoretical approach:
https://bitcointalk.org/index.php?topic=462236

Basically the concept is sound, but there are a few weak points which are hard to solve:
- Blackmail
- Irrational attackers
- Unintended failure (hard disc crash, death,...)
- System attacker who does not care about costs

Reputation is probably inevitable as identity is leaked due the trade and will open up a blackmail attacks as well (defame other trader as scammer in forum,....).

Nice. I might try this first with a testnet client with test coins. I hope others will as well. Mostly I am concerned about the transaction size. I thought that was the limitation for only 3 signatures at the moment.

[k99]

MultiSig page: https://coinb.in/multisig/

Our P2P Fiat-BTC Exchange is based on 2of2 MultiSig and that game theoretical approach:
https://bitcointalk.org/index.php?topic=462236

Basically the concept is sound, but there are a few weak points which are hard to solve:
- Blackmail
- Irrational attackers
- Unintended failure (hard disc crash, death,...)
- System attacker who does not care about costs

Reputation is probably inevitable as identity is leaked due the trade and will open up a blackmail attacks as well (defame other trader as scammer in forum,....).

Nice. I might try this first with a testnet client with test coins. I hope others will as well. Mostly I am concerned about the transaction size. I thought that was the limitation for only 3 signatures at the moment.

Yes testnet is always a good idea ;-)

In my paper there are also doc linked with all the RCP calls and raw tx data, so you can see how multisig are created and handled on the RPC level.
Alice: https://docs.google.com/document/d/1o4Cwh709Vw_MLKuP8Dz6u7Qk_dmA5WJb0HUsvq1IBas
Bob: https://docs.google.com/document/d/1YhuIwjCl6AABfspS5VehQiDosxuvdtDjyVOvQkS4Eag

[last2come222]

I'm moving (slowly) towards setting up an escrow service.  I'm planning on building a database that will allow people to advertise how many successful transactions they have made.

That would be wonderful to have such service and watch your progress! Good Luck!