BANK RUN! - P2P Fiat-Bitcoin Exchange

[k99]

Maybe the following scenario has already been discussed in this thread, but I missed it:

Bob wants to sell his BTC to Alice so he sends his BTC and colleteral to the multisig address.
Alice agrees to the trade and sends her colleteral to the multisig adress to lock the funds.
Meanwhile the price rallies which is not uncommon for BTC so Alice has second thoughts about her commitment to Bob.
She decides to keep the funds locked up until prices have come down, after all only her colleteral is locked in the tx and she spend the fiat on something else.
...
Bob gets angry with this fancy new program and decides to hit the pub.


What I have described here is a common problem for low latency trades such as localbitcoin or similar. In times of heavy price movement many trades get aborted.
I think the issue could easily be fixed by higher colleterals according to volatility.

Yes the influence of price volatility is discussed in the paper.

Price volatility
A change in the BTC price will only affect Alice in the time period between publishing the deposit tx and starting her bank transfer. If she notice a price change against her favor (price falls, so she pays too much to Bob) she could decide to not continue and take in account to lose her collateral. The price change must be larger than the collateral to lead her to that decision. Assuming that the time period will be less than a few hours (to protect against double spend she should wait at least 1 confirmation or 6 confirmations to be totally safe -> 10 - 60 min.), it is not very likely that with an already low collateral of 10% (like in the example) the price change in such a small time span will exceed 10%.
But nothing prevents the parties to use a higher collateral in times of high volatility.

For Bob the volatility has no influence when he has the possibility to break the contract at the end of the trade. If he does not release the payment/refund tx he will lose his collateral. It does not matter if the value of the collateral is now less than it was in the beginning of the trade as long as it is more than zero.

[1714870178]

1714870178

[1714870178]

1714870178

[k99]

Interesting: Satoshi has planned a P2P market inside Bitcoin in his original version.

Here the source code:
https://bitcointalk.org/index.php?topic=68121

[FSCbitfan]

Hello fellow alt currency fans,
I was excited to see this well developed thread because I have the same concern about Bitcoin having all the fiat exits shuttered. I came up with an idea that differs markedly from this great looking proposal. My concept would preserve the general anonymity of both the buyer and seller on both ends.

There are probably holes a mile wide in my idea, but healthy discussion and discovery is what the forum is for.

Here are the notes I scribbled about my concept:

The idea is to do away with centralized exchanges like MtGox, Bitstamp, Btc-e, coinbase or anywhere that the opfor will look to shut down a BTC/Fiat exchange.

Use the alt coin wallets that all users have for the coins and add an exchange software.
1. Each user adds a Dwolla, Paypal, Bank, Western Union or any other money transfer account to the back end of their alt coin wallet. Same security applies with any API. 2FA or any level suggested by the user. This is open source code.
2. The user selects a percentage of their account or a set amount they are willing to exchange for a given time frame. For example, $300/month through Dwolla.
3. The user then becomes part of a network of pooled mini exchangers.
4. A person who wants to exchange alt coins or currency for alt coins then accesses a website that issues a one time wallet or account for them to send funds to. They do not know who the account holder is, nor does the other person know who they are, as they can send money by Western Union or other methods, possibly including deposit into ATM.
5. Then the network of mini exchanges, controlled by software, confirms the deposit and routes the exchange to the anonymous mini exchanges who then handle the transaction. For example, if a Fred wants to exchange 10 BTC for USD (crazy I know..), the network software would poll for the equivalent number of mini exchangers like Wilma, Barney, Dino and however many other mini-exchangers to combine for the total equivalent of $4670 in USD. Each mini-exchanger can either agree to complete their preauthorized exchange or cancel. The network would then go to option 2, 3, etc. This could also be completely automatic if a user/mini-exchanger wishes to honor all requests for exchange per their limits.
6. No one knows who is getting what from whom. Complete anonymity, as much as is possible.
7. Small or large amounts can be handled by combining many mini exchanges.
8. No one person or company to arrest, because everything is only small dollar amounts.
9. The person initiating the exchange sends their coin in to the address where the software would then distribute it to the mini exchangers. Upon confirmation, the software would complete the out exchange through the agreed intermediaries set-up by the mini-exchangers.

Just like we can send checks, ACH's, SWIFT payments, Western Union, Dwolla payments, paypal, etc. this system could disperse the payment process so everything appears to be from multiple sources without the central exchange as the bottle neck.

 

