Topic: BANK RUN! - P2P Fiat-Bitcoin Exchange - page 9. (Read 39092 times)

I think these are serious issues which need to be considered

A sybil attack would be just me selling to myself a 1000 times (you could also call it the "Huobi" attack... ) from a couple different accounts... All of these trades would be (of course, there is no need to even actually transact funds!) successful ones.

The reputation system is optional. I assume sybil attacks cannot be avoided completely. But in practive they works not so bad, many web apps using such systems are confronted with the same problem. The only secure solution would be with an identity proof, which is unacceptable. But maybe a solution with zero-knowledge crypto or the like will be possible some day.

Yes the economic irrational actor would be a problem, and if fact it could be economic rational - just in the way that the profit is gained outside the system by bringing down the system (like Gold, Silver manipulation).
Another attacker would be a political motivated attacker.

For those 2 groups a reputation system could make it at least a bit more difficult. With sybil attacks it also would not be completely covered.

I had one idea but have no solution yet how to implement that:
If every locked fund will go to the trading community (as lottery style payout to save tx fee costs) then such an attacker would not hurt the system, because participating in the system will be more attractive as you could earn money when you are the lucky winner.
Only the successful traders would be in the lottery pool. So if a attacker sybil attack that concept he needs to make a lot of succesful trades, so helping the system again...
To solve the locked funds problem would be a great improvement.

Maybe its not so hard to solve that. I will elaborate it more....

I thought they didn't restrict that, but are asking for is now when you deposit.

I think this system is great.  The area that concerns me most is the reputation system.  What stops people buying and selling reputation tokens from each other in another market.  This way the reputation merely has a cost/price and adds nothing over the collateral which is also a cost. If we cant think of a strong and effective reputation system, it might be worth trying to build this system without reputation.

Is OT really that complex?  It seems like the API should be pretty straightforward to program to, and then you just make a simple GUI for it (you don't have to worry about all the other 'advanced' stuff the OT server does).

It occurs to me that such a P2P exchange could make a profit from locked transactions where the two parties couldn't come to an agreement.

There are two problems with that I can think of:

1. Bank transfers can be reversed in some circumstances (account was stolen etc). Some days after Bob gets the money and releases the bitcoins, the bank may reverse the transaction.

2. I'd be worried that the bank may freeze my account if I receive cash transfers from someone who turns out to be a criminal or the bank freaks out for some reason.

I would much prefer a centralized exchange.

This concept could work if A and B meet up and payment is made in cash. This concept could also work for trading between cryptocurrencies (btc <--> ltc etc)

Hello!

This looks fantastic, exactly what BTC needs. With a little tweaking this would be magnificent for alts.

I see that there is an escrow-like model to the exchanges where both parties must put down collateral.

Isn't this the wrong approach to have given the fact one party could still potentially scam the other? I'm not sure if this question has been addressed, yet. However, I will try to elaborate upon it.

For example, Ethereum has a p2p style escrow where the parties have trust ratings. The person who is putting the money forward can withdraw 1% a day, the other person getting the money can only withdraw 0.05% daily. Creating a drawn-out and delayed exchange given the fact one party could be fraudulent. The forwarding party can watch if the other receiving party has begun retracting their end of the deal. Except, the forwarding party can withdraw their funds faster due to the early warning the delay gives.

Is there any way some of this could get implemented ?

edit: a word

Exactly! They can choose it freely. Basically it depends on the volatility, but as I described in the other reply there is no much risk with that included. I will probably elaborate that topic in the paper more in details.

In the paper under the chapter "Attack scenarios" I describe 2 situations where one could try to cheat.

Attack scenarios:

Step 3. Alice publishes the deposit tx and does not send the Fiat money:
Alice will loose 0.1 BTC.
Bob will loose 1.1 BTC.
Both loose, 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 loose 0.1 BTC + 1000 USD -> 1.1 BTC.
Bob will loose 1.1 BTC - 1000 USD -> 0.1 BTC.
Both loose, make no sense to do that.

Both are covered if the collateral is > volatility of the btc price.
So in normal times 10% should be enough, but it can be set to any value by the offerer.

Please note that both attack scenarios (Alice publish the tx but do not pay the Fiat) are very unlikly as no party can win anything.
It is easier to understand if you assume a 0 BTC collateral.
Step 3:
Alice publish and lock the depost tx. Before that step both can cancel easily when spending the BTC form the input address.
Alice has payed in: 0 BTC collateral, 0 USD
Bob has payed in: 0 BTC collateral, 1 BTC
If Alice does not continue she will not win anything, but Bob will loose 1 BTC (locked). To prevent that possibly evil behavior from Alice the collateral serves as incentive to behave fair.

The above with collateral of 0.1 BTC:
Alice has payed in: 0.1 BTC collateral, 0 USD
Bob has payed in: 0.1 BTC collateral, 1 BTC
So now if Alice does not continue she still will not win anything, but she will loose her collateral of 0.1 BTC. Bobs loss of 1.1 is even higher, but what she would gain from that?

The second situation is when Bob has received the Fiat and does not continue (release the payment/refund tx).
Step 4:
When not using a collateral it would be like that:
Alice has payed in: 0 BTC collateral, 1000 USD
Bob has payed in: 0 BTC collateral, 1 BTC
Bob has received in: 1000 USD
If Bob stops here, he has payed 1 BTC and have received 1000 USD, that was exactly how the trade was intended. So if he is evil he could stop here. He has reached his goal and has nothing to loose, but also no possibility to win more. For Alice that would mean a loss of 1000 USD.

With collateral:
Alice has payed in: 0.1 BTC collateral, 1000 USD
Bob has payed in: 0.1 BTC collateral, 1 BTC
Bob has received: 1000 USD

If Bob stops here, he has payed 1.1 BTC and have received 1000 USD, that is not how the trade was intended (1 BTC for 1000 USD). So if he is evil he could stop here but he has NOT reached his goal and has lost 0.1 BTC. There is no possibility to win more. For Alice that would mean a loss of 0.1 BTC and 1000 USD.

The 2 scenarios have once more risk for Bob and once for Alice. So overall both are exposed to the same risk.

When the price would change from 1000USD/BTC to 500USD/BTC, Alice could decide to not continue at step 3.
But even that is very unlikely because there is no reason to do that. She can cancel without breaking the rule until the second before she publish the deposit tx. The next step would be to deposit the USD, but thats following directly after the publication, so the time window for a huge price change which will lead her to break the contract is very small.

The collateral amount will also need to rise in times of higher volatility (much like margin on a regulated exchange).
The amount of collateral can be agreed beforehand by the parties as part of the contract. More collateral, better rate.

I would without a doubt recommend a larder deposit then 10%.. heck that's less then arbitrage in some instances. dare i recommend 25%? sounds high. however in the matter of the time it takes for bank transfer happens a lot can happen in the markets. Alice would get screwed if bob has greater incentive to walk away from his deposit if he has a better trade opportunity.

in a different scenario
 there might be a chance bob could extort Alice in order for her to get her deposit back.  should he refuse  to confirm

If we are exchanging 1 BTC for $650 and we lock up 1 BTC or less as a collateral, then I can receive your $650 and let my 1 BTC stuck as a collateral forever. I'm not losing anything (I'd pay 1 BTC anyway), but you lose 1 BTC + $650.

