BANK RUN! - P2P Fiat-Bitcoin Exchange

[jubalix]

what motivation does he have to sign BTC over?

eg by no signing he acutly increases his wealth (sender is poorer) and marginally increases his and every one else BTC worth, by leaving BTC locked up.

time this by millions of transactions and you get alot of BTC locked up forever, and sender looses

" what motivation does he have to sign BTC over?" - To get back his collateral.
The 0,1 btc in the paper is only an example, can be any. Think to 1 btc collateral, that's much incentive to behave fair.
No, he does not increase his wealth (he has spent 1 btc + coll and received 1000 USD), so the collateral he needs to get back otherwise he loses.
The effect of a locked up btc is close to zero (about 1/10 M).
Locked funds will happen but probably very rare (1 of 1000?). There is no way to win money, only lose less then the other, that is for normal people no incentive to behave unfair.

ok so if he want to get his 1BTC back he has to sign over the 0.1 btc to the other person as they are both locked up together so what is the mechanism to hold the 1 BTC locked up and who / what has the key and what trips it to pay out.

Whatever that is at its root faces the same problem.

Actually I kinda get it

the 1.2 btc multi sig, allows the 0.1 to flow back to bob, so he is motivated to sign it, he however does at this ratio can burn sender much more.

You likely need a ration that is higher

to really hurt bob if he does not sighn.

the other problem is if he just does not sigh, while this hurts bob, it does not help sender, so that need to be taken care of some how.

Eg Bob dies or looses keys then what?

[waxwing]

Indeed, jubalix, the size of the deposit is open to debate. But the basic structure is that each side only stands to lose by defaulting on their commitment.

In my opinion this is not the main issue; the main issue is there is nothing forcing the two parties to pay out in the ratio (1.1,0.1) to (Alice,Bob) at the end. They could end up paying out (0.8,0.4) or anything else. This is one of a few things we've been discussing on irc #bankrun.

[k99]

Indeed, jubalix, the size of the deposit is open to debate. But the basic structure is that each side only stands to lose by defaulting on their commitment.

In my opinion this is not the main issue; the main issue is there is nothing forcing the two parties to pay out in the ratio (1.1,0.1) to (Alice,Bob) at the end. They could end up paying out (0.8,0.4) or anything else. This is one of a few things we've been discussing on irc #bankrun.

Yes the collateral of 10% seems to me now also too low, but it is free to choose, but probably there will be a recommended collateral more about 50% or 100% (will be updated in the paper in a new version).

What will be the right collateral?
We could analyse the statistics of past trades (data from the blockchain) and estimate the rate of failed trades and see the collateral used there. That could be maybe a mechanism helping to find the right balance. If the collateral is higher all will be more safe, but if it is too high the chances that somebody take the offer will decrease, also the possible loss will rise.

If the other trader cannot continue unintendedly (death, hard disc crash,...) there is no way to unlock the funds if we dont use an escrow (still in discussion). But that case will be very rare. I assume 1 of 10 000 or less, so if you keep the trades low, that could be taken in account as kind of fee. Maybe a kind of insurance service could be used to flatten that effect, but that comes with new problems.
Another solution could be to use a lottery system to spend the locked funds to a lucky winner who has traded once successfully. So the negative effect could be turned into some positive. But that system opens again up new problems, but it is in discussion.

Yes that blackmail scenario waxwing has found is more serious then the one I discussed in the paper:
A normal blackmail would suffer from the asynchonious payment. So if you accept a blackmail and then as 2. step the blackmailer need to pay back the open funds, then you are exposed again to him. Nothing prevents him to repeat the blackmail. So that could be an infinite loop.
But if Bob signs a tx with changed outputs to his favor and send that to Alice, Alice only needs to sign and publish it, so there is no gap anymore between blackmail negotiation and payment. If Alice accept it and publish it, she will get her money back for sure. So that is a more serious attack scenario.

But it still has its problem to become a realistic threat:
The software does not provide any tool to do the signing and publishing for Alice in a way that a non-tech person can do it easily. Alice can not easily copy her private key, she need to be tech-savvy to do that. So Bob need to provide tools to help her and give technical instructions, making the attack more difficult to succeed.