Whadya think?

[k99]

@FSCbitfan:
Interesting idea but i think that is hard to implement and will have a lot of open questions and problems.
- If anyone in that system handle money in behalve of another you are in the regulatory realm
- Dependency to those limited company who support automatic money transfers, they can be shut down or forced to limit those APIs.
- First we need to solve all the open problems in the most simple version (direct 1 to 1 exchange) before getting to that more complex version. But in future there is for sure more headroom for automatism. The Bank interface will be the weakest part always.

[FSCbitfan]

Thank you for the response K99!
I definitely do not want to hijack your thread, only contribute my ideas and help suss out possible solutions.

"Interesting idea but i think that is hard to implement and will have a lot of open questions and problems.
- If anyone in that system handle money in behalve of another you are in the regulatory realm
- Dependency to those limited company who support automatic money transfers, they can be shut down or forced to limit those APIs.
- First we need to solve all the open problems in the most simple version (direct 1 to 1 exchange) before getting to that more complex version. But in future there is for sure more headroom for automatism. The Bank interface will be the weakest part always."

The implementation would be "interesting" no doubt, but in the realm of possibility. After all, it involves linking current systems, not creating. Even if we do not use API's, we could use form robots.
1. I may not have explained my concept clearly enough. Some people allow their health club to debit their account a certain amount every month for their health club fees. Many clubs only allow this. Same goes for utilities. This proposal is for the same kind of possible access but on a software basis, where the exchange add-on to the wallet can open an API. We all handle money with others in normal transactions. These transactions will be small enough to not fall under the FinCen rules.
2. I agree completely. That is why there would be limits on the size of the transfers and frequency, to avoid alarms going off.
3. Definitely the right progression. I am learning PHP to work on this project because we need this distributed banking with network management or all the alt currencies are going to end up as curiosities and not viable means of value transfer. That is my fear.

I look forward to seeing how your great idea develops!

[daybyter]

As I said before (I think), I wouldn't develop it with PHP running on a server, but rather do it as an Android app running on smartphone. I don't have a lot of spare time at the moment, but I'm willing to help where I can.

[k99]

Btw: A basic www.bitsquare.io webpage is up. Wiki will follow soon....

[FSCbitfan]

Hey K99 and Daybyter,
Thanks for the responses. An Android app would be perfect and I agree that is probably a better way to go. Will read the paper and defer to the geniuses that put all of this in play initially.

[Vigil]

You need for a dollar/bitdollar exchange that keeps 1:1 reserve ratios and charges a fee for conversion from dollar to bitdollar and vice versa. their bank account would need to be public to guarantee they are maintaining proper reserve ratios. Once you have the bitdollars you can easily exchange them with bitcoin through decentralized "wallet" that also records and broadcasts each B$/BTC exchange and its ratio.

The value of each bitdollar is tied to the going market rate for dollars.

[Sukrim]

You need for a dollar/bitdollar exchange that keeps 1:1 reserve ratios and charges a fee for conversion from dollar to bitdollar and vice versa. their bank account would need to be public to guarantee they are maintaining proper reserve ratios. Once you have the bitdollars you can easily exchange them with bitcoin through decentralized "wallet" that also records and broadcasts each B$/BTC exchange and its ratio.

The value of each bitdollar is tied to the going market rate for dollars.

You're just describing Ripple here, not what the OP has in mind...

[k99]

You need for a dollar/bitdollar exchange that keeps 1:1 reserve ratios and charges a fee for conversion from dollar to bitdollar and vice versa. their bank account would need to be public to guarantee they are maintaining proper reserve ratios. Once you have the bitdollars you can easily exchange them with bitcoin through decentralized "wallet" that also records and broadcasts each B$/BTC exchange and its ratio.

The value of each bitdollar is tied to the going market rate for dollars.

You're just describing Ripple here, not what the OP has in mind...

Yes that is not what we have in mind. The main and hard problem it how to convert a crypto currency to real Fiat money not any colored coinn/IUO.
That is was we try to solve.

[johnyj]

Some experience from using localbitcoins

1. Reversable payment
Alice paid Bob and get the bitcoin, then she reverse the SEPA bank transfer

2. Stolen account
Alice using a stolen account to pay the Bob and get the bitcoin and then Bob's account is frozen by the banks after he released the bitcoin

