Potential solutions for Escrow/Fraud issues

[bluefirecorp]

Didn't read most of the thread..sorry, but a problem I foresee.

Say I'm trading my 1000 bitcoins for something. The bitcoins are magically locked away, well..the guy tries to scam me, of course I don't release my half, but neither does he!

So, now I'm out of 1000 bitcoins, but he's not out of his object. What does this mean? Well, the scammer can use this against me and agree to unlock my half of coins for a small fee...

[1714100542]

1714100542

[1714100542]

1714100542

[1714100542]

1714100542

[1714100542]

1714100542

[1714100542]

1714100542

[DeathAndTaxes]

Didn't read most of the thread..sorry, but a problem I foresee.

Say I'm trading my 1000 bitcoins for something. The bitcoins are magically locked away, well..the guy tries to scam me, of course I don't release my half, but neither does he!

So, now I'm out of 1000 bitcoins, but he's not out of his object. What does this mean? Well, the scammer can use this against me and agree to unlock my half of coins for a small fee...

He could but his rep is ruined.  Now compare your same scenario without escrow.  You pay scammer 1000 BTC and he disappears.

Which is worse?  If mult-sig escrow a silver bullet that allows one to be careless with giants piles of coins?  No.  Is it better than the current 100% implicit trust required system?

[bluefirecorp]

Didn't read most of the thread..sorry, but a problem I foresee.

Say I'm trading my 1000 bitcoins for something. The bitcoins are magically locked away, well..the guy tries to scam me, of course I don't release my half, but neither does he!

So, now I'm out of 1000 bitcoins, but he's not out of his object. What does this mean? Well, the scammer can use this against me and agree to unlock my half of coins for a small fee...

He could but his rep is ruined.  Now compare your same scenario without escrow.  You pay scammer 1000 BTC and he disappears.

Which is worse?  If mult-sig escrow a silver bullet that allows one to be careless with giants piles of coins?  No.  Is it better than the current 100% implicit trust required system?

Just was pointing out a small flaw in the protocol, I think after a set amount of time on the coins, they should be returned to the host if the deal doesn't go through [both parties would see the time before they agree on it]. Then again, this leads to more security issues of people paying for goods and then not confirming the arrival of goods.

Really hard to do a system like this without a 3rd party to inspect each of them. If one of the parties are corrupt, the deal falls through and 1 guy gets screwed over anyways.

[DeathAndTaxes]

Just was pointing out a small flaw in the protocol, I think after a set amount of time on the coins, they should be returned to the host if the deal doesn't go through [both parties would see the time before they agree on it]. Then again, this leads to more security issues of people paying for goods and then not confirming the arrival of goods.

You can't see the problem with that?

Method A: coins locked forever without consensus
False transaction by buyer - buyer loses/gains nothing, seller loses coins
False transaction by seller - buyer loses coins, seller loses/gains nothing

Method B: coins returned to sender without consensus
False transaction by buyer - buyer gains product & coins, seller loses coins
False transaction by seller - buyer loses coins, seller loses/gains nothing

In the current method neither party GAINS anything by faking the transaction.  Yes they can make someone else lose but they don't gain.  In a coins return to buyer method the fake buyer can always win.  You create a game theory scenario where the proper way to play the game is not complete transactions as a buyer.

So untrusted buyers won't be trusted to use the escrow and thus make the escrow worthless.

[Xenland]

So not to fragment off but the reason why auto refunds can't be done is becuase the person that is supposed to recieve the refund has the other half of the "key" to commence an action(such as unlocking and sending back to wallet). Is this correct?

[DeathAndTaxes]

So not to fragment off but the reason why auto refunds can't be done is becuase the person that is supposed to recieve the refund has the other half of the "key" to commence an action(such as unlocking and sending back to wallet). Is this correct?

Correct.  It is the same reason the merchant won't "automatically get paid".  They need to sign off on the "forward" transaction also.

In a 2 party transaction both parties must sign the transaction even if it is obvious to the humans that they will want to sign it.  Granted some of this can be automated by the wallet.  You could get a popup "there is a half signed transaction to receive 50 BTC @ addresss xxx we control.  should we sign it to complete?  yes/no/more info".

[Matthew N. Wright]

Thanks DeathAndTaxes and everyone. I finally get that what I am proposing will require multisig adoption for it to work safely.

On that note, I hope that whichever implementation is adopted, that there is an escrow function also adopted that does not:

• require 3+ parties just to perform a single transaction
• there is no 'time limit' created on the transactions where all coins are returned (same thing as not having escrow at all)

[DiThi]

So not to fragment off but the reason why auto refunds can't be done is becuase the person that is supposed to recieve the refund has the other half of the "key" to commence an action(such as unlocking and sending back to wallet). Is this correct?

Correct.  It is the same reason the merchant won't "automatically get paid".  They need to sign off on the "forward" transaction also.

In a 2 party transaction both parties must sign the transaction even if it is obvious to the humans that they will want to sign it.  Granted some of this can be automated by the wallet.  You could get a popup "there is a half signed transaction to receive 50 BTC @ addresss xxx we control.  should we sign it to complete?  yes/no/more info".

