Buyer-Seller Escrow Transactions (with or without 3rd-party)

[etotheipi]

I have posted a complete first-draft of how I would implement buyer-seller escrow if I had to do it right now in Armory.

https://gist.github.com/2305966

Luckily, I'm not doing it right now, and I think this could use some improvement & optimization.   I'll leave the bulk of the content on the gist page, but I have copied the "Things to ponder further..." section below:

• 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 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 PubKeyB to send to Alice... 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, Bob just revealed some of his funds to Alice.
• 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 Bob doesn't have a risk deposit, he has no incentive to complete the transaction after he receives the merchandise (besides being a good person). If Alice isn't required to put in a risk deposit -- she could have Bob create the 2-of-3 transaction (or 2-of-2!) with her address, and then she backs out and leaves the money stranded. Then Bob 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 think the number one priority to optimize is simplicity/usability at the UI.  I don't mind complicating stuff under the hood a bit to make it easier on the user.  But I do require a solution that would work without relying on third-party services being available (I think the solution should work for 2-of-2 tx, as well, and let users eat the risk of small tx getting locked).

[teste]

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

I prefer punish only the "loser"

Question: What about add an option to let users choose if only the "loser" is punished with the third party service fee or the two parts (seller and buyer)

[Haplo]

Whatever overhead fees are incurred are on the buyer, who is asking for the service. I don't think it's possible to do escrow without a third party, at least not one which would be acceptable to both involved parties. The best you could do would be to store the deposited money to a "virtual address" on the blockchain so that your third party can't just steal the money (unless he's already in collaboration with the seller).

On the other hand, for a proxy-seller like bitmit it might make more sense to escrow the money to a proxy account so that the proxy service can collect their fees as well as guarantee their own buyers against seller abuse. Escrow can't work without at least one trusted third party anyway, which is why amazon is so successful, since customers know they can get their money back most of the time even with an unrated seller.

[etotheipi]

Whatever overhead fees are incurred are on the buyer, who is asking for the service. I don't think it's possible to do escrow without a third party, at least not one which would be acceptable to both involved parties. The best you could do would be to store the deposited money to a "virtual address" on the blockchain so that your third party can't just steal the money (unless he's already in collaboration with the seller).

On the other hand, for a proxy-seller like bitmit it might make more sense to escrow the money to a proxy account so that the proxy service can collect their fees as well as guarantee their own buyers against seller abuse. Escrow can't work without at least one trusted third party anyway, which is why amazon is so successful, since customers know they can get their money back most of the time even with an unrated seller.

It's not so clear cut who pays for overhead fees.  If you consider credit cards, it's always been the seller.  If it's PayPal transfers, again it's the seller.  Why not here, too?

In the case of Bitcoin, the network can be the third party.  That's what the 2-of-2 version is:  both parties agree on the terms (that only further agreement from both parties will be accepted) and the network holds it until they're ready for disbursement.  Of course, even with good intentions, the death of one party or HDD failure could lead to un-recoverable funds -- which is why I wouldn't recommend it for any substantial value.  But if you're purchasing something for under $100, I think it's acceptable (and third-parties may not want to deal with small tx, anyway).

I highly recommend third-parties, but I think it should be possible not to use them.  And people who use silk-road would probably agree with me (though I am making no formal endorsement of silk road or drugs in general:  just an example of where executing transactions between untrusted parties may be desirable without a third party).

Plus, the benefit of using 2-of-3 is that there's a lower threshold of trust needed for the third-party -- there is no risk that they take the bitcoins and run.  They'd have to collude with the one of the parties to do that.  All that matters is that they are impartial to the two parties involved.

[teste]

Of course, even with good intentions, the death of one party or HDD failure could lead to un-recoverable funds -- which is why I wouldn't recommend it for any substantial value

Gavin proposal has something like:  if Alice is lazy for 30 days, it's the same of ok/agree

Etotheipi: what about your proposal?