3. Delayed payment
Alice paid Bob but Bob does not receive the payment in a week (Bank doubt that it is a bitcoin related transaction and intentionally delay the payment)

4. Future trading
Alice started the trade request but only do the bank transfer after the price rose

My experience is that person to person trading involves lots of fraud attempt from fraudulent buyers and sellers, even a well established trader can be fooled into some new type of scam

And as usual, liquidity and pricing is also a concern, you eventually need some large traders act as market maker to provide liquidity

[cjp]

I haven't read all the posts, so I'm not sure if this is a new idea, but I'd like to contribute the following attack scenario:

Suppose, in the last step, Bob does not publish the fully signed transaction. What then? A naive view would be that Alice would lose 1.1 BTC, and Bob would lose 0.1 BTC. However, that is only the outcome if Bob really does nothing.
What if, instead, Bob offers Alice the following:

Hi Alice.

I did not receive your $1000, but I believe your claim that you honestly sent
them. F*ing banks, eh? I suggest we split the losses, so that both of us
receive half of the BTC. I prepared the following Payment/Refund tx for you:

Input: 1.2 BTC (Deposit)
Output: 0.6 BTC to Alice
Output: 0.6 BTC to Bob
Bob has signed for spending the deposit

Your software may not have the functionality for signing this, so I prepared
some instructions for you [see attachment or URL] on how to sign this
transaction. This is the only method I can offer you to let you have your
0.5 BTC and your 0.1 BTC collateral.

regards,
Bob

If Alice is smart, she doesn't just believe this. But what can she do?

Alice could simply refuse to sign, but I think, at this point, both have equal bargaining power(*), so Bob can probably get away with about 50% of the output, at least in a part of the cases. For 1 BTC transfer and 2 * 0.1 BTC collateral, he can fund five collateral losses with one successful attack, when repeating the attack to different people.

Since Bob's success rate is a function of human psychology, I think the minimum collateral size is also a function of human psychology. If human beings are more or less rational and selfish, I'm afraid the collateral would have to be quite large, possibly even larger than the transferred amount.

Maybe here it's an advantage that the banking system isn't really anonymous: such a message can be used against Bob in a lawsuit. However, this means you'd need support from the legal system, which means that the scheme can be broken by governments, simply by declaring it illegal.

(*) In fact, Bob is in a better position, since Alice has already sent him a signed version of the "fair" refund transaction.

[waxwing]

I haven't read all the posts, so I'm not sure if this is a new idea, but I'd like to contribute the following attack scenario:

Suppose, in the last step, Bob does not publish the fully signed transaction. What then? A naive view would be that Alice would lose 1.1 BTC, and Bob would lose 0.1 BTC. However, that is only the outcome if Bob really does nothing.
What if, instead, Bob offers Alice the following:

Hi Alice.

I did not receive your $1000, but I believe your claim that you honestly sent
them. F*ing banks, eh? I suggest we split the losses, so that both of us
receive half of the BTC. I prepared the following Payment/Refund tx for you:

Input: 1.2 BTC (Deposit)
Output: 0.6 BTC to Alice
Output: 0.6 BTC to Bob
Bob has signed for spending the deposit

Your software may not have the functionality for signing this, so I prepared
some instructions for you [see attachment or URL] on how to sign this
transaction. This is the only method I can offer you to let you have your
0.5 BTC and your 0.1 BTC collateral.

regards,
Bob

If Alice is smart, she doesn't just believe this. But what can she do?

Alice could simply refuse to sign, but I think, at this point, both have equal bargaining power(*), so Bob can probably get away with about 50% of the output, at least in a part of the cases. For 1 BTC transfer and 2 * 0.1 BTC collateral, he can fund five collateral losses with one successful attack, when repeating the attack to different people.

Since Bob's success rate is a function of human psychology, I think the minimum collateral size is also a function of human psychology. If human beings are more or less rational and selfish, I'm afraid the collateral would have to be quite large, possibly even larger than the transferred amount.

Maybe here it's an advantage that the banking system isn't really anonymous: such a message can be used against Bob in a lawsuit. However, this means you'd need support from the legal system, which means that the scheme can be broken by governments, simply by declaring it illegal.

(*) In fact, Bob is in a better position, since Alice has already sent him a signed version of the "fair" refund transaction.

