Buyer-Seller Escrow, with or without third-party

armory_escrow.md

Buyer-Seller Escrow, with or without third-party

• Author: Alan Reiner (Armory)
• Orig Date: 04 April, 2012 First Draft: Sorting out ideas, and event sequences, handling details like who signs what when and where change outputs and fees fit into the equation.

Example Transaction

Here's an example of Alice and Bob setting up the transaction. Bob posts an item on craigslist, knowing that unknown, untrusted Alice will try to buy it. In this case, Bob is the seller and will set the "Risk Deposit" (could also be "Escrow Deposit"). This can be negotiated by the buyer, but I expect that something like 15-25% would be standard and not a point of contention. Remember, buyer does not trust seller, and vice versa.

1. Bob makes craigslist posting identifying the item for sale, the price (20 BTC), and the desired "Risk Deposit" (20%)
2. Alice finds the posting and emails Bob saying "I'll buy it for 20 BTC, 20% deposit is fine, here's PubKeyA, and let's use a third-party Charles."
3. Bob agrees so he obtains a public key from Charles, and constructs a very wacky transaction: Inputs: (1) Bob 4 BTC (20% deposit) -- signed using SIGHASH_ANYONECANPAY Outputs: (1) 28 BTC to TwoOfThree(PubKeyA, PubKeyB, PubKeyC) (2) Bob's change output, if necessary
4. Note that this tx is invalid because it has 4 BTC inputs, but 28 BTC outputs. Bob sends incomplete tx to Alice (probably via BIP 0010, but after modification to include a way to specify P2SH scripts)
5. Alice verifies that PubKeyC belongs to Charles (if using third-party)
6. Alice creates a perfect-sized input of 24+fee BTC, adds it to the tx, signs and broadcasts (Bob's sig is still valid because of ANYONECANPAY)

Now there is 28 BTC locked up in the network requiring two-of-three signatures from Bob, Alice or Charles. This could be a 2-of-2 tx without Charles, but if one party disappears (before tx completion) the money will be locked forever.

Three possible outcomes:

• Everything goes smoothly, Bob creates "completion transaction": Inputs: 2-of-3 for 28 BTC and an optional fee input, Outputs: Bob 24, Alice 4. Signs and sends to Alice who signs and broadcasts

• Something went wrong, Alice needs a refund. She constructs tx: Inputs: 2-of-3 for 28 BTC and optional fee, Outputs: Bob 4, Alice 24.

• DISPUTE: Charles intervenes (or no one does and the money is locked until agreement)

  1. Charles contacts both parties, figures out who gets the money -- assume it's Bob
  2. Charles creates a Tx:
     Inputs: (1) 2-of-3 for 28 BTC (2) Optional tx fee Outputs: (1) Bob 20 (2) Charles 8
  3. Charles signs both inputs, sends to Bob
  4. Bob adds second signature to input (1) and broadacsts.

In this case, the "Risk Deposit" serves two purposes:

1. Guarantees that Alice has incentive to complete the transaction after she receives his merchandise, and adds incentive to the seller not to randomly back out and leave the multi-sig money stranded.
2. It's an already-included, equally-funded-by-both-parties fee, in case the tx needs arbitration.

A couple things to ponder:

• Someone had brought up the possibility that only the "loser" of the arbitration should pay, and the "winner" would get their risk deposit back. I'm not entirely sure I agree with this...
• If we can't use SIGHASH_ANYONECANPAY, then one party would have to supply the other party with an appropriate sized set of inputs and a potential change address, so that the other party can construct the entire transaction before signing. It may require an extra half-step, but also may not be too bad if this step is executed by software, anyway -- it's already producing a PubKeyA to send to Bob... it might as well also figure out an appropriate set of inputs and change address and forward that on. On the other hand, if the tx never executes, Alice just revealed some of his funds to Bob.
• Second-half tx fee could be included on the original amount: commit 28.01 BTC to the 2-of-3 to make sure you don't need extra inputs later just to pay it.
• Client software could integrate third-party services -- so the retrieval and verification steps for third-party, Charles, could be done in the software for you. This may be especially important, because if you do a lot of purchasing online, you may need to advance-register with the third party so that they know who to contact during arbitration...
• Message signing may become important here, especially for third-parties...
• In direct response to Gavin suggesting that "risk deposits" are awkward and confusing: I don't see a way without it. If Alice doesn't have a risk deposit, she has no incentive to complete the transaction after she receives the merchandise (besides being a good person). If Bob isn't required to put in a risk deposit -- he could have Alice create the 2-of-3 transaction (or 2-of-2!) with his address, and then he backs out and leaves the money stranded. Then Alice will have to pay Charles to help unlock the money. Or if it's a 2-of-2 -- it's just locked forever.

This process is complicated, but half of it is under the hood. A lot of it can be automated with a "simple" set of options and a well-thought-out interface.

I like the proposal, but in my opinion the "loser" of the arbitration should pay, and the "winner" would get their risk deposit back.

What about open a topic on forum asking for feedback?