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

Well I agree that in the "two-phase" blackmail scenario, the argument for Alice to comply is less clear since there's nothing forcing Bob to release the initial transaction once he receives payment from Alice. I would just point out, however, that this type of "two-phase" blackmail is attempted in real life, and the blackmailed party often complies, even if they have no guarantee the blackmailer won't follow through with their threat, or that no future blackmail will occur. In other words, in the face of large potential losses, actors do not necessarily behave rationally. If you concede that this is the case, it may be worth it for Bob to at least attempt a large number of blackmail attacks, hoping he'll find a target that complies with his request. This could result in a loss for all of Bob's targets, including the ones that don't comply. Whether this attack makes sense depends on how costly it is for Bob to initiate an attack, the potential reward of a successful attack, and the distribution of compliant victims.

That is certainly a good observation, but as Manfred pointed out early in the discussion, this kind of "two-phase" blackmail is not a credible threat. Satoshi addressed it as follows (I paraphrase, I don't have the quote to hand) - if a counterparty blackmails you and requires upfront payment, they have already shown no trust, so why should you trust them that they will do what they say after you make that payment?

You see the critical difference? In that attack you and I described, there is one, atomic transaction. If blackmail involves more than one step, it is not going to work - the only rational option for the victim is just to default.

After thinking about this some more, I agree with this.

I think this is an interesting observation, but this may still be vulnerable to attack. Bob can still hold the transaction hostage, promising only to release it if Alice transfers some amount of BTC to Bob in another, unrelated transaction. Again, Alice is probably motivated to comply to minimize her loss.

I appreciate your idea. However, my humble request is correct spell and grammatical errors please. If I am able to spend time, I will lend a hand to you.

Good luck.

this is a great system as far as i understand.

please make it happen. i think the developers should focus on some projects like this. The funds or costs not important because pretty sure that there will be huge donations for a legit stable project.

This is good thinking. At first glance it looks like the right approach. This is how oracles were intended to be - just verification of something objective.
The oracle being in possession of a signing key raises the security stakes of course, but that's handle-able I think.

The remaining question is how to implement the oracle. dansmith came up with an extremely clever scheme to make an effective oracle using an Amazon EC2 instance (you can read about it on the ssl logging thread) and implemented it in November. You can see detailed discussion kicking off from around this post: https://bitcointalksearch.org/topic/m.3429555

We tried out the technology a few times and it seems to work well. However, it is a complex architecture and bases the trust in the oracle on a bootstrap of the trust in Amazon certificates, ultimately. I don't think this is a practical problem at all, in terms of validity and trust, to be honest, but building systems that way has its architectural limitations of course.
The problem is the lack of Zero Knowledge Proof working technologies - that's what's needed (look into SCIP for example) to make pure oracles.
In the absence of that, dansmith's style of oracle is a practical approach. It's just technically somewhat fragile so requires a lot of care and attention.

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.

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, 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? 

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.

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.

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

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

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

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.

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

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.

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/

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!

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.