cjp,
Indeed you haven't read the thread I have gone to great lengths to argue this perspective on IRC and it has been repeated here in the thread. Although I have to say you make the point quite eloquently.

[k99]

I haven't read all the posts, so I'm not sure if this is a new idea, but I'd like to contribute the following attack scenario:

Suppose, in the last step, Bob does not publish the fully signed transaction. What then? A naive view would be that Alice would lose 1.1 BTC, and Bob would lose 0.1 BTC. However, that is only the outcome if Bob really does nothing.
What if, instead, Bob offers Alice the following:

Hi Alice.

I did not receive your $1000, but I believe your claim that you honestly sent
them. F*ing banks, eh? I suggest we split the losses, so that both of us
receive half of the BTC. I prepared the following Payment/Refund tx for you:

Input: 1.2 BTC (Deposit)
Output: 0.6 BTC to Alice
Output: 0.6 BTC to Bob
Bob has signed for spending the deposit

Your software may not have the functionality for signing this, so I prepared
some instructions for you [see attachment or URL] on how to sign this
transaction. This is the only method I can offer you to let you have your
0.5 BTC and your 0.1 BTC collateral.

regards,
Bob

If Alice is smart, she doesn't just believe this. But what can she do?

Alice could simply refuse to sign, but I think, at this point, both have equal bargaining power(*), so Bob can probably get away with about 50% of the output, at least in a part of the cases. For 1 BTC transfer and 2 * 0.1 BTC collateral, he can fund five collateral losses with one successful attack, when repeating the attack to different people.

Since Bob's success rate is a function of human psychology, I think the minimum collateral size is also a function of human psychology. If human beings are more or less rational and selfish, I'm afraid the collateral would have to be quite large, possibly even larger than the transferred amount.

Maybe here it's an advantage that the banking system isn't really anonymous: such a message can be used against Bob in a lawsuit. However, this means you'd need support from the legal system, which means that the scheme can be broken by governments, simply by declaring it illegal.

(*) In fact, Bob is in a better position, since Alice has already sent him a signed version of the "fair" refund transaction.

Yes you explained very clearly the only really dangerous blackmail attack which takes the advantage that one trader prepares a signed atomic tx. All other blackmail scenarios would suffer from the "who pays first" problem and results in a trust problem, where the blackmailer is in a bad situation as he has already lost completely his trustworthiness.

A solution for the scenario you described is that we create a 3of3 multisig address (instead the 2of2 MS) for the deposit tx and the 3rd kex is used to sign immediately the payment/refund tx and then DELETE that key.
That guarantees that the deposit can only be spent by this ONE AND ONLY prepared tx.
Any attempt to change the output settings is impossible as that 3rd key is not available anymore.
That solution has also its problems as you cannot prove the key destruction. But it would make a possible blackmail much less likely.

Another psychological issues is that Bob as blackmailer is acting aggressive and his identity is know to Alice. Even without the inclusion of the legal system he is risking something as he dont know how Alice will react (discussed in a previous post).

At the end the height of the collateral will be the key for fight all those blackmail scenarios (as you also mentioned).
The 3rd key idea will make it much less likely to succeed, even if it is not perfect as well.

I just updated the paper with that 3rd key protection idea under the chapter blackmail in more details.
https://docs.google.com/document/d/1d3EiWZdaM89-P6MVhS53unXv2-pDpSFsN3W4kCGXKgY/edit#heading=h.950d4t4cwl3q

At the end there will be no perfect secure solution possible. But also centraliced exchanges does not server perfect secure solutions. I guess everybody knows whom I mean.... :-)

We are currently going more in direction of a 3rd party escrow system with SSL dump for an unforgeable evidence for the bank transaction.

[erkki12]

To k99

Generally in the model there is presented the assumption of the rationally working self-interested trader, who sees his economical advantage to be the highest possible value. This is fine for me when thinking the larger userbase, but when thinking about the politically and otherwise motivated traders this raises some terrible concerns.

Now to think about that if this system would be used as the next gen, replacing 3rd party exchanges there could be serious inverse blowbacks due to politically motivated trades. Quote from the (white)paper:

Attack scenarios

