Topic: Buyer-Seller Escrow Transactions (with or without 3rd-party) (Read 12309 times)

I wish to have both with/without 3rd party escrow in all of the services.

I know that this topic is a bit out of date, but just in case you are still interested in a P2P Fiat-BTC exchange, I wanted to post an update of our project and announcement for our crowd funding campaign which will end in a few days (on February 9th).

Bitsquare released an alpha version in December and it can be tested at our regular testing sessions with other traders (testnet).
Today 17:00 CET we have such a session. Feel free to join us on our IRC channel #bitsquare-trading on Freenode.
Further information can be found here:
https://github.com/bitsquare/bitsquare/wiki/Bitsquare-WAN-Parties

Regarding the crowd funding campaign:
We are using Lighthouse as decentralized crowd funding solution to iteratively fund the development of every milestone, leading to a fully functional version 1.0.
The funding goal is 120 BTC for the next milestone and the campaign ends in a few days on February 9th. 
Please visit our web page for more details:
https://bitsquare.io/crowdfunding

If you like to support that project please help us to spread the word.

Best regards,
Manfred

etotheipi,

what is the state of that project?

Is it possible the parties to an escrow could elect which party pays the fee? Or split it.

As for Bob's deposit adding a step:  I guess Bob-zero-deposit could remove a step if Bob posts his public key as part of his advertisement.  But Alice has to send Bob a message and receive confirmation from Bob that he's still selling the item, anyway.  Even if she expects 0 deposit from Bob, she doesn't want to dump her money into a 2-of-2 or 2-of-3 until she's sure that Bob hasn't already sold the item.