Another more important point is that Alice know the real ID of Bob due the Bank account, so she could go to a lawyer or try to confront him in real life (Bob does not knwo who is Alice, she might be an innocent girl or the sister of a powerful mafiosi). Assuming that Bob does not use a stolen Bank account (but that will be out of the scope here).

There would be a way also to create a legal contract for the trade with the initial deposit tx. That would create then even more pressure to Bob to act fair. But we will try to keep the concept independent form the outside legal system, cross country trades would complicate all that as well...

[k99]

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.

No that is not right. If you unlock you get your collateral back (0.1BTC in my example, 1BTC in yours). If you dont unlock then you lose that.

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

The collateral only serves as incentive to not hurt the other losing his money. There is no way to steal the others money. Even a small collateral like 10% can fulfill that job. If you behave unfair you will lose 0.1 BTC as well, even if the other will lose 1.1 BTC for rational persons it is not an incentive to lose anything if he only needs to click a button.
The height of the collateral can be freely chosen, but there will be probabyl a recommended value.
I will consider to set the default collateral higher maybe 50% or 100% of the trade volume.

[gdassori]

I wonder if you know "Twister" (but probably the answer is 'yes') and if something comes out from that concept can be useful: It's a P2P microblogging platform.

It comes with an implementation from Libtorrent (DHT) for the resources management, and it uses the blockchain for the users management. White paper and documentation explains everything, definitely better than I can.

[k99]

I wonder if you know "Twister" (but probably the answer is 'yes') and if something comes out from that concept can be useful: It's a P2P microblogging platform.

It comes with an implementation from Libtorrent (DHT) for the resources management, and it uses the blockchain for the users management. White paper and documentation explains everything, definitely better than I can.

Yes Twister is beside Bitmessage the preferred solution for the messaging system.
Dark Wallet will probably use that as well, and it could be that we will build on Dark Wallet. But it is still too early to discuss much about the technical decisions...

Are you more familiar with Twister?

[gdassori]

Not deeply, TBH.

I just know and understand the concept, but as I told elsewhere I'm not an highly skilled developer, I just know a little bit Python and SQLAlchemy ORM, used them to build 'classical' exchangers trading API and some backends for dynamic websites.

I told you about Twister just because the first time I saw it I said 'hey, this engine could be great for a p2p exchanger'. I loved how they used Libtorrent to keep the blockchain clean and smooth and spread data inside the net faster, without the need of block confirmations.

I always used to think that one of the limit of a p2p exchanger is this: We can't wait the time needed by the blockchain to confirm (and so lock for the rest of the audience) the ASK\BID. We have to avoid collisions (and surely you spent more time than me thinking about this )

Probably I could be more useful in documentation mantaining or something like this, in 'Bank Run', hopes this post didn't sound too much silly.

[k99]

Not deeply, TBH.

I just know and understand the concept, but as I told elsewhere I'm not an highly skilled developer, I just know a little bit Python and SQLAlchemy ORM, used them to build 'classical' exchangers trading API and some backends for dynamic websites.

I told you about Twister just because the first time I saw it I said 'hey, this engine could be great for a p2p exchanger'. I loved how they used Libtorrent to keep the blockchain clean and smooth and spread data inside the net faster, without the need of block confirmations.

I always used to think that one of the limit of a p2p exchanger is this: We can't wait the time needed by the blockchain to confirm (and so lock for the rest of the audience) the ASK\BID. We have to avoid collisions (and surely you spent more time than me thinking about this )

Probably I could be more useful in documentation mantaining or something like this, in 'Bank Run', hopes this post didn't sound too much silly.

Indeed the storage solution of Twister is very powerful. For longer offer storage that would be necessary as well. Bitmessage comes with 2 days AFAIK. That might be too short. And maybe there will emerge other needs to store data (reputation?), so to have a solution which has that already built in will be definitly better.

The offer broadcasting is intended to do via the messaging system not via the blockchain. The only point where you have to wait for a confirmation to avoid a double spend attack is when Alice publish the deposit tx. If she waits then at least for 1 confirmation before starting the bank tx all is fine (bit double spend here will be very difficult as well, because Bob does not know the moment when Alice publish the tx).

