Here are some building blocks of a possible solution for a trustless p2p fiat-crypto exchange:
Based on ideas from:
https://nashx.comhttp://www.bitescrow.organd in discussion with 2 other friends (not sure if they want to get listed here....)
To understand the following better its suggested to have a look first to the above 2 solutions.
The escrow solution is used for 3 escrow transactions. 2 risk funds (one for each trader) and the payment fund (btc). The fiat transaction goes over a conventional channel (bank,...).
To introduce an incitive for releaseing the fund after the fiat buyer has received the money (he could just be fine in that situation, he has payed btc and received fiat) we introduce the idea of the Nash equilibrium. If the transaction for one of both is not satisfying, both will loose the money they paid to the risk fund.
But there is a problem with the Nash equilibrium, as in different stages of the trade transaction there are different amounts both traders could loose. That leads to 2 attack situations for blackmailing the other user. If both are loosing some money but one loose more then the other, that could be used to blackmail the other...
To get rid of that problem a trading pool could serve as a possible solution.
Maybe there are other solutions, the basic idea was to break the connunication line so a blackmail does not work anymore (if you dont know the other you cannot blackmail him). With a trading pool where the mapping of the partners in the second part of the tx is randomized the communication line is broken (see later in the example if its not clear enough yet...).
Trading pool:
A group (n) of trading pairs want to buy 1 btc for the same price.
At the end it does not matter who will pay whom. All give the same fiat amount for 1 BTC.
The mapping between the fiat receiver and the btc receiver is randomly defined (only the system knows the mapping, not the traders).
The larger the pool the lower the risk for attacks.
First it looks that a trading pool will be much more difficult to use for trading as more then 1 trading partners must be found, but I think that depends only on the number of users. A user could set an offer within a price range and some security conditions like:
I want to buy 1 BTC for price 800 EUR +/- 20EUR in a pool with min. 5 trading pairs.
Here a quick overview of the rough idea:
Fiat Seller 1 sends fiat to BTC Seller 1
Fiat Seller 2 sends fiat to BTC Seller 2
Fiat Seller 3 sends fiat to BTC Seller 3
After successful fiat transactions:
BTC release with randomly choosen mappings.
BTC Seller 1 release BTC to BTC Seller 2 (for example)
BTC Seller 2 release BTC to BTC Seller 3
BTC Seller 3 release BTC to BTC Seller 1
Lets play it with an example:
User A sell 800 EUR to 1 BTC
User A has to pay trading value + x to risk fund, in our example 0.1 BTC: 1 BTC + 0.1 BTC = 1.1 BTC in risk fund
User B has to pay payment + x to risk fund, in our example: 1 BTC (payment fund) + 0.1 BTC (risk fund)
Critical attack situations:
Situation 1: User A does not send fiat money
Situation 2: User A has sent fiat, user B does not release btc payment and risk funds
Fair game:
Situation 1
User A: -1.1(Risk); balance: -1.1
User B: -0.1(Risk) - 1(Payment); balance: -1.1
Situation 2:
User A: -1(Money); balance: -2.1
User B: +1(Money); balance: -0.1
Release:
User A: +1.1(Risk) + 1(Payment); balance: 0
User B: +0.1(Risk); balance: 0
All fine....
User A tries to cheat:
Situation 1
User A: -1.1(Risk); balance: -1.1
User B: -0.1(Risk) - 1(Payment); balance: -1.1
Blackmail attack from user A does not make sense as both would lose the same:
If user A does not send, both will lose the same.
User B tries to cheat:
Situation 1
User A: -1.1(Risk); balance: -1.1
User B: -0.1(Risk) - 1(Payment); balance: -1.1
Situation 2:
User A: -1(Money); balance: -2.1
User B: +1(Money); balance: -0.1
User B could try to blackmail user A but the probability that user A get his payment and risk fund released from user B is 1/n (due to the randomized mapping).
Losses if he does not release:
User A: balance: -2.1/ n (only if the system mapped him to that trader)
User B: balance: -0.1
Users has only contact info to their trading peer not to the other users in the pool, so no way to make a poolwide blackmail.
What value should be applied to x? It depends on the size (n) of the trading pool.
To obtain an equilibrium we have that condition:
(2 + x) / n = x
for n = 1 that would result in an inequation, so that will not work.
2+ x != x
for n = 2 we get a valid result for the equalition, so min. pool size is 2.
(2 + x) / 2 = x
x = 2
Test:
x = 2 for n = 2;
User A: balance: -4/2 = -2
User B: balance: -2
both loose the same so no blackmail risk
Attack situation 1:
User A: -3(Risk); balance: -3
User B: -2(Risk) - 1(Payment); balance: -3
for n = 3
x = 1
Test:
User A: balance: -3/3 = -1
User B: balance: -1
Attack situation 1:
User A: -2(Risk); balance: -2
User B: -1(Risk) - 1(Payment); balance: -2
Conclusion:
As soon as we have a second trading pair we get perfect Nash equilibrium using the propability of the pool size. The larger the pool the lower the necessary risk fund.
Additional:
Some thoughts about user reputation systems:
If the p2p trading system would work, it should be very easy to create a new user.
That could be automated by scripts, so there could be created 1000s of virtual traders used to build up good ratings.
So I think a rating system without visible controlled identity will be misused.
Real person escrow (if we need that at all) could be introduced like that:
In case of a dispute a trading party could ask for an escrow which would be selected automatically from the system randomly between all users.
The selected escrow has to reply within a certain timespan (e.g. 1 hour), if he does not reply the next one will be selected. If the escrow accept to help he would get a fee.
The escrow could then release funds for one or the other party.
Let me know if you find any weak points in the trading pool approach.
One could be that members in a pool could work together, or a pool is a pseudo pool by 1 member with different accounts. But I think as a cheater cannot proof that he is the owner of the other pool members, a blackmail will be hard…
But of course that needs to be refined much more and there will be for sure more problems when getting deeper. Just a first step....