But arguably, if this all has to get dumped into a bunch of opaque binary transfers between clients.  At that point, I guess it doesn't really matter.  3 vs 4 is immaterial (right?). Unfortunately, networking is not my forte.  There's a reason I rewrote everything in Armory except for the networking (and of course, because it's big and scary).  I will have to defer the creation of the protocol to others, and then follow the implementation in Armory.  (like verifying a mathematical proof instead of proving it myself)

So, I think we're in agreement that the clients will have to communicate in some fashion.  How difficult will it be to setup the communication?  Will it require extra steps, such as one person sending the other their IP address?  Or an IRC name?    Then it sounds like the method we define in this thread will not be so sensitive to the number of "hops" unless each hop requires confirmation from the user.  But I think the client can be made to have the user click once what their preferences are, and then the client apply all operations in sequence as long as each step completes/verifies successfully.  If Bob doesn't sign the DISPUTE/MAD tx, the client will not broadcast the multi-sig, etc.    However, that comes with the risk that the client handshakes and processing sequence have a vuln in them...

So there's still questions about whether deposits are necessary (sound like yes, but may be 0% in some cases) and whether there is a LAZY_ALICE tx (sounds like yes, but need to have a dumb-user-capable way for Alice to MAD the money after Bob prematurely broadcasts it).

Yes, if Bob puts in a deposit it adds a step internally.

I think for this to have a reasonable user-interface Alice and Bob's bitcoin clients will need to communicate in real time.

My inclination is to add JSON-RPC methods to bitcoin-qt/bitcoind to support this, and not build it into bitcoin-qt's GUI (or at least not right away). I'm imagining Armory or little "let's make a deal" 2-party-escrow-apps that... Do The Right Thing.

Random UI thoughts:

Alice could be asked "How much do you trust Bob?"  and "How much do you think Bob trusts you?"  If an answer is "not at all" then propose an escrow that requires a substantial deposit.  If the answer is "a lot" then maybe no deposit is required. It'd be way spiffy cool if it was automagically tied into the #bitcoin-otc web of trust sytem...

(... more random thoughts: would IRC as the communication mechanism under the covers be a good or bad idea?  might be a convenient way to prototype...)

I'm imagining Bob gets the details of the proposed escrow and can either agree or disagree (maybe with a message to let Alice know what he WOULD agree to).

Etotipi (just cant spell your name):
>>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.

Its required to share personal information and/or transaction details if you want to have your transaction arbitrated. Its same everywhere, if you pay in cash IRL and you want to have the deal arbitrated you will have to provide personal/transaction details and sign a contract and much more. Same with a third party arbitration service, you will have to provide them with your personal details and transaction details.

>>which may involve contacting both parties and collecting documentation.

Not required. The goal of the voting arbitration scheme is that buyer and seller SHOULD provide documentation before executing the deal, and if the seller's information is incorrect, (for example if the buyer and seller agreed on 25BTC for 50$ on paypal and instead sends 10BTC and writes "want 50$ on paypal for this") seller should REFUSE transaction and let it go back to sender.




Its same IRL too. You can either pay in cash, but then if you are scammed, the cash is lost. Cash is also anonymous.
Or you can pay in bank card, and then if you are scammed, then transaction can be chargebacked by the bank, but card is nonanonymous.


Since "the bank" in bitcoin is all nodes collectively, I think a voting scheme is best here. In this way all nodes collectively decide if the transaction should be chargebacked or not. Then you really get a decentralized "bank" which can do escrow, arbitration and control the money flow.

You're right -- these days, sellers have incentive not to do shady stuff because they have a reputation, and likely have some degree of legal accountability because someone (usually the third-party) knows their identity.  Most of that is because sending money over the internet has always required a third-party.  It just so happens that in this case the third-party can arbitrate.

But Bitcoin is different -- the third party to hold the money is no longer necessary (or rather, it's the Bitcoin network).  So if you can find a way to eliminate the chance of needing arbitration, then why bother paying a third-party at all?  That is the Bitcoin way.  Of course, you won't eliminate it entirely, but I bet there's a way to reduce it enough for the MAD option to be like real MAD:  no one really ever uses it, but the threat that a party could use it is enough to keep people playing fairly.  

I think some combination of things Gavin and I are discussing add a lot of value for knowledgeable users, even if it's awkward and different.  For users that can't grok it, they can always just do it through the third-party, as usual.  

---

Gavin,

I just realized one complication -- the 2-of-2 tx (or 2-of-3) has to be created and fully signed before any of the spending tx can be created -- because they need the tx-hash for the 2-of-2 txout, which won't be available until all signatures are collected. That means I see a minimum of 4 "hops" for tx data:

(1) Alice contacts Bob saying "I'll buy this, here's some public keys"
(2) Bob creates the 2-of-2 tx (with SIGHASH_ANYONECANPAY), signs it and sends to Alice  (Bob can't create any spending tx until he gets Alice's sig)
(3) Alice signs the 2-of-2 and doesn't broadcast -- Creates and signs REFUND && LAZY_ALICE, sends to Bob
(4) Bob stashes REFUND and LAZY_ALICE, creates and signs DISPUTE/MAD and SUCCESS, sends to Alice

That's a lot of hops.  The nice thing is, Alice (who has the most money at stake) can hold onto the 2-of-2 and not broadcast it until she gets DISPUTE and SUCCESS signed from Bob.  That gives her a way to avoid locking her money until she at least has the power to MAD the money.

Sounds like there has to either be a third-party server to post data for each other to exchange, or direct-connect.  I don't like either idea.  It's a shame we finally have a way to send money conveniently, but no easy way to exchange all the data for this.  All solutions so far seem to be 80% solutions...

I see, so it's like a mutually-assured-destruction. If Bob's deposit is 100% of Alice's payment, that could work.


Usually with the backstop of bank chargebacks or some company such as ebay or amazon resolving disputes. Also, seller ratings? Even if it's anonymous, you can usually still know something which will indicate whether the seller is honest or not, or else decide whether a purchase is too much money to chance or not, or what your chances are getting a chargeback via paypal or whatnot should they defect.


Except maybe that. That's the problem with trying to do business by mutually assured destruction .

I don't think Alice being a miner is a serious consideration, though. In order to get all of her money back, she would need to own a serious chunk of the total hashpower and be able to find a block herself (with her dispute included without being transmitted) before nLocktime ran out. In order to get most of it back, she'd have to at least own a serious chunk of a pool, and hope that her pool mines the block with her 'Dispute' call in it. She's much more likely to burn the contract just to be a dick.

That's why Gavin suggests that DISPUTE is actually a send-100%-to-tx-fee.  Then no one gets the money, but it does get recycled.   And that's why I recommended deposits, so that both parties have a mutual incentive not to do shady stuff.  If it costs them money to be a dick, there will be a lot less dickery.


The part that you're missing is that the Bitcoin network is offering a dramatic improvement over something that happens all the time -- people trust completely random strangers over the internet, endlessly.   And for those people, one party has to assume all the risk: Alice sends money first, or Bob sends merchandise first.  

But now the Bitcoin network can act as very dumb-but-strict escrow and split some of the risk between the two parties that choose to trust each other anyway.  Perhaps because they wish to preserve their own privacy, or simply don't feel like registering with a third-party.   I agree that for "full 100% guarantee" you need a third-party. But that doesn't mean that there is 0% value in using the scripting capabilities of the network to improve the non-third-party case.

---

Gavin,

I still think a risk deposit is necessary here.  Even if DISPUTE goes to the miners, Alice may just be bitter that her new merchandise is crappy quality and issue DISPUTE to spite Bob.  She doesn't get any money back either way, so what does it matter to her whether Bob gets it or the miners get it?

By the way, another problem with it:  if Alice has a lot of mining power, it's very +EV for her to pull the DISPUTE trigger, since she's would get something back instead of nothing.

Alice and Bob sign a contract, Bob is to ship good X, Alice is to provide money. Bob holds 'Lazy_Alice', and Alice holds 'Dispute'. Bob ships the item and forwards the tracking number to Alice. Alice uses 'Dispute' to get most of her money back. What does Bob do?

I think you're wrong about Alice being the one taking all the risk. The symmetry lies in the fact that neither party is really getting any lower risk by such a deal, unless there's an asymmetry between 'Dispute' and 'Lazy_Alice' which would dump all the risk on one party or the other.

Trying to manage dispute resolution between two mutually untrusting parties without a third party is impossible. In the 2-of-3 case, as long as Alice and Bob are really both honest, they can sign for each other and finish the transaction. In the case that either Alice or Bob are dishonest, they cannot agree without arbitration (the money ends up in limbo). Given that the contract is only used where at least one party assumes the other may be dishonest, a 2-of-3 is absolutely required to resolve things if that does turn out to be the case.

I'm less concerned about miners not agreeing to it, than the complexity of making sure the arbitrary user has access to a miner that will do it for them.  Maybe it could just be a rule that most miners will adopt, but something doesn't sit right with me about most miners accepting conflicting zero-conf tx just by including a bigger fee.  Maybe zero-conf tx have very little value right now, but they'll have even less once anyone can start canceling their outgoing [zero-conf] tx on a whim...



The asymmetry is that Alice is the only one with anything at risk.  Maybe Bob is just bored and wants to laugh about people losing money, so he starts advertising stuff he doesn't actually have.  When the person commits money, he delays a bit, then broadcasts LAZY_ALICE.  Worst case (for Bob), he doesn't get anything and gets his laugh.  Best-case, Alice can't figure out how to DISPUTE, and Bob actually gets some money!  Sweet game! 

I mean, people could do this now, though it would catch up to them eventually.  With Bitcoin, it's a lot easier to hide your identity, so there's almost no risk for Bob to do this. 

And so I'm coming around to your point about complexity and awkwardness of something like a Bob-deposit.  I agree, the further we deviate from what people are already used to, the stranger and more-confusing it will be.  At the very least, if we were to do something like risk-deposits, bitcoin.org could have an education section so users have some trusted place to go when they say "wait? I have to put in money as the seller?  sounds like a scam!"



Yeah... I don't think anything is going to be easy about it, besides minimize the number of exchanges between parties.  Right now, I want to get anything that works, and let the knowledgeable users get their hands on it, play with it, break it, and figure out how it can be improved.   As you said, it'll be easier to know what people like when we see if they use it.

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:


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.

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.  

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?

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 [email protected] "
" 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.

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.

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://bitcointalksearch.org/topic/bitcoin-secure-chargebacks-with-votes-4856

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.

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.

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.