No does not sound silly at all! :-)

Its great that you offer your help, and I am sure there will be plenty of tasks to pick up and to contribute.
As far the concept is more mature and kind of "signed off" and as far as the core developer team stands, I will try to setup also more organisational stuff, how we organize, etc... I want to keep all transparent and open.
Maybe you can help me soon when setting up a web presence (wikie/blog/forum).
If anybody has good recommendation for webhosters and wiki/blog/forum templates or like to help in that area would be very appreciated.
But for the domain we need to commit to the project name. I am still not sure if the project name "Bank run" is the best choice. I like it but I tend to use a more neutral one.
Any suggestions are welcome!

[k99]

Bounty for successful attacks:

I am asking for somebody who is willing to try with the described protocol to break the system and steal the my BTCs.
There is no software yet, but there are 2 files describing step by step the RPC calls on the Bitcoin qt clients console (or bitcoind).
You can try that out first on testnet to be sure to understand the protocol and not make any mistake to loose real BTC. Also I would recommend to use a wallet with limited funds, you can make easily a mistake and spend all your funds to miners or the like.

I will offer a 0.1 BTC trade at actual Bitstamp price (any direction you prefer) with 0.01 BTC collateral for both sides, the BTC tx fees will be devided.
I only will accept one trade after the other, so if anyone find a way to break it I will not accept more offers.
Also I may stop taking offers after a few rounds when it seems prooven that it is safe.
Real bank transfer will be included as well, to be sure there is no flaw in that part. So the trade may take a few days until it is completed.
All your steps have to be stored in a sheet and passed over in case of problems (priv. keys removed).

If you manage to break it you can keep the 0.11 BTC, but you have to send me the details how you did it. The result will be public.

"Soft" attacks like blackmail, etc. are not considered as successful attacks, I would never agree to a blackmail anyway.
So basically the attack vector would be more in the "implementation" side (usage of the tx procedure like describted in the papers).
Bank chargebacks are also not considered as a successful attack. It would only cause for both much trouble if you try that. My bank will probably not accept it (they told me so) as well, but I prefer to not have too much contact with them ;-)
Ah my Bank account is in EU with SEPA. Others I cannot accept.
If you make any mistake on your side and I can help to recover from that I will help of course, means I will not try to steal your funds.

Alice RPC calls:
https://docs.google.com/document/d/1o4Cwh709Vw_MLKuP8Dz6u7Qk_dmA5WJb0HUsvq1IBas/
Bob RPC calls:
https://docs.google.com/document/d/1YhuIwjCl6AABfspS5VehQiDosxuvdtDjyVOvQkS4Eag/

[UDT - US Dollar Token]

...

You have linked to http://index.php

Thanks waxwing,

It is very odd that it was posted that way, maybe it was my drag and paste acting up again?

The posts have been fixed and I'll quote the first one here.

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.

Here is something that could be integrated into your platform, or used independently. It will provide 'near instant' conversion of digital assets into USD. We're just waiting for contributors to get the project started.

[UDT] US-Dollar-Token, STOP THE ABUSIVE AND UNFAIR PRACTICES AND FEES!

Yay!@SaneBox cleaned out 954 emails, leaving 271 important emails in my Inbox. Try it for free: http://sanebox.com/t/4qw44

[k99]

I am planning to rename the project to BitSquare (bitsquare.io).

What do you guys think about that name? Is is a good name?

The reasons for a change are:
- It helps the project more if it is a more neutral name. Bankrun has some provocative and political touch. I like it but for more mainstream people it might be too extreme. For the project it is better if those mainstream people use it as well. The bigger the user base the better.
- I will redefine the project it a bit into a more generic P2P market place. You can buy anything for BTC. Fiat or any goods. Transport of the non BTC thing will be post or if fiat also bank. The concept is exactly the same.

So BitSquare is more generic:
Square as a symbol for people to meet to interact. Satoshi square was some inspiration for it....

[ShadowOfHarbringer]

