Topic: Potential solutions for Escrow/Fraud issues (Read 3742 times)

I like the CoinSpeculator's idea.
It can be % that can be set from the client before the transaction.
There should be a trackbar that goes from 0.00% to 100%, or even it can be set manually ( ex: 120% )
So, it will be even possible that both buyers and sellers will need to put the same amount of Bitcoin to make the exchange.
If everything will go well, the seller will get back his own money and buyers money too.

I don't know if this kind of transaction ( with such a high % ) will ever happen/needed, but I think that the should be available on the client(s)

I am distinct from the op of any thread. Indubitably.

I meant the OP of that thread, who is of course distinct from the OP of this thread.

Might wanna relook who the OP is.

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.

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

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.

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.

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.

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.

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.

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.

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.

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

P2SH is discussed here:
https://bitcointalksearch.org/topic/pull-request-748-pay-to-script-hash-opeval-replacement-56969
https://bitcointalksearch.org/topic/old-p2sh-debate-thread-58579

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.

This discussion is relevant.

Did anyone read my reply?

Example, I am the buyer and I have this transaction already signed by the seller:
If I want to release the escrow, I sign it and publish it. The seller automatically get paid.

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)

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

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?