Quote from: belcher on October 11, 2015, 05:25:39 PM

So let's talk about the technical side of how this should work.

There are three entities: buyer, merchant and arbitrator.
...
Now for what happens if merchant is honest.

7. Merchant fulfills their end of the obligation by shipping the goods or services.
8. On the arbitartor's website, the buyer (or merchant) press a button called either Release Escrow or Receive Escrow Money. The arbitrator creates a partially signed transaction spending from the multisig addresses, going to the merchant and also a cut going to the arbitrator.
9. Merchant downloads transaction from arbitrator, either using http or copypasting.
A. Merchant's GUI examines the transaction, displaying to the user how much money goes to which identity. User presses Sign Off Payment which signs and broadcasts it.

Might be better to not involve the arbitrator if the merchant is honest, ie:

- Original payment is locked with 2 of 3 multisig to buyer, merchant, arbitrator
- Buyer clicks "purchase received", sends a partially signed tx paying to merchant to merchant
- Merchant fully signs tx, collects payment

or

- Original payment is locked to *either* CLTV 7 days to merchant *or* 2-of-3 multisig to buyer, merchant, arbitrator
- Merchant waits 7 days for payment to clear and spends it

In the latter case, in the event of a dispute being raised within 7 days, the arbitrator and buyer probably would spend the payment to a 2-of-3 multisig with buyer, merchant and arbitrator, without a locktime escape so any evidence can be reviewed without a deadline. Or it could have a CLTV 60 day branch sending back to the buyer to provide a two-month deadline for the merchant to provide evidence that they actually delivered the goods. The more automated payment processing and dispute handling can be, the cheaper it can be...