Did anyone read my reply?

Example, I am the buyer and I have this transaction already signed by the seller:

This transaction sends 1 BTC to {seller}. To be valid, have this signed by {seller} and {buyer}.

If I want to release the escrow, I sign it and publish it. The seller automatically get paid.

[Meni Rosenfeld]

This discussion is relevant.

[CoinSpeculator]

A two party escrow would eliminate malicious fraud.  Surprised no one has mentioned it.

Ex:  I want to buy a FPGA miner for 100 bitcoins.

I put 100 in escrow.  The seller is required to put some amount, maybe 10%  along with mine in to escrow.  Range could be a sliding scale from 1% to 100% of the amount I put in escrow.  Escrow now contains 110 coins.

You would have to be a pretty rich jerk to maliciously scam people repeatedly.  Worst case scenario, untrusting buyers could demand 100% matching escrows for first time transactions.

[interlagos]

A two party escrow would eliminate malicious fraud.  Surprised no one has mentioned it.

Ex:  I want to buy a FPGA miner for 100 bitcoins.

I put 100 in escrow.  The seller is required to put some amount, maybe 10%  along with mine in to escrow.  Range could be a sliding scale from 1% to 100% of the amount I put in escrow.  Escrow now contains 110 coins.

You would have to be a pretty rich jerk to maliciously scam people repeatedly.  Worst case scenario, untrusting buyers could demand 100% matching escrows for first time transactions.

I like the idea by CoinSpeculator very much!
Is it possible with P2SH multisig approach currently being implemented?

P2SH is discussed here:
https://bitcointalk.org/index.php?topic=56969.0
https://bitcointalk.org/index.php?topic=58579.0

[DeathAndTaxes]

I like the idea by CoinSpeculator very much!
Is it possible with P2SH multisig approach currently being implemented?

P2SH is discussed here:
https://bitcointalk.org/index.php?topic=56969.0
https://bitcointalk.org/index.php?topic=58579.0

Yes.  Essentially you just have a transaction w/ 2 inputs (100% from buyer and x% from seller) and those funds require both keys (signatures) to transfer.

So buyer gets the product he creates a transaction sending all of funds (his 100% & sellers 10%) to seller and sign it.  Then seller signs it and transaction is complete.

For a refund seller creates a transaction returning the 100% to buyer and 10% to himself and signs it.  The buyer then signs it and the transaction is complete.

[DeathAndTaxes]

A two party escrow would eliminate malicious fraud.  Surprised no one has mentioned it.

Ex:  I want to buy a FPGA miner for 100 bitcoins.

I put 100 in escrow.  The seller is required to put some amount, maybe 10%  along with mine in to escrow.  Range could be a sliding scale from 1% to 100% of the amount I put in escrow.  Escrow now contains 110 coins.

You would have to be a pretty rich jerk to maliciously scam people repeatedly.  Worst case scenario, untrusting buyers could demand 100% matching escrows for first time transactions.

I like it.  I actually like it a lot.  Even a small counterparty deposit increases the cost of being a jerk.
In a "normal" escrow the buyer only stands to lose reputation and honestly some people don't value that very highly.  A small counterparty deposit ensures they lose BOTH reputation and financial stake.

[Matthew N. Wright]

A two party escrow would eliminate malicious fraud.  Surprised no one has mentioned it.

Ex:  I want to buy a FPGA miner for 100 bitcoins.

I put 100 in escrow.  The seller is required to put some amount, maybe 10%  along with mine in to escrow.  Range could be a sliding scale from 1% to 100% of the amount I put in escrow.  Escrow now contains 110 coins.

You would have to be a pretty rich jerk to maliciously scam people repeatedly.  Worst case scenario, untrusting buyers could demand 100% matching escrows for first time transactions.

That's a very interesting direction. Other than the annoyance of requiring that someone have something in order to give something, it does seem to fit all the criteria for a social solution to fraud.

I believe I'll support this.

Also, thank you DeathAndTaxes for contributing to this thread and helping myself along with others to understand the finer details.

[DeathAndTaxes]

That's a very interesting direction. Other than the annoyance of requiring that someone have something in order to give something, it does seem to fit all the criteria for a social solution to fraud.

Well if you already have significant reputation & trust it is unlikely you will need to put up a counterparty deposit.  Obviously is someone asks you for more of a deposit you are comfortable with you can not trade.  If it becomes commonplace it will be just another negotiating tactic so that both parties feel their risk is hedged.

Interesting thing is that you can use blockchain to facilitate order updates too.

1) Mathew wants to buy a rig from me from me.  We agree on a price of 150BTC.
2) Mathew wants to use escrow (smart idea) but I have little rep so he demands a counterparty deposit of 30 BTC.
3) I negotiate it down to 10 BTC which he accepts.
4) We create the transaction with 160BTC which requires 2 signatures to release.
5) Once I ship the product I sign the first half of a "paid" transaction (all 160 BTC goes to me) I include in the transaction the tracking #.

Now depending on how sophisticated Mathews's client is (and this doesn't exist yet) the block chain could notify him not just of the half signed transaction but decode the text message inside showing him "Hey mathew I shipped the rig.  Here is tracking #.  Be sure to sign your half once you get it".

