BANK RUN! - P2P Fiat-Bitcoin Exchange

[k99]

[UPDATE]

Here is the new thread with updated resources:
https://bitcointalk.org/index.php?topic=647457

[END UPDATE]

#############################################################

I would like to announce a concept for a P2P Fiat-Bitcoin Exchange.

Basics:
- Pure P2P, cannot shut down by a central authority, no 3rd party involved.
- Collateral as warranty for fair behavior
- Fiat money will be transferred from one users bank account to the others bank account without any intermediary party. No identification that the money transaction is connected to a BCT trade.
- No fees beside the standard BTC transaction fees.
- Open source

Here is the paper:
https://docs.google.com/document/d/12q5r6S0yMp5TMjApfa7Ci4GRvvvKYvlmWQBYeGxI0zA

I would appreciate a constructive discussion and I am looking for developers.

High-level overview of the protocol:

[1714937673]

1714937673

[1714937673]

1714937673

[1714937673]

1714937673

[1714937673]

1714937673

[1714937673]

1714937673

[dansmith]

What you described here is exactly the P2P exchange I had in mind.

You have all the right pieces in place: collateral, 2-of-3 multisig with an optional escrow agent, bitmessage
You paper also mentions my SSL dumps project. I developed a much more simpler approach called tlsnotary:
https://bitcointalk.org/index.php?topic=173220.msg4998488#msg4998488

I could add a word or two about how to create a privacy-friendly reputation system but as your paper notes, this is a complex feature and it can be addressed later when the p2p exchange gets implemented.

wrt to funding model, I have no good ideas. I doubt that it is possible to get anything upwards of 1000$ in donations at this point. So I'd say, it's best to first release some working software and gauge the market reaction to it. Then it will be easier to sit down and come up with monetization ways.

[k99]

I could add a word or two about how to create a privacy-friendly reputation system but as your paper notes, this is a complex feature and it can be addressed later when the p2p exchange gets implemented.

Would love to hear your ideas about a privacy-friendly reputation system!

I am not sure if in practice it would be needed (collaterals should be enough) and probably there is never a perfect solution against sybil attacks as well. But I have not researched that topic much, so maybe there are "good enough" solutions out there?

You have all the right pieces in place: collateral, 2-of-3 multisig with an optional escrow agent, bitmessage
You paper also mentions my SSL dumps project. I developed a much more simpler approach called tlsnotary:
https://bitcointalk.org/index.php?topic=173220.msg4998488#msg4998488

Great work on the SSL/tlsnotary stuff!
Maybe that could be added after the basic concept is implemented.
I would like to design it as a plug-in architecture, so all non-core features could be added optionally (SSL/tlsnotary, reputation, escrow, bank API).

wrt to funding model, I have no good ideas. I doubt that it is possible to get anything upwards of 1000$ in donations at this point. So I'd say, it's best to first release some working software and gauge the market reaction to it. Then it will be easier to sit down and come up with monetization ways.

I know that will be a difficult topic, but at the moment is has no top priority to me .
Basically I would like to keep it free of fees and have a clear and transparent model.
I liked the way how Dark Wallet has done it with crowdfunding. That is clear and there is no elements of speculation and greed in there (as with many altcoin projects).
I know without incentives like "join and you will be millionare in 2 month" it will be harder to find people contributing (I need devs), but it may be a good filter as well. :-)
My motivation is to get a missing part of the BTC infrastructure solved, not to get rich with it.

That a decentralized crypto-currency is dependent on centralized exchanges/banks is a contradiction which need to get solved.
If we don't solve it soon we will get challenged  with that single points of failure the hard way (China, Russia,...).

The Ripple/OT/NXT/... solutions are not pure P2P solutions IMO (IOU, gateways).
See that thread for more discussion: https://bitcointalk.org/index.php?topic=425317.msg5117398#msg5117398

[utens]

I'm not technical, but please do it 

[bitappend]

What happens to the flow of money under the following scenarios?


Bob claims he never received fiat funds?
I'm not worried about the reverse case as there no question about bitcoins going through.


alternative scenario.
Bob dies in a car crash on way to work before acknowledging receipt?

[CryptoFuture]

I'd tap this.

[vqp]

Bob claims he never received fiat funds?
I'm not worried about the reverse case as there no question about bitcoins going through.

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?

[IsaacGoldbourne]

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.

[IsaacGoldbourne]

Bob claims he never received fiat funds?
I'm not worried about the reverse case as there no question about bitcoins going through.

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?

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

[CryptoFuture]

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.

[bitappend]

Bob claims he never received fiat funds?
I'm not worried about the reverse case as there no question about bitcoins going through.

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?

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

yes this is what i was getting at..

[k99]

What happens to the flow of money under the following scenarios?
Bob claims he never received fiat funds?

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....

Bob dies in a car crash on way to work before acknowledging receipt?

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.

[CryptoFuture]

Bob claims he never received fiat funds?
I'm not worried about the reverse case as there no question about bitcoins going through.

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?

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

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).

[k99]

Bob claims he never received fiat funds?
I'm not worried about the reverse case as there no question about bitcoins going through.

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?

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).

[k99]

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.

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.

[k99]

Bob claims he never received fiat funds?
I'm not worried about the reverse case as there no question about bitcoins going through.

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?

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

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?

[k99]

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.

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).

[Polvos]

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.

[ShadowOfHarbringer]

After preliminary analysis, this idea seems pretty amazing !

Who needs Ripple, when you have Bitcoin !

[russokai]

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.