Bitcoin Forum

Any problems with this?

If it works, it seems we could do away with escrow and centralized exchanges in many cases. A reputation system would only be necessary to keep out misanthropists who would pay to see some random, faceless person lose money.

https://i.imgur.com/Pqxal.png

Nice table. The main problem (as has been discussed for example here (http://bitcoin.stackexchange.com/questions/557/decentralized-escrow-functionality-built-into-bitcoin)) is blackmail - instead of doing step 5, trader B can tell trader A "I'll only give you the key if you pay me 50 BTC!". Assuming the threat is credible, A will have to part with 50 BTC to rescue the other 50. Even if most people won't give in to blackmail, if B's deposit is small he can try it on N people until he succeeds. This is alleviated if B's deposit is larger, but then A can blackmail him in step 6... You can make it work (with carefully balanced deposits and more sophisticated transactions), but it's not trivial.

For an alternative mechanism, see https://en.bitcoin.it/wiki/Contracts#Example_2:_Escrow_and_dispute_mediation - it involves a 3rd party arbiter, but the arbiter cannot steal (or lose) the funds without colluding with one of the parties, as long as the traders agree it doesn't matter what happens to him.

Yep, and a problem arises for people who use PayPal, reversible it is no matter if you use dual-key wallets or a gazillion-key wallet.

Either that or an escrow house/arbiter has to just come out and say "hey, this is who I really am" so there is recourse in the event of fraud.  I'm working on something along these lines, slowly and surely, where my real information will be posted as well as arbitration clauses involving judge.me (which are enforceable in court - hence they only have a <4% default rate).

For now, until a system of checks and balances can be put in place that supersedes traditional escrow, somebody is going to have to forgo the anonymous armor that bitcoin provides, and that someone is going to be the escrow house.

So you're saying it's more like this?

https://i.imgur.com/opCs9.png

Perhaps by adding some kind of (untrusted, mutually anonymous) third party, the incentive to blackmail could be reduced enough to be handled by a reputation system.

Also, I may be missing something, but wouldn't blackmail be impossible if the system ensures that Trader A and Trader B cannot contact each other or know who each other are except pseudonymously (preferably just identified by random numbers chosen by the system for reputation purposes)? No communication = no blackmail, right? Unless the fiat money side of it prevents this somehow.

Since this isn't a trivial problem and has a large possibility space that is hard to keep track of in your head, I'm thinking that using incentive tables or similar visual aids could help raise the overall level of insight on this and accelerate progress toward a solution.

Even if this is possible it sounds like such a system would be very limited. It definitely wouldn't generalize to arbitrary transactions (eg buying a product at an online store). And for currency exchange you have other methods such as Ripple-based exchange.

I like the tabular format.  It helps visualize what's going on here.

I recommend reading through the discussion between me and Gavin about this.  There's a lot of overlap with what you posted, but also some details that we already worked out that you're missing:  https://bitcointalk.org/index.php?topic=75481.0 (https://bitcointalk.org/index.php?topic=75481.0)

We referred to the "guaranteefee" as a "risk deposit", and it's something that both parties have to contribute.  It's the only way to make the remaining risk symmetric -- if everything goes smoothly, everyone gets their risk deposits back.  Until then, both parties have financial incentive to resolve the transaction agreeably.   Any off-nominal behavior could result in loss of risk deposit.  The size of the deposit can be set depending on the level of trust (or lack of) between the two parties.  20% might be agreeable for online sellers with reputations at risk, but 100% would be expected between two parties contacting each other on craigslist.

It is possible, with multi-sig and non-standard signature hashtypes, that the buyer can create a transaction including purchase price plus buyer-risk-deposit that is invalid until the seller commits his risk deposit to the same transaction (which will all go to the 2-of-2 "wallet").  It won't be valid until the seller commits a risk deposit of the correct size to the transaction.  In other words, either both parties get their money in at the same time, or no one does.  This is a prerequisite for any contract/escrow that requires money from multiple parties.

Also, I strongly disapprove of key-sharing, for any reason.  Also, it doesn't work if the money is ultimately split at the end  (Alice puts in (1+Risk)*X and Bob puts in Risk*X, and at the end, Alice gets Risk*X and Bob gets (1+Risk)*X).  When one party gives up their private key, there's nothing stopping the other party from taking 100% even if the two parties agreed to split it in some way.   Additionally, it is a potential security disaster for app developers to have to accommodate private keys for which it is epic-fail if they are revealed, but other keys are expected to be revealed.

This is why multi-sig was created (P2SH).  You create a wallet specifically for these types of escrow transactions.  Buyer and seller each generate the next private key in their wallet, and exchange public keys to create the 2-of-2 "address" to which funds will be committed.  At the end of the transaction, one party creates the payout transaction as they'd like to see it (usually (1+R)*X to Bob and R*X to Alice, but could also be a refund transaction, or some split due to wacky situations).  That party signs it with their private key and sends it to the other party.  That party verifies the distribution is correct, then signs and broadcasts it.  No one compromised any private keys, and P2SH was used to its fullest potential :)

This is easy to solve for many situations.

Trader a increase his sum that he can lose. And they both takes turn adding Bitcoins to the two part adress.

A ads 0.2 Btc.
B ads 0.2 Btc
A ads 1 Btc
B Ads 1 Btc.
etc.

If this can be automated it would be great but its not needed.

Now. Trader A not only do not have anything to win by blackmail.
But he even have coins to lose from doing Blackmail.

Now both have something to win by making sure the deal goes through.
Both have something to lose if the deal does not go through.

Problem solved.

 

No, it doesn't solve the problem. Being gradual maybe solves a problem with the OP's specific implementation (avoidable with better transactions). The hard part is what happens after everyone finishes depositing. Every party can hold the other ransom - with a successful blackmail he gets both his deposit back and some of the other party's. Having a large deposit means trying to do blackmail is more expensive, but also that more can go wrong.

It pretty much completely removes all incentive to blackmail as if one try to do so they will now risc the other party getting angry and thus, now instead risc losing their own money.

Looking at this with gametheory.
 
Knowing this, the other party will have no reason to let themselves be blackmailed.
Because if he does, how will he know he will get his money back?
He cant know that.
In fact the odds is he probably wont, since the first party by blackmailing has showed to not be trustworthy.

So the best option for him is to just dont care about the blackmailer and walk away.

Over several attempts to blackmail will thus in the long run lose his own money.

Its simply just better to not waste/risc effort trying to blackmail in this situation.

This basically solves the whole trading on internet problem and getting screwed for free,
for the first time in the entire history of human trade.

Is there another way to look at it?

We already said with a proper deposit/transaction structure you can alleviate the problems, enough to make this a powerful tool in practice. But they are hardly solved when:

 - You need to trust the other party not to lose their key.
 - The seller may not have available funds to use as deposit (if the deposit is large).
 - Even if it's not in their best interest, some people will still try to blackmail, and some people will still give in to it.

I've made arguments similar to yours in the past and I agree, I just disagree with the characterization as "solved".

I agree with Meni that this problem isn't exactly "solved", but most of the blackmail concern is mitigated with the two-way "risk deposits" I mentioned above.  The remaining asymmetry is only when one party values money much more than the other party (and doesn't mind losing a few dollars to screw over the other person).

The important part to remember about what I described: 
(1) Both parties contribute money to the 2-of-2 address  (both parties have money at risk)
(2) Both parties put their money in simultaneously  (either both parties are committed, or neither of them are)

Point 2 is important for the blackmail concerns:  if the Risk Deposit is 20%, the buyer can construct a transaction using "SIGHASH_ANYONECANPAY" that allows him to supply 1.2*X BTC to a transaction that has 1.4*X outputs.  This transaction is not valid, and no coins are committed until someone supplies the remaining 0.2*X.  If the seller does not put 0.2*X BTC into the transaction, then the transaction was never valid, and the coins never left the buyer's wallet.  So the only way for the seller to get the buyer to commit coins is to commit coins, himself.  If the two parties are mutually untrusted, 100% risk deposit should be used, so that the seller has as much at risk as he would otherwise gain by being a jerk.

As for the concerns about large transactions:  once transactions are big enough that the risk deposit becomes prohibitive, that's when third-parties should probably be involved as arbitrators (using 2-of-3 tx).  My primary motive is small transactions on the internet, for which getting third-parties involved would cost more than the transaction itself. 

The one thing Gavin and I didn't finish figuring out, was how to allow the coins to be recycled in case of not being able to complete the transaction agreeably.  Gavin proposed time-locked transactions for automatic movement of coins to the seller after some amount of time, but I didn't care much for that solution because one party could abuse it, and the other party would have to find a miner to help them to prevent it.  If time-locked transactions were officially enabled on the network, I think his solution would work, as long as the buyer's wallet app made it easy to replace a time-locked transaction that was broadcast by the seller prematurely.

Well agreed, solved was a to strong word. But I believe it will be "solved" for the majority 99% of trades.
For blackmailing, there should be better ways to blackmail, I might be wrong but I think it will with time become very unusual to use that kind of transaction to blackmail.

The lost key is a very small problem.
Would it be possible for both parties to somehow prove they have the key before and during the transactions to the adress.

If the seller loses the key he should still send to product.
It would be almost identical to the seller losing his own money after receiving them.

If the buyer loses the key he owns the seller his money back.
Both can be proven in court if identities are known.

Brainstorming I can imagine some kind of rescue/backup transaction that would "unlock" and rollback the first transaction if certain conditions were met which would confirm from both parties that a rollback would be ok.

I might be wrong but I dont see Bitcoin as the system for that.

Yes, proving you have a key is trivial, that's what message signing is for.

If there is a court to go to when there's a problem, why would you need this whole system? Yes, the loss scenario is less common and manipulable than a straightforward payment, but still.

Well, you can use an oracle (https://en.bitcoin.it/wiki/Contracts#Example_4:_Using_external_state) as a "3rd party" in the script. I don't know if it will be possible to have an oracle that is useful for this purpose, though.

Or each party can have a backup key, which is less protected (hence less prone to loss) and used in conjunction with an arbiter:
A & B || A & B2 & C || A2 & B & C
If the main key is lost, the transaction can still be completed with the backup key and the arbiter; if A manages to steal B2, he cannot complete the transaction without the arbiter; if A colludes with the arbiter, he cannot complete the transaction without stealing B2.