[etotheipi]

Of course, even with good intentions, the death of one party or HDD failure could lead to un-recoverable funds -- which is why I wouldn't recommend it for any substantial value

Gavin proposal has something like:  if Alice is lazy for 30 days, it's the same of ok/agree

Etotheipi: what about your proposal?

The problem is, I don't think Gavin's proposal works.  His proposal relies on transaction replacement, which is not enabled on the network, and he admitted that he made an erroneous assumption about the way locked transactions work.   Specifically, Alice can get Bob to put the 20 BTC into one of these transactions, and then Alice just disappears without doing anything -- then after 30 days she gets the money.  Gavin had assumed that Bob can replace the transaction, but I don't think it's feasible (at least not without setting up an explicit agreement with a miner, which is way beyond usable in this case).  EDIT: and even then, I think the locked tx technically goes into the blockchain, so it couldn't be pre-spent even with a miner's help -- it would be final.

However, if an alternative can be made to work with existing, enabled features of the network, I'm open to it.

[Haplo]

It's not so clear cut who pays for overhead fees.  If you consider credit cards, it's always been the seller.  If it's PayPal transfers, again it's the seller.  Why not here, too?

The seller, who passes those fees onto the consumer either by higher S&H or by higher prices overall.

In the case of Bitcoin, the network can be the third party.  That's what the 2-of-2 version is:  both parties agree on the terms (that only further agreement from both parties will be accepted) and the network holds it until they're ready for disbursement.  Of course, even with good intentions, the death of one party or HDD failure could lead to un-recoverable funds -- which is why I wouldn't recommend it for any substantial value.  But if you're purchasing something for under $100, I think it's acceptable (and third-parties may not want to deal with small tx, anyway).

I don't see how that solves anything. If Alice wants to buy something from Bob for 10BTC, and Alice doesn't trust Bob to deliver and Bob doesn't trust Alice to pay, how does "the network" decide if Bob has delivered or not to know whether to sent the money to Alice or Bob? If Alice is "lazy", then Bob might have to wait until the contract n-locktime expires to get his money, which might be a long time. Worst case if the tx can't be finished without both parties signing it, then if Alice is lazy Bob might never get his money, and if Bob is crooked then Alice can't get her money back.

I highly recommend third-parties, but I think it should be possible not to use them.  And people who use silk-road would probably agree with me (though I am making no formal endorsement of silk road or drugs in general:  just an example of where executing transactions between untrusted parties may be desirable without a third party).

Plus, the benefit of using 2-of-3 is that there's a lower threshold of trust needed for the third-party -- there is no risk that they take the bitcoins and run.  They'd have to collude with the one of the parties to do that.  All that matters is that they are impartial to the two parties involved.

If you've figured out some magical way to do escrow without a trusted third party to settle disputes, I'd love to hear it, but it seems technically impossible to me. As I mentioned the best you're likely to do is to lock the money up on the blockchain so your third party doesn't need to be trusted to hold it, just to release it to the deserving party. That's really not much better than what's possible now, although it might streamline things a bit.

[etotheipi]

In the case of Bitcoin, the network can be the third party.  That's what the 2-of-2 version is:  both parties agree on the terms (that only further agreement from both parties will be accepted) and the network holds it until they're ready for disbursement.  Of course, even with good intentions, the death of one party or HDD failure could lead to un-recoverable funds -- which is why I wouldn't recommend it for any substantial value.  But if you're purchasing something for under $100, I think it's acceptable (and third-parties may not want to deal with small tx, anyway).

I don't see how that solves anything. If Alice wants to buy something from Bob for 10BTC, and Alice doesn't trust Bob to deliver and Bob doesn't trust Alice to pay, how does "the network" decide if Bob has delivered or not to know whether to sent the money to Alice or Bob? If Alice is "lazy", then Bob might have to wait until the contract n-locktime expires to get his money, which might be a long time. Worst case if the tx can't be finished without both parties signing it, then if Alice is lazy Bob might never get his money, and if Bob is crooked then Alice can't get her money back.