I am planning to rename the project to BitSquare (bitsquare.io).

Not bad. But what about bitswap.io ?

Anyway, at this point in the project development (almost) any name you choose will be OK. People will simply get used to it and with time they will associate the name with the function it created.

[k99]

I am planning to rename the project to BitSquare (bitsquare.io).

Not bad. But what about bitswap.io ?

Anyway, at this point in the project development (almost) any name you choose will be OK. People will simply get used to it and with time they will associate the name with the function it created.

bitswap.io is not available anymore. I thought of that as well ;-)

I know the name is not so important yet, but I wanted to setup a wiki soon and a dedicated domain would be better, so I wanted to get that done...

[Sukrim]

https://squareup.com/ might have something against Bitsquare, just sayin'...

[k99]

https://squareup.com/ might have something against Bitsquare, just sayin'...

They have the global rights about the word "square"?

[syph3r]

I don't have a complete analysis, but I think that this scheme is vulnerable to blackmail in a way which is impossible to mitigate. Consider the case in which Alice wants to buy X BTC from Bob. The scheme depends on Alice and Bob both depositing BTC into a shared, multisig address, where Alice deposits cA, some collateral, and Bob deposits cB, his collateral, plus X, the amount of BTC to be purchased. Neither Alice nor Bob can withdraw from the multisig address unilaterally, so it is their best interest to come to an agreement on how to disperse the BTC in the transaction.

An attacker, in this case Alice, who had no intention of actually buying BTC, could at this point suspend the process by telling Bob she has no intention of transferring any money. The value of the transaction is X+cA+cB, and Alice proposes dividing the contents of the transaction evenly between Alice and Bob, and publishes her half of a transaction to this effect. At this point Bob has two options, he can either reject the new agreement and suffer a loss of X+cB, or he can accept the new agreement, complete the transaction, and suffer a loss of only 0.5X + 0.5cB - 0.5cA. It is therefore in Bob's best interest to accept the new agreement. The strategy of simply not agreeing to the blackmail is economically irrational.

The primary reason this attack can succeed is because Bob has committed more resources to the shared transaction than Alice has. You might then suggest that the solution is to raise the value of Alice's collateral cA such that it is equal to Bob's total commitment, cA = X+cB. If cA > X+cB, then Alice has no motivation to proceed with the attack because she will only lose BTC in the process.

However, if cA > X+cB, then Bob can become the attacker. After a sincere Alice has initiated the exchange and transferred the money from her bank account to Bob's, we are in the same situation as before. There is a multisig transaction of value X+cA+cB, and Bob can at this point suspend the the process, and demand that the BTC in the transaction be distributed evenly between Alice and Bob. Alice has more BTC committed to the transaction, and must agree to minimize her loss.

The point of this is that there are no values of cA and cB you can select such that one party isn't motivated to blackmail the other party.

[waxwing]

syph3r,
Yes this is precisely the point I was making in post #104 in this thread. The difference is I made it tersely and you made it thoroughly.

I think you are rather too definitive in saying things like "Alice has more BTC committed to the transaction, and must agree to minimize her loss. " - the word 'must' is not quite appropriate, but of course it is highly important that one side has more to lose than the other, which puts them in a weaker bargaining position.

I also disagree that this issue (the imbalance between the parties) is the *primary* reason such an attack can succeed. It is more a supporting factor. The reason that the attack exists is that the power over the spending out from the multisig address is divided equally between the two parties, with no independent parties (arbiter, oracle etc.) having a say. To enforce a specific payout ratio requires something external - an arbiter, or some reputation cost at the very least.

