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

They are centralized companies.

Can you elaborate you criticism?

Exactly. I am referring that in my paper "Think of it as localBitcoin without any company or 3rd party involved".
The goal of that project is to create a p2p system which works like those but WITHOUT any central element.

The basic idea is that nobody has any incentive to cheat, as it will lead to losses on both sides. Only economically irrational people would cheat.

A couple people here had a misunderstanding.
Assuming that any of the parties do not agree on anything , everything is frozen.
The money gets deposited in the shared wallet after both parties have provided collateral.
If they have a dispute , such as 1000$ is not received , both parties have their collateral stuck along with the 1 BTC stuck in the shared wallet.
Surely , the bitcoin seller has a bigger loss in this case , but the buyer has a loss too.

Now what I don't get is how will funds from both parties be simultaneously be introduced into the wallet ?
( not too much knowledge about technicalities )

It already exists on nashx, localbitcoins and bitcoins.de for years.

This scheme won't work, is exploitable (buy BTC from stolen bank accounts and screw Bob), does require trusting banks and has loopholes all over the place.

All you did is describing bitcoins.de but instead of saying "they go to a website" you said "they exchange data via BitMessage" and doing multisig transactions instead of escrowing with a neutral third party.

Might not be the smartest idea to give your mail address to strangers if you trade a couple dozen BTC... also cash-in-mail can and will get lost - how does Bob proof to Alice he got just an envelope full of copied dollar bills and how dies Alice proof to Bob that she actually put the money in there?

I'll have to read this closely. It looks like you are on to something bro!  Thanks.

Ripple is the darling of the Banks.

With this Nash equilibrium solution you can even send money by snail-mail. You don't need to trust the banking system.

This is good but one obstacle in the USA is how to get funds into the other person's bank account.  Chase is already making it so you are not able to deposit cash into someone else's account, and other banks are likely to follow.

After preliminary analysis, this idea seems pretty amazing !

Who needs Ripple, when you have Bitcoin !

Somebody has to start developing this software as soon as possible. Nash equilibrium has always been my first choice for P2P exchanges. It's a very smart solution where no arbitraging is needed and the collateral requirement is almost insignificant.

Please, this idea needs to be implemented in code.

He can spend his funds until Alice have signed and published (she cannot publish without signing).
Before Alice sign/pub she (the sotware) needs to check if Bobs funds are still unspent.
Until Alice has published the deposit tx everybody can cancel without harm (just time lost).

Bobs payment is locked, so he will not get returned any BTC. He would loose 0.1 BTC collateral and recieved 1000 USD. so his deal was then 1000 USD for 1.1 BTC instead of 1000 USD for 1.0 BTC. Why should he opt in for the worse deal by not releasing the last tx?

Either get some BTC form other exchanges or faucets or use a non-collaterated offer. If a reputation system is included he could use that for minimizing the risk of fraud when doing a deal without collateral. Note that even without collateral nobody can steal money of the other, they could just be evil to not continue in the process und not unlock the tx. they would not win anything but the other would loos something.
For very small amounts (10 USD?) I can imagine that that risk can be taken.

I wanted to keep the graphic simple and probably there are already too much details in. It is more to get a quick overview and a help for less tech-savvy people. In the paper most of the scenarios are described.

At the end it comes to the point that they need to ccoperate, otherwise both will loose. So if there are a problem like the bank tx failed, then they can communicate and find a solution based on cooperation. They could create a rollback tx if they agree, both have the keys needed for that. But as this would be an unexpected case I did not include that (in the software there should be  tool for that).

Bob would lose his 0.1 BTC collateral. So if he was trading at the normal market price the trade would most likely end at a loss for him (He gets $1000 but loses 1.1 BTC instead of just 1 BTC).

That is the situation what is described under Attack scenarios step 4:
He has already received the Fiat, so the only missing for him is the BTC collateral he payed in and which he only gets returned if both sign the last tx. If he tries to cheat he will loose his collateral (Alice know she had payed, so she has no reason to believe him).
Alice would loose also the payment in that case. But why should Bob risk to loose the collateral?

Opionally there could be used an escrow, either included in all the process (I did not described that, but all 2 of 2 multiSig txs would be then 2 of 3 MS) or optionally afterwards (described under the point Extensions). If there is something to mediate, both can agree to create a new tx to a 2 of 3 multiSig with the escrow. Then move the money from the deposit tx over there, and then consult the escrow for arbitration. That could be treated outside the system, just use any available Escrow service.

The SLL dump mentioned in a post above (and in the paper) could be used for the escrow as proof of the bank transfer. Without that proof it will be easy to cheat an escrow with some photoshoped bank tx screenshots....


That is the only real problem. Then if nobody in his family can access the funds or you cannot contact (the bank account details could be used) them, the depost if lost.
As this should be a very rare case (1 in 10 000?) and the system should not be used for high volumes it could be considered as something like an "trading fee". If you trade a lot and loose once the funds, then it may be 0.1% of your overall trading volume. Much less like in most centralized exchanges or the costs for Bank transfers.
Another solution would be an 2 or 3 escrow like above. Maybe a solution based on timelocks could solve the problem as well, I have not found a working solution yet.

An overal design goal is also to keep it as simple as possible.
First because it is more realistic that it gets developed some day.
Second it is easier to understand and use.

Open Transactions or Ripple are very advanced and complex solutions. It is even for tech people like here in the forum difficult to really understand it (and trust it). For non-tech savvy people it would be even more difficult. A simple system would help that people really use it and therefore create market liquidity.

A certain remaining risk is acceptable and in fact accepted by quite a lot of people using shady or badly operating exchanges (MtGox, BTC-e,...). The level of risk is defined by every trade with the trading volume and collateral.

yes this is what i was getting at..

What happens when Alice requests to buy 1 BTC. Bob signs his half of the transaction and then Alice just disappears? Is the 1 BTC lost? Malicious buyers could do this an infinite amount of time with no money lost to them.

I think the point there was Bob CLAIMS to have not received the funds, when in reality he has. He just wants to keep the fiat and btc

Great idea, but how would a first time buyer of BTC provide any collateral. It would just be a scammers haven without some sort of escrow agent.

The graphic should show what happens if Bob does not receive the wire transfer and they agree to cancel the transaction. I guess in that case a "rollback transaction"  is necessary (input: deposit 1.2, output: Bob 1.1 , Alice 0.1) right?