You're missing the point.  People buy stuff all the time, from other people they don't trust over the internet.  But for many transactions, they do it anyway, and just hope they don't get screwed.  This system makes it an order-of-magnitude safer to conduct these transactions.  No one gets any money (or gets their risk deposits back) until both parties agree.  Both parties have an incentive to complete the transaction smoothly and without issue.  It means that the seller can't send some super-shitty/incomplete product to the buyer knowing that he's already got the buyer's money.  The buyer doesn't have to send money to some random person on the internet hoping that he's going to ship some potentially-imaginary product.

I highly recommend third-parties, but I think it should be possible not to use them.  And people who use silk-road would probably agree with me (though I am making no formal endorsement of silk road or drugs in general:  just an example of where executing transactions between untrusted parties may be desirable without a third party).

Plus, the benefit of using 2-of-3 is that there's a lower threshold of trust needed for the third-party -- there is no risk that they take the bitcoins and run.  They'd have to collude with the one of the parties to do that.  All that matters is that they are impartial to the two parties involved.

If you've figured out some magical way to do escrow without a trusted third party to settle disputes, I'd love to hear it, but it seems technically impossible to me. As I mentioned the best you're likely to do is to lock the money up on the blockchain so your third party doesn't need to be trusted to hold it, just to release it to the deserving party. That's really not much better than what's possible now, although it might streamline things a bit.

You've missed a critical distinction here:  there's a difference between "escrow" and "third-party arbitration."  The escrow simply means that the money is held by a third-party that has no partiality towards either of the first two parties, and that there is an explicit agreement about the conditions under which the money will be released.  "Arbitration" means that the third party gets involved to solve a dispute, which may involve contacting both parties, and sorting out semi-truths to find out who the money should go to.  Typically, third-parties serve both roles.

In this case, the bitcoin network can be that third party escrow -- it is holding onto money for the two parties, and has instructions to release it only when there is a distribution agreement (spend tx) that is signed by both parties.  You're right, the network can't arbitrate it: but it can be trusted to be impartial and not steal the escrow fund.

In many cases, especially early in the multi-sig world, there may not be good third-party services that both parties agree on.  In that case, I'd prefer to use the network for escrow alone, than trust that some third-party the seller is recommending is truly impartial (super-common escrow fraud).  

As I said before:
(1) I only recommened this for small transactions, in which case the third-party arbitration may be more expensive than the transaction itself.  In lots of standard transactions, it doesn't even make sense to have a third-party, does that mean that we shouldn't bother at all?
(2) When neither party gets the money, they will (usually) find a way to agreeably resolve their own dispute so that the money does get unlocked.

[etotheipi]

ACK: I was responding to a message from teste... but those disappeared...  here was my response to his now-missing message

You guys are missing the point of 2-of-3 transactions, which was the whole point of P2SH/BIP16:  there are X coins held up in a 2-of-3 transaction.  It means that in order for those coins to be used as input for a new transaction, that transaction must have the signatures of 2 of the 3 parties.  Any party can propose how to distribute the funds however the heck they want, but they can't make it happen unless they get one other party to sign it.  

Let me say that in another way:  No one party has any control over the money whatsoever.  