If it could be enforced that the payout from the multisig was either (1.1,0.1) to Alice and Bob, or (0,0) (they don't agree) then the system would seem relatively sound (i.e. it works with rational and error-free behaviour assumed). But encumbering a utxo to only spend to pre-defined outputs is not possible in Bitcoin.

To put it briefly, In this scheme, the final payout is just a matter of negotiation. This can be countered by saying that a reputation system will dissuade behaviour which is not according to protocol, but then the important part of the system is the reputation system, and not the use of multisig.

[k99]

@syph3r, waxwing:

Thanks for your thoroughly anaysis.
You spotted a really important open weak point.

The second case when Bob blackmail Alice I dont see that dangerous as Alice know his identity (bank tx). So she could use that to protect herself (lawyer) and Bob will be more cautious as he does not know if Alice could become mad and would threaten him.
For the first attack Alice can lie about her ID. So that is a weak point we need to solve. If Bob would know Alice identity, Alice will not risk the consequences of a blackmail.

Here are a few different possible solutions to meet that problem:
1. Use higher collateral for Alice so payments are the same (against Alice blackmail attempt). Bobs blackmail attempt is less dangerous as Alice know his identity from the bank tx.
2. Use higher collateral for both, so the difference gets lower and Alice lose more if the blackmail does not succeed. E.g. 1 btc trade with 2 btc collateral leads to a 2 btc loss for Alice and 3 btc loss for Bob if the blackmail does not succeed.
3. Mutual identity check. Before starting the pay in Bob can ask Alice for some proof of her identity (real life or a social web id). That could be let open and outside the system. So they can freely use different possibilities. Facebook/Twitter/G+ account postings, so the other peer see that he has control over that account and can check the web identity to see if he seems trustful (sock puppets). Use a video chat to show some documents in front of the camara (Bob can request any document, so its more difficult for Alice to have preprepared faked docs). That area need to be more explored. It will not lead to perfect security but maybe to a good enough. 
4. Escrow with SSL dump. That would the technological best solution from a technological point of view. I am not sure how big the problem would be to get the trust from the users to a software accessing their bank transfer session. I personally would feel uncomfortable with that. Even all is open source and proofed, a normal user is confronted with a P2P software wihtout a company behind it, so he will be cautious trusting that software too much and has probably not the ability to proof it for himself. To do only the trade has a limited risk scope (cannot loose more then inside the btc wallet), but any contact to the bank account feels more dangerous. Probably more a kind of "soft" problem, but could be hard to solve.
5. Reputation: Have their own problems and imperfections. But need to be considered as well.

All in all the target of the project is to keep it as simple as possible. To make it more realistic that it get done and that it is easier to understand and use.
A certain risk will always remain. Also with centralized exchanges, people can fake documents for KYC and use stolen bank accounts, etc...
To trade with small volumes will be also a recommended strategy to minimize the risk. Good education and guadance (FAQ, GUI) should help as well.
And finally: The idea is based to use human capabilities to help to overcome the hard problems (interface to bank tx). I think the same could be used to overcome the blackmail problem (Alice). A mutual identity check could be the easiest way. Not a technological solution but a pragmatic one. Assign the task for the KYC check to the traders.
The privacy is broken between the traders. That is unavoidable due the bank transfer. So why not use that power to secure the system.


The blackmail scenarios have been updated in the paper recently.
Here from the actual version of the paper:

Blackmail
Satoshis statement in a discussion regarding his proposal for an escrow model [2]: "Now, an economist would say that a fraudulent seller could start negotiating, such as "release the money and I'll give you half of it back", but at that point, there would be so little trust and so much spite that negotiation is unlikely. Why on earth would the fraudster keep his word and send you half if he's already breaking his word to steal it? I think for modest amounts, almost everyone would refuse on principle alone."

If Bob starts to blackmail Alice he has one problem: Why should Alice trust him that after she payed him that he does release the payment/refund tx? Bob could continue to ask for even more money. That could lead to an infinite blackmail scenario. The only rational reaction from Alice would be to reject the blackmail

But there is another more serious attack variant.
Bob could create a new payment/refund tx with changed outputs to his favor, sign that and send it to Alice as blackmail. Now the situation is different as Alice does not need to trust Bob anymore to get payed that what was negotiated in the blackmail. She can sign and publish and then get payed the BTCs.
But Bob has some serious risk when doing blackmail. Alice know his real life identity due the bank details. She could go to a lawyer to solve the situation.
Another issue is that Bob does not know much about Alice. She could ring his bell the next days and make serious troubles...
Another protection against that attack would be to use a legal contract as described later.

If Alice do that kind of attack it would be even more dangerous as she could lie about her real identity (Bob cannot because of the bank transfer). The legal contract protection will not work here as well as Alice could lie.
A high collateral, reputation systems or a mutual identity proof will be probably the only solution to protect against that.
Another solution could be that Alice has to pay in a higher collateral, to in the deposit tx there is equal payments from both sides, avoiding a blackmail from Alice in the first situation. The second situation (Bob blackmails) is more protected due the fact that Alice know his identity due the bank account.

One important point regarding blackmail is to consider the money is frozen and not destroyed. If you do not accept a blackmail the money will stay there until the blackmailer give up and prefer to get returned his collateral.
A BTC price increase could change his mind as well. If 0.1 BTC is 100 USD then it may be worth his loss to try the blackmail. But what if BTC rise to 10 000 USD and 0.1 BTC is worth 1000 USD? Will he still let that frozen or will he redeem it and therefore unlock the other peers funds? 

[k99]

If it could be enforced that the payout from the multisig was either (1.1,0.1) to Alice and Bob, or (0,0) (they don't agree) then the system would seem relatively sound (i.e. it works with rational and error-free behaviour assumed). But encumbering a utxo to only spend to pre-defined outputs is not possible in Bitcoin.

Accentuation in the quote done by me.

Thanks waxwing for bringing that up again!
It is not possilbe to do this in btc directly, but with an oracle!
That would solve all the blackmail problems.

Make the deposit to an 3 of 3 multisig address. The 3. signer is an oracle proving that the spending tx is like it was defined initially. That can be verified with the hash of the outputs (need to investeigated in details how to do it but that shoud be not a problem).
When the 2 traders want to spend the deposit they need the signature of the oracle and that is another peer (or replicated server) verifying that the output match with the initial ones. If the output has changed the oracle does not sign. That is a fully automated process without any human involvement. The Oracle receive the tx, verify the outputs and publish it if it is valid.
That way any changed output due a blackmail is impossible to get published. Any other blackmail attempt suffer from the weak position of the blackmailer that the other party will not trust him. Something like pay me 0,5 btc and then i will sign the payout tx like it was defined, suffer from the fact that the oterh peer has no guarantee that the blackmailer will not ask for money afterwards, he has no guarantee that he hold his promise, in fact he has many reasons to not trust him.

The oracle should be doable in a pure P2P way, probably your (waxwing) work for the escrow pool can be used for that. Otherwise if a P2P solution will become too complex servers which replicate the data could be used as well. But a pure P2P version would be better of course.
One point to consider is that those peers acting as oracle should not earn money with that, because I assume that would implicate legal issues (they could be considered as a commercial service). Not sure about those legal questions but I think a solution where the oracles work in the background is better (like BTC client doing verification without direct incentive).

To implement the oracle will have its own challenges.
How make sure that there is at least one peer in the network available for that tx for signing?
How to prevent that Alice or Bob are not manage to become an oracle on their own, or control an oracle peer?
How to distribute the private key to a pool of oracles?

All those problems will be difficult, but I assume they are solvable. At least less problematic then the other alternative approaches.

What do you think?

Maybe some other idea from a fresh outsider could be the missing puzzle part?

Earlier I was trying to find a way to break up the communication channel between the peers.
How?
With a trading pool where the peer you payed in is not the same as the one to whom you pay out (randomized, so a blackmail does not hit the right target, you dont know the peer signing your paypout tx).
But that has its own problems with complexity, asymetric and for one side high collateral and that you need to create a pool with other traders doing the same trade volume (5 traders buying 1 BTC for 400 EUR).

Just wanted to post that as inspiration, that maybe a completely new strategy could lead to a solution.

[syph3r]

The second case when Bob blackmail Alice I dont see that dangerous as Alice know his identity (bank tx). So she could use that to protect herself (lawyer) and Bob will be more cautious as he does not know if Alice could become mad and would threaten him. 

If you believe this then your protocol has no purpose. Alice can simply transfer some amount of money to Bob's bank account, and then Bob can transmit an equivalent amount of BTC to Alice, without the need for all this multisig business.