The half signed transaction sits on his wallet until he either signs it or rejects it (the blockchain has no concept of reject, reject would simply hide that transaction).

Now this is one example but when people like me says Bitcoin NEEDS mult-sig to expand beyond uber-nerds this is why.  multi-sig allows users to replace implicit trust with stronger methods.

Issue: wallet can be stolen
Solution:  multi-factor wallets are much harder to compromise
How: multi-sig allows 2 factor signing (wallet + secondary key on smartphone for example)

Issue: seller can be scammer (trading requires implicit trust)
Solution: escrow
How: multi-sig allows a transaction to be "half completed" and frozen until consensus between buyer & seller is acheived.

Issue: online wallets can be scammers (mybitcoin)
Solution: variant on multi-factor wallet
How:  multi-sig allows wallet provider to retain 1 of the two private keys and the user passphrase is in realtime converted into the 2nd private key

Issue:  double spends can be dangerous but merchants want realtime processing
Solution: multi-factor wallet provides some double spend protection
How:  Since a spend requires wallet provider key (not just user key) a double spend would require both wallet & user.  If merchant doesn't trust user but trusts wallet provider (because say they are multi-million dollar company w/ real assets) then double spend by user alone isn't possible.

And the list goes on and on.

[CoinSpeculator]

After talking to a friend IRL about the two party escrow thing I realized there is nothing to stop the buyer from not releasing the money after the items arrive.

EX: I get items from seller, I'm already out my 100 bitcoins, and he's out 10 more, LOL!  I'm going to change my name and no one will never know that I'm a dick!

I think both sides would need a ~10% additional escrow to prevent all malicious fraud.  I think this is important especially for buyers as they will have far less reputation to verify and depend on compared to centralized merchants.

[Meni Rosenfeld]

After talking to a friend IRL about the two party escrow thing I realized there is nothing to stop the buyer from not releasing the money after the items arrive.

EX: I get items from seller, I'm already out my 100 bitcoins, and he's out 10 more, LOL!  I'm going to change my name and no one will never know that I'm a dick!

I think both sides would need a ~10% additional escrow to prevent all malicious fraud.  I think this is important especially for buyers as they will have far less reputation to verify and depend on compared to centralized merchants.

The reason I (and others) linked to past discussions is so that less time is spent reinventing the wheel. Take a look at this for example. Some more discussion occurred here.

[Matthew N. Wright]

After talking to a friend IRL about the two party escrow thing I realized there is nothing to stop the buyer from not releasing the money after the items arrive.

EX: I get items from seller, I'm already out my 100 bitcoins, and he's out 10 more, LOL!  I'm going to change my name and no one will never know that I'm a dick!

I think both sides would need a ~10% additional escrow to prevent all malicious fraud.  I think this is important especially for buyers as they will have far less reputation to verify and depend on compared to centralized merchants.

The reason I (and others) linked to past discussions is so that less time is spent reinventing the wheel. Take a look at this for example. Some more discussion occurred here.

Thank you for sharing Meni. Many of us are very new to these issues, and some of us (like myself) have already followed them but were not quite clear on some of the finer points.

I am glad to see everyone discussing this issue just the same.

[CoinSpeculator]

After talking to a friend IRL about the two party escrow thing I realized there is nothing to stop the buyer from not releasing the money after the items arrive.

EX: I get items from seller, I'm already out my 100 bitcoins, and he's out 10 more, LOL!  I'm going to change my name and no one will never know that I'm a dick!

I think both sides would need a ~10% additional escrow to prevent all malicious fraud.  I think this is important especially for buyers as they will have far less reputation to verify and depend on compared to centralized merchants.

The reason I (and others) linked to past discussions is so that less time is spent reinventing the wheel. Take a look at this for example. Some more discussion occurred here.

It appears you overly complicated the idea and no one in that thread had a clue what you were talking about.

[Meni Rosenfeld]

After talking to a friend IRL about the two party escrow thing I realized there is nothing to stop the buyer from not releasing the money after the items arrive.

EX: I get items from seller, I'm already out my 100 bitcoins, and he's out 10 more, LOL!  I'm going to change my name and no one will never know that I'm a dick!

I think both sides would need a ~10% additional escrow to prevent all malicious fraud.  I think this is important especially for buyers as they will have far less reputation to verify and depend on compared to centralized merchants.

The reason I (and others) linked to past discussions is so that less time is spent reinventing the wheel. Take a look at this for example. Some more discussion occurred here.

It appears you overly complicated the idea and no one in that thread had a clue what you were talking about.

This is ridiculous. Of the 3 people who posted after me in that thread:
remmy (the op) understood what I said, up to some technical details.
iamzill probably didn't understand. His loss, my suggestion solves his suggested failure mode and I explicitly addressed it.
BitOffer presumably understood what I suggested, as he referenced it.

My "overly complicating the idea" was written in a way that makes it precise who gets what in which conditions. It was designed to solve the problems raised earlier in that thread - some of which you will probably only realize after some more chats with your IRL friend.