-- The third-party can't "run with the money," because it would require transferring 100% of that 2-of-3 output to their own address, and neither Alice nor Bob would ever sign that transaction.  
-- Alice could decide he deserves a refund, but he can't execute it without getting Bob's signature (when he agrees that there was a problem with the shipment and he needs to be refunded), or getting the third-party signature (after it arbitrates and decides that Alice deserves a refund).  
-- Alice and Bob are both understanding people and recognize they both f***ed up and they should split the money:  that works too!  They create a tx spending 28 BTC, and sending 14 BTC to each of them (and the third party wasn't even necessary).

In all cases: the Bitcoin network is acting as an escrow service -- and it's conditions are release are: "Wait for further instructions that are agreed upon by any two of these three people."  

BTW: I'm not proposing that this is the only way to escrow in the BTC network.  I would like to see some kind of time-locked tx that prevents laziness, and doesn't give one party too much power.  But I don't know how it can be done when tx-replacement isn't enabled on the network.

[Gavin Andresen]

In all cases: the Bitcoin network is acting as an escrow service -- and it's conditions are release are: "Wait for further instructions that are agreed upon by any two of these three people."  

BTW: I'm not proposing that this is the only way to escrow in the BTC network.  I would like to see some kind of time-locked tx that prevents laziness, and doesn't give one party too much power.  But I don't know how it can be done when tx-replacement isn't enabled on the network.

I think it is really important that the bitcoins involved in failed escrows not be destroyed, but EVENTUALLY make their way back into the economy.

So I'd really like to see network and client support for having both people pre-sign and hold on to a transaction with a far-in-the-future lockTime (maybe as a fee-only transaction).

[teste]

Hi etothepi,

Thanks for the post, it's very clear to me now. I deleted my post because was not sane.

My fear with both buyer and seller pay charge fee is that this could estimulate a market where bad people linked in any way with
 malicious third party services could realize escrows with the only purpose to generate a dispute and profit with it.

Third party service:
 1- Decide in correct way who win. (So will have good reputation).
2- Refund the bad person.
3- Profit from the good person

[etotheipi]

In all cases: the Bitcoin network is acting as an escrow service -- and it's conditions are release are: "Wait for further instructions that are agreed upon by any two of these three people."  

BTW: I'm not proposing that this is the only way to escrow in the BTC network.  I would like to see some kind of time-locked tx that prevents laziness, and doesn't give one party too much power.  But I don't know how it can be done when tx-replacement isn't enabled on the network.

I think it is really important that the bitcoins involved in failed escrows not be destroyed, but EVENTUALLY make their way back into the economy.

So I'd really like to see network and client support for having both people pre-sign and hold on to a transaction with a far-in-the-future lockTime (maybe as a fee-only transaction).

Gavin, I totally agree with you if it were possible.  But so far I'm not seeing how.  The locktime/replacement stuff is promising, but it doesn't answer the question of how to deal with it now.  It would probably be a long time before we could test it enough and roll it out.  Which is why I don't feel bad that I don't understand it too well... I have time.

As far as I can tell, even locked transactions are final, it's just that the outputs can't be spent until the lock time.  This means that once any such transaction hits the network, one party will get the money in the future if they just disappear and do nothing else.  And because it's final and in the blockchain, there's nothing else you can do to divert it. Obviously, we want to avoid that situation.  But I'm not seeing many other ways with the tools we have (besides keeping third-parties in the loop)

[etotheipi]

Just an update:  I talked with Gavin yesterday and we determined the extent to which transactions are "replaceable", which is more than I expected.

There are two locktime/replacement features of a transaction that would be used if full-replacement was available:  tx-locktime and per-txin-sequence number.  While replacement is technically "disabled", there is some logic in there that still triggers if you have non-zero locktime, and non-maxxed-out sequence.  See the bytemap for where locktime and sequence numbers occur in a tx.

The final conclusion was this:  If you create a transaction with a locktime in the future and with a non-maxxed sequence number, that tx will not be allowed in the blockchain.  It will be allowed into the blockchain after the locktime though (if seq is maxxed out, it will pass IsFinal() and be included in the blockchain immediately, though you can't spend the outputs yet).

However, even without it being in the blockchain, it will propagate and stay in nodes' memory pools.  This means that even though the tx is not in the blockchain, if it is broadcast, nodes will hold onto it and reject conflicting tx.   Therefore: locked-tx replacement is possible, exactly once, if you contact a miner and have them delete the locked tx from their memory pool and then include a new [conflicting] tx in their next block.   

However, I'm not entirely convinced that this is "usable".  In most of the scenarios where I can see this being used, there's too much reliance on being able to contact a miner to replace a tx.  And I wonder if miners should [ethically] be agreeing to just replace arbitary tx for users on a whim. I'm sure there's some deceptive practices Bad People will find.

Gavin, where is your original proposal on multi-sig/escrow?  I want to look at it again now that I understand what's actually possible.

[Gavin Andresen]

Gavin, where is your original proposal on multi-sig/escrow?  I want to look at it again now that I understand what's actually possible.

https://gist.github.com/830ca16758fb9ad496d7   : I created it as a 'private' gist because it is only half-baked.

RE: lockTime and the memory pool:

Note:  I'm using an "Alice pays Bob" scenario as described in the above gist:

If neither party is cheating, then the pre-signed DISPUTE  should NOT get broadcast until there really is a dispute. Instead, Alice and Bob's clients hold on to it.

So it is not in any miner's memory pools, and if there is no dispute nobody besides the two people involved in the transaction ever know about it.

Of course we have to assume that people WILL try to cheat, so the question becomes: what if Alice or Bob broadcasts DISPUTE prematurely?  Would anything bad happen?

I believe the answer is no, assuming Bob waits for transactions to be confirmed.  If DISPUTE is in "everybody's" memory pool, then any other transaction involving the escrowed funds will just be ignored. Even if Bob's client didn't see the DISPUTE broadcast (maybe he was offline) but later saw the SUCCESS transaction broadcast from Alice, SUCCESS would never be confirmed.

On the other hand, if not "everybody" has the DISPUTE transaction in their memory pool and Alice broadcasts SUCCESS, then it will likely be picked up by a miner and confirmed.  Once it is in a block, the conflicting DISPUTE transaction gets dropped from everybody's memory pool as a failed double-spend.  Given the churn in the nodes connected to the network, I expect this would actually be the most common case.

If Bob's client does see DISPUTE broadcast, it should probably let Bob know that Alice is unhappy and has disputed the transaction.

DISPUTE (which will be given a non-final sequence number) cannot get into a block until after lockTime.

All of the above is based on my best understanding of how the Satoshi code works right now; prototyping and experimenting on the testnet would be a good next step to make sure it actually behaves the way I think.

[sebastian]

I have a idea of how arbiritation can be done: With secure votes.
I have put a idea of a forum, but it didnt got any replies. Instead of writing the text again, Ill post a link to the thread:
https://bitcointalk.org/index.php?topic=4856.0

Basically, all opted-in members in the bitcoin network votes on how the transaction should end up, and all members are rewarded for voting correctly which means theres incentive for really verifying the details of the transaction and make sure arbitirating are done correctly.

[etotheipi]

Gavin,

I have nothing new to add except that I switched Alice and Bob on the gist I posted.  So now it should be consistent with your gist.  I'll continue pondering the replacement idea... I think it's acceptable, but we also need some way for a user to be able to submit a replacement tx without hiring a geek to help.  Getting help could cost more than the tx itself, and then Bob would just broadcast the LAZY_ALICE tx right away and get the money after 30 days knowing it's not worth it for Alice to try to figure it out.

Even if it's just another service that can be directly integrated or linked into the UI so the user has something to click to explore that option.  Presumably some big miners could setup some kind of service for this purpose, but I hate bringing even more third-parties into the equation. 

Plus, I'm not 100% fond of the idea that miners should be easily bribed to replace their memory-pool tx with different ones...


Sebastian,

I don't totally understand your proposal, but I don't see how or why the Bitcoin network, 99.9% of whom have nothing to do with this private transaction, should have any say in this.  I  *don't want* the network getting involved in my private affairs.

[sebastian]

If you read the thread, you will find that "secure transactions" are entirely optional, you can in other words select if you want to send a "normal" transaction or if you want to send a "secure transaction".
Because disputes of secure transactions disturb the network very much (by nagging all users that have selected to partipicate in voting with a popup or a message or what your client do), they will be very expensive, with a tx fee of 10BTC or something like that.

Basically, you send a transaction, AND in this transaction a message is written:
Examples:
" Nokia 3310 + shipping to blabla blablasson North Street 10A XXXX XX New York "
" 50$ on paypal acct blabla-paypal@hotmail.com "
" Custom homepage project with a green template, upload to FTP on www.yourhomepage.com "

Then, the receiver needs to approve the secure transaction (or he can refund it), with a response:
" Here is your 3310 on way: http://www.large-freight-company.com/tracking.php?track=US395359235628974 "
" Here is your paypal money. Did a print screen: http://www.image-host.com/paypal_print_screen.jpg "
" Here is your custom home page: http://www.yourhomepage.com "

THEN the sender of money now either approves transaction OR he "dispute" the transaction

If the sender now dispute the transaction, ONLY those that have selected in their bitcoin client to partipicate in arbitirating of disputed secure transaction, will get a popup in the bitcoin client:



You can then look at the evidence the receiver posted - in this case a screenshot of a sent paypal transaction, and then select to:
Defer the vote - which means you will not partipicate in this particular vote and not send out any votes.
Vote in favor to the sender - Your bitcoin client will compute "sender" vote and send out with PoW.
Vote in favor to the receiver - Your bitcoin client will compute "receiver" votes and send out with PoW.

And the outcome of the majority (where more CPU power = more votes) will decide which adress the money will go into.

[teste]

Hi sebastian,

Incredible I had this same idea, but I think the the way to decide where the bitcoins go should be something like:

1- People will have an option to select in their bitcoin client to partipicate in arbitirating of disputed secure transaction
2- Bitcoin client will choose in randomly order 11 ONLINE clients that market to participate in arbitirating...
3-  6 or + votes decide if bitcoins go to alice or bob.
4- The 5 ones that voted against will pay a fee.
5- The 6 majoritarians will receive the bitcoins of risk deposit mentioned on etotheipi idea.

Make sense?

[etotheipi]

I'm sorry guys:  it is not acceptable to have to share my personal information and transaction details with the entire Bitcoin network, or any subset thereof, just to have my transactions arbitrated.  If I'm going to pay anyway, I expect a privacy agreement and someone who will exercise due diligence in arbitration -- which may involve contacting both parties and collecting documentation.  I just don't think a random-user voting scheme is part of this solution.

There may be a place for it, but it's not a general solution to the problem we face here.  

[Gavin Andresen]

Getting help could cost more than the tx itself, and then Bob would just broadcast the LAZY_ALICE tx right away and get the money after 30 days knowing it's not worth it for Alice to try to figure it out.

Well, if DISPUTE is a fee-only transaction then miners have a VERY strong incentive to drop LAZY_ALICE and mine DISPUTE instead. I don't think we'd have trouble asking miners to support a code change that is something like:

If you get a transaction spending the same input as non-final (sequence number < max_sequence, lockTime in the future) transaction in your memory pool, then use the new transaction if it's got a (significantly) higher fee.

etotheipi, I've been thinking about your comment "I don't like the asymmetry" ...
LAZY_ALICE and DISPUTE are, I think, symmetric-- Alice holds DISPUTE in case Bob doesn't hold up his end of the bargain, Bob holds LAZY_ALICE in case she doesn't.  I proposed that DISPUTE have an earlier lockTime than LAZY_ALICE, but maybe that's not necessary.

If Alice really doesn't trust Bob, then I think the whole scheme also works if Bob puts a "good faith security deposit" of bitcoins into the mix.


The complexity of all this (5 possible transactions, different states the escrow can be in, initial communication to initiate the escrow) makes me nervous. Even just figuring out how Alice and Bob's clients talk to each to setup the escrow isn't obvious.