A proposal for a semi-automated Escrow mechanism

[Olipro]

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

[knightmb]

Basically a specialized bitcoind that the buyer sends a payment to and when everything is good, the buyer sends a special "all clear" message to that server that then knows to "release" what it has to whoever it's suppose to go to.

Programming wise, should be possible with direct IP payments for example, where the "From" and "Comment" fields can be used to "reserve" the BTC until later.

One could send a transaction and in the comment field put something like "Escrow=<public hash of seller> Amount=1000.00 Release=<some encrypted string>".

When the buyer gets the stuff and he/she is happy, they send a 0.01 payment to the same escrow server "Escrow=<public hash of seller> Amount=1000.00 Release=<some encrypted string>" and the server sees the match, knows it's ok to send payment to that address, for that amount, etc.

Very doable from a programming standpoint.

[Olipro]

Basically a specialized bitcoind that the buyer sends a payment to and when everything is good, the buyer sends a special "all clear" message to that server that then knows to "release" what it has to whoever it's suppose to go to.

Programming wise, should be possible with direct IP payments for example, where the "From" and "Comment" fields can be used to "reserve" the BTC until later.

One could send a transaction and in the comment field put something like "Escrow=<public hash of seller> Amount=1000.00 Release=<some encrypted string>".

When the buyer gets the stuff and he/she is happy, they send a 0.01 payment to the same escrow server "Escrow=<public hash of seller> Amount=1000.00 Release=<some encrypted string>" and the server sees the match, knows it's ok to send payment to that address, for that amount, etc.

Very doable from a programming standpoint.

kind of, the point of this system is that you can leverage the network for escrow transactions so long as everything goes to plan, thereby ensuring a low cost. in instances of dispute, you will pay a third party.

[Cdecker]

kind of, the point of this system is that you can leverage the network for escrow transactions so long as everything goes to plan, thereby ensuring a low cost. in instances of dispute, you will pay a third party.

I'd go too with websites offering escrow services. The network is quiet complex as it is, without having to add all the confirmation, delay and dispute stuff.
Currently when a transaction is broadcast it'll sooner or later be added to the block chain, what you are asking for is a mechanism to tentatively add a transaction and then dispute it later.
Also who do you think will be the third party moderating the dispute? There is no real advantage in adding it to the protocol itself.

[FreeMoney]

  what you are asking for is a mechanism to tentatively add a transaction and then dispute it later.

I don't think that's what he means. The transaction will be made completely, but both will hold part of the key required to spend that money. If they are satisfied they ship the money to the appropriate person. There is not disputing with the block chain. They either work it out and use the code like everyone else does for all transactions, or they don't work it out and the money stays locked up.

[Olipro]

  what you are asking for is a mechanism to tentatively add a transaction and then dispute it later.

I don't think that's what he means. The transaction will be made completely, but both will hold part of the key required to spend that money. If they are satisfied they ship the money to the appropriate person. There is not disputing with the block chain. They either work it out and use the code like everyone else does for all transactions, or they don't work it out and the money stays locked up.

if the buyer refuses to finalise the transaction and the seller refuses to permit a refund, they have 2 choices.

1) be spiteful and nobody will get anything

2) agree on a third party to send the money to. that third party will be an arbitrator who will weigh up both sides of the argument and come to a decision as to who should be returned the money, minus whatever fee they agreed with the two hurt parties.

Subsequent to this, I also realised that my suggestion is open to trolling whereby a seller makes someone do an escrow transaction and then refuses to ship anything or arbitrate, my solution to this issue gives the following modification of the system:

the buyer makes an escrow transaction which is then presented to the seller, if the seller wants to go ahead, they must agree to be debited a sum stipulated by the buyer, the seller agrees and the escrow transaction then goes into the network for inclusion into the block chain, both parties are now down on their money.

if everything goes to plan, the buyer OKs the release of the funds and the seller gets the payment + his "trust deposit" returned.

if the buyer wishes to cancel, the seller authorises the cancellation and both parties get their original funds back.

if nobody can agree on a release, both parties now have an incentive to go to an arbitrator, when the arbitrator is authorised to receive the transaction funds, the trust deposit gets immediately returned to the seller, the arbitrator doesn't get a say over those funds.

[satoshi]

A transaction can be written that requires two signatures to spend it next.  You write a payment that requires the signature of both the 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.

[Red]

A transaction can be written that requires two signatures to spend it next.  You write a payment that requires the signature of both the 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.

That is really quite clever!

Do you simply assign the transaction to two bitcoin addresses and transmit it to the network for inclusion in the block list?
Can you do more than two? Is it a one-or-more situation?

Is this feature in the GUI yet?

[jgarzik]

A transaction can be written that requires two signatures to spend it next.  You write a payment that requires the signature of both the 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.

Due to that recourse, it is unlikely to be used as an escrow mechanism

[satoshi]

Due to that recourse, it is unlikely to be used as an escrow mechanism

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.)

[Red]

I understand it! It adds value with a little risk.

If you did it twice at the same time, you would have exactly the "tear two $5 bills in half and swap halves" case.

That helps the risk cut both ways.

[Olipro]

Due to that recourse, it is unlikely to be used as an escrow mechanism

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.)

Yes, because that recourse open up the possibility of either victimising people who have grudges or simple trolling (just look at 4chan) ... a host of trolls will get buyers to do escrow transactions and refuse to release them because it costs them nothing to do so.

An effective automated escrow mechanism needs to disincentivise both parties from scamming/trolling.

[jgarzik]

Due to that recourse, it is unlikely to be used as an escrow mechanism

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.)

Existing mechanisms of online escrow (escrow.com, for example) provide more user-friendly methods of recourse.

I just don't think "burn the money" is an attractive recourse, nor a natural reaction, for the average human.  Ask any salesman to add that to their sales pitch, and gauge their reaction

[FreeMoney]

Due to that recourse, it is unlikely to be used as an escrow mechanism

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.)

Yes, because that recourse open up the possibility of either victimising people who have grudges or simple trolling (just look at 4chan) ... a host of trolls will get buyers to do escrow transactions and refuse to release them because it costs them nothing to do so.

An effective automated escrow mechanism needs to disincentivise both parties from scamming/trolling.

Buyer puts full amount in and seller puts 5% in, now it costs something.