Escrow

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 him the 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.

Buyer not having recourse except burning the money will limit the utility, I think.

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.

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

Regardless of what the technical options are, I think that an escrow 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.