Trying to steal from the other
Step 3. Alice publishes the deposit tx and does not send the Fiat money:
Alice will lose 0.1 BTC.
Bob will lose 1.1 BTC.
Both lose, make no sense to do that.
Step 4. Bob does not publish the payment/refund tx after he has received the Fiat money: Alice will lose 0.1 BTC + 1000 USD -> 1.1 BTC.
Bob will lose 1.1 BTC - 1000 USD -> 0.1 BTC.
Both lose, make no sense to do that.

Now you can see that a politically motivated trader could use his/her wealth in order to inflict 10x the damege to normal investors. By this a instance with 1,000 bitcoins in his/her disposal could do 10,000 BTC worth of damage to the image of BTC. Now I see this as a lottery ticket to the opposers of a decentralized banking system.

Quote from politically motivated attackers (from the paper):

For a political attacker costs may be less relevant. But we can assume that there will be cheaper ways for them to attack BTC (e.g. by laws) and the political cost of an exposure of the attack need to be considered as well (will be considered as an illegal action). So all in all it does not seems too likely that this will happen.

Now you have made the assumption that there are more cost-efficient ways for a politically motivated attacker to attack BTC. Please could you tell me on which data have you made this assumption based on. I present this question, because I respectfully disagree with you argument. It is known that only in the US lobbyists are spending hundreds of millions of dollars per year (see for example: https://www.opensecrets.org/lobby/top.php?showYear=2013&indexType=s) in lobbying. The link does not show the financial sectors amount correctly, but according to the bible of the modern age - wikipedia - " Wall Street lobbyists and the financial industry spent upwards of $100 million in one year to "court regulators and lawmakers", particularly since they were "finalizing new regulations for lending, trading and debit card fees" (http://en.wikipedia.org/wiki/Lobbying_in_the_United_States).


I would like to propose another simplified game-theoretical model of approach with different assuptions to this problem so you can see what I mean:

1. Lets start with the fact that we have a large banking sector in all over the world, which would see bitcoin as a competitor/threat if there is implemented a direct p2p trading mechanism.

2. This banking/finance sector is fundamentally based on the economy and capitals gained from ordinary people. Now assume that if these ordinary people would get a solution to "skip" the 3rd party (banks, etc) when moving currencies, assets to each other through this mechanism, they would. Now the financial institutions would lose profits when people would move to direct p2p exchange and thats why they would see it as a threat.

3. The banking sector spends at least a hundred of millions of dollars in lobbying.

4. The mechanism of p2p trading has the following "flaw" that can be abused in the following way. Because it is based purely on trust there is the possibility that when trading through the system an institution that would want to sabotage the credibility of the p2p currency transfer system could spend x amount of money to inflict at least 10x damage to users in the network.

5. Now imagine that 10 of the biggest financial lobbyists get together and spend 500,000 $ in order to damage the credibility of bitcoin. They do not need to make all the transactions in the system fraudilent. They would only need to make 10% of the transactions in the system fraudilent for, lets say 3 monts, and nobody would trust this system anymore.

6. Now why the attacker(s) would be able to avoid the legal consequences is due to the highly rigorous banking laws in certain countries which let the banks withdraw the information of the account owners. Also the possibilities of opaque transfers of capital inside multi-nationally working financial institutions can provide cover for this.

7. Now make the final assumption that comparing to the lobbying costs to ban bitcoin it could be financially beneficial to make this sort of attack is the direct p2p mechanism is implemented.

8. The above steps can only lead to one solution regarding the rationally motivated financial attacker: He will attack the p2p exchange system.

Now the scenario above can happen if the politically motivated attackers value the damage done to the system more that the capital spent on damaging it. I see that this is a real concern and through the above mechanism there can be a lot of damage inflicted to bitcoin in general. If this problem is not faced and made some countermeasures against it the p2p system will be left open to a politically motivated attack that could damage bitcoin hugely.

How do you feel about this?

[k99]

Some experience from using localbitcoins

1. Reversable payment
Alice paid Bob and get the bitcoin, then she reverse the SEPA bank transfer

2. Stolen account
Alice using a stolen account to pay the Bob and get the bitcoin and then Bob's account is frozen by the banks after he released the bitcoin

3. Delayed payment
Alice paid Bob but Bob does not receive the payment in a week (Bank doubt that it is a bitcoin related transaction and intentionally delay the payment)

4. Future trading
Alice started the trade request but only do the bank transfer after the price rose

My experience is that person to person trading involves lots of fraud attempt from fraudulent buyers and sellers, even a well established trader can be fooled into some new type of scam

And as usual, liquidity and pricing is also a concern, you eventually need some large traders act as market maker to provide liquidity

Thanks johnyj for your input!

Re 1:
The reverability is a real hard problem. I thought SEPA is irreversible. At least my bank told me that. It may lead to a smaller set of bank transfers types which can be considered as safe. Or we need a reputation system or other elements to mitigate that fraud risk.

Re 2:
Thats another hard problem. But I assume thats is a problem with all online services dealing with money. At Ebay can happen the same. That does not mean we take that serious.
One protection to minimize the possible problems is to not use the primary bank account but a dedicated one, so a block of the account will not cause so much troubles.

I guess the only possible solution for that would be to include a form of reputation system. Unfortunately there is no perfect solution to protect against sock puppets, but in reality it makes it more safe and more cost-intensive for the attacker.
An identity check would be another solution against that. The traders could use an off-system channel like a skype video chat to show some IDs like a passport to prove the identity. The privacy is leaked anyway by the banking transfer, so that would not introduce a new disadvantage. An identity check combined with reputation could also solve the first point (chargeback). But reputation has also the problem of false accusations, which could be used for blackmail... so any new feature to fix something introduce new problems....
We discuss a possible solution for a reputation system in the paper, but it is not elaborated too much yet.

Re 3:
I never heard about that. But as long the users dont mark those payments with something like "BTC payment txID:1234" it would be hard for a bank to track those payments. And if a bank gets too customer-unfriendly why not change the bank, there are a lot of free alternatives (OKPay, PerfectMoney,....). So the banks has also something to lose...

Re 4:
That will be dependent to the collateral height.
In our example it would be Alice who offers 1000 USD for 1 BTC.
1. Assume the price change to 500 USD/BTC:
Alice dont like to do the deal anymore as she would pay too much. But she will lose her collateral if she does not continue.
If the collateral is lower then the price change she has incentive to stop and perfer to lose her collateral.
2. Assume the price change to 2000 USD/BTC:
Alice is happy to have the contract for a great deal she get 1 BTC for 1000USD which is already worth 2000.
Bob would like to stop but he cannot. When he receive the Fiat, he could decide to stop, but he will always lose some BTC (collateral) independent from the price. Just if the BTC price goes close to zero he might lose his incentive to behave fair. But anyway it is never lost, it is just blocked, it price rise again the incentive might also rise to finalize the trade.

The time window for Alice between broadcastin gthe depost tx and starting the bank tx would be 10 min to 1 hour, depending how much security she wants against doublespend attacks from Bob.
So the price change must happen in that time window. A price change of more then 10% in one hour might happen but is a bit unlikely, also the whole trade is a slow process due the bank tx. It is not the daytrader/HF trading setup.
Of course she could wait longer but if she waits too long it will hurt her reputation (if we use that).

The collateral height will be the main influence for that attack scenario. A reputation system would help also (but is difficult as well).
A trading fee could make any attack also more costy (beside the cost of time and blocked collaterals).
The trading fee could be distributed as lottery to all successful traders (described in the paper as well). But again, every new feature introduce new problems....

The pure Nash based setup seems to be too weak to protect against all possible attacks.
We are considering a 3rd party escrow solution with SSL Dump now.
The fact that  the identity is known to the other due the banking tx leads to the need of a reputation system. If we don't offer any, the users will use something on their own (post scammers in a forum,...).

[k99]

Hi erkki12,

thanks for your input!

There are a few counter measurements, but none of them are perfectly safe (like in BTC as well with 51% attack,...).

First the 10% collateral is only an example, it can be choosen freely by the traders, so in times of higher fraud rate that collateral will be higher.
If you need a collateral of 10 BTC for a 1 BTC trade the asymmetry of the possible loss (better blocked funds, its not lost) is reduced (10 against  11). But of course such a high collateral will make offers less likely to get accepted.

From the paper:
"One protection will happen automatically as in times of more failed trades the traders will increase the collateral and therefore make the attack more cost intensive. That should help against the attacker with limited resources like competitors or market manipulators.
A statistical tool which analyse the number of failed trades in relation to the collateral could help to auto-adjust the recommended collateral value. So in times of a low fraud rate the recommended collateral will be lower."

The above will be not enough for political motivated attackers.
If we assume they have near unlimited funds to attack (they can print money) we need a better protection.

A possible protection against political motivated attackers is described in the paper.
A shot version here:
Create a lottery where frozen funds are distributed to successful traders.
So any money spent for attacking the system will boost the system as it serves as incentive for honest traders to trade and have a chance for winning that price-money.

It has its own problems and introduce new attack surfaces. You cannot prevent that the attacker creates a huge amount of sock puppets and therefore has higher chances to win the distributed money.
But it is a dynamic system:
The higher the winning chances the higher the motivation for new traders to get into the system, or to cheat as well with sock puppets.
Fees could help as well to make sybil attacks at least more cost-intensive. Maybe other mechanisms like PoW could be used as well.
Those ideas are not much further developed yet and would need much more investigation.

At the end it will be a very dynamic and hard to predict situation. Also the attacker has his risks.

A reputation system would be another protection. But as well has its own problems.

To use a 3rd party escrow with SSL dump seems at the moment to be the best protection for the majority of attack scenarios.

The beauty of the initial Nash based solution is its simplicity.
It is relativly easy to understand and would be easy to use (and to implement).
Any new feature to protect against one attack surface will open up new attack surfaces and new problems. The rise of complexity will introduce its own problems (more complex code leads to bugs and security risks, harder to understand and to use).

The Nash based setup suffers from 2 basic flaws:
1. The possible loss is asymmetric between the actors
2. The honest actor will lose even more if the other behaves unfair.

The second point will lead to strategies that users try to escape from the game setup (use off-system channels) as they feel that it is not a fair game.

[biolizard89]

A few thoughts here.

I really like the collateral-based system.  I think the only involvement from a 3rd party that is warranted is an oracle which forces the final transaction to not be split, i.e. either the payment goes through completely or a complete refund is given.  And this oracle could be one of the parties of the transaction, as long as that key is wiped after signing both the payment and the refund, right?  So any 3rd party seems unnecessary to me.  Involving 3rd parties holds the potential to compromise anonymity unnecessarily, and the 3rd party could prevent the transaction from completing if they wished to sabotage the system.

Reputation systems would compromise anonymity, and would be vulnerable to Sybil attacks.

For irreversible transactions, cash in the mail seems a good option to me.  It also has much better privacy than banks.  There's a Tor hidden service I saw a while back which acts as an exchange where all fiat transfer is via $20 bills in the mail.  I wouldn't be surprised if that site is a scam, but the idea is good if done using P2P and collateral.  Sure, some people will prefer something faster, but I imagine a lot of people will be okay with waiting 3 business days for USPS to deliver an envelope with cash -- a lot of centralized exchanges take a while too (CoinBase took ages last time I used them).

Also, this concept seems easily applicable to a generic marketplace (a la Bitmit) as opposed to just a currency exchange.  I know that's been mentioned already, but I hope that the emphasis won't just be on currency exchange.

Are you familiar with the BitMarket concept by AyrA?  I'm not sure how similar it is, but maybe some of the stuff in that project would benefit this?

[cjp]

So, the basic idea has it flaws, and any attempt to fix these flaws creates new flaws. I'd say we should Keep It Simple: start with a relatively simple, conservative version, and only improve it after we gained some practical experience.

I think that using a trusted 3rd party as escrow, with a 2-of-3 mutisig, is already an improvement over existing exchanges: the escrow party can not run away with the funds, go bankrupt & so on. Even if the escrow party disappears, the trading parties can usually finish their transaction, since most of them are honest.

Maybe the escrow provider doesn't even need to know what transactions he's escrowing, just like a judge doesn't need to know what contracts are signed in his jurisdiction: the existence of a contract / transaction is only revealed to him/her in case of a dispute. All an escrow needs to do is:
* publish a public key
* publish the compensation he/she requires for the escrow service
* publish the types of transactions he/she supports, some guidelines for the kind of evidence accepted & so on
* somehow make people trust his/her escrow service (this could include revealing his/her true identity)
* (of course) actually resolve conflicts

For now, I think anything related to the reliability of the escrow service doesn't need to be solved in the system: people are already familiar solving that issue outside the system, e.g. by discussing the reliability of Bitcoin services on forums like this one. We can always try later to invent an in-system fix for that problem, if it turns out there is an urgent need for such an addition.