I'd consider a collateral that is big enough to not cheat, but not too big to go into a different category. In absence of mutually trusted third party (e.g. online exchange), the only way to resolve the issue is to "buy" the trust by agreeing on some big enough collateral.

This only works if the price for BTC is stable.

At the time of the trade, 1 BTC is 1000 USD.
Alice buys 1 BTC, freezes 0.1 BTC, sends 1k USD honestly.
Bob sells 1 BTC, freezes 1.1 BTC, receives 1k USD but never reports on it.

Once these 1.1 BTC are worth LESS than 1k USD, Bob was smart.

Staying honest when selling with this scheme just depends on how low you think the price would go.
Only if he believes the price won't tank more than 2-fold until he gets the money. Also he has now a much higher risk that someone locks up 2 BTC to lock up 3 of his. Potentially forever.

Would you sell me 1 BTC right now via bank transfer if we both need to lock up 50 BTC for that?

Here are the slides I'm showing tonight at Paris Bitcoin meetup.

http://oleganza.com/bitcoin-epita-2014.pdf

They explain in depth the protocol to exchange anything based on collateral without any trust in anyone.

By normal wire perhaps ? Wires aren't blocked AFAIK. Only direct deposits.


Collateral can obviously depend on the trust level between participants and other parameters/circumstances.

Collateral should be greater than amount in exchange. If they exchange $1000 for 1 BTC, collateral should be 2 BTC. So when Bob receives $1000 it's cheaper for him to unlock collateral (2 BTC) than to keep 1 BTC worth of product (cash in this case).

Which economically rational person buys unbacked digital assets?

Anyways, if you for example have stolen money or Bitcoins, you don't need to be economically rational. Also paying a price for hurting your competition can be economically rational.

It leaks private data (cash in mail: mail address, bank transfer: bank account data) all over the place. I described one problem (stolen bank data which will lead to later reversed USD transactions) already, also there can be indefinite lock-ins, the extra funds at stake (in your example 10%) can lead to people implicitly taking a short/long position, it requires trust to begin with (who wants to trade with a newbie in your system?), both traders need to be online and do manual tasks outside of the system...

I mean, feel free to try this out in practice, it's not even hard to do - just post an offer in this forum for the mean time, put some funds on the table and get trading. It took less than 2 weeks each for 2 different new Ripple gateways, until they had a few 1000 USD bank transfers reversed each. Maybe you can beat them to it?

Thanks for helping to explain it!


We create an atomic transaction where both funds are locked at exactly the same time when it gets published. It is all or nothing.
1. Bob creates first a tx with 2 inputs and the multiSig output.
2. He sign his input (He agree to pay his part, but the tx is only valid if the other party also agree to pay)
3. He send the tx to Alice the partly signed and therefore invalid tx (off-chain)
4. Alice sign her input. The tx is now valid but still not published, so both inputs could be still spent to another address if any of both want to cancel.
5. Alice publish the tx. From that point on both funds are locked.