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

As I said before (I think), I wouldn't develop it with PHP running on a server, but rather do it as an Android app running on smartphone. I don't have a lot of spare time at the moment, but I'm willing to help where I can.

Thank you for the response K99!
I definitely do not want to hijack your thread, only contribute my ideas and help suss out possible solutions.

"Interesting idea but i think that is hard to implement and will have a lot of open questions and problems.
- If anyone in that system handle money in behalve of another you are in the regulatory realm
- Dependency to those limited company who support automatic money transfers, they can be shut down or forced to limit those APIs.
- First we need to solve all the open problems in the most simple version (direct 1 to 1 exchange) before getting to that more complex version. But in future there is for sure more headroom for automatism. The Bank interface will be the weakest part always."

The implementation would be "interesting" no doubt, but in the realm of possibility. After all, it involves linking current systems, not creating. Even if we do not use API's, we could use form robots.
1. I may not have explained my concept clearly enough. Some people allow their health club to debit their account a certain amount every month for their health club fees. Many clubs only allow this. Same goes for utilities. This proposal is for the same kind of possible access but on a software basis, where the exchange add-on to the wallet can open an API. We all handle money with others in normal transactions. These transactions will be small enough to not fall under the FinCen rules.
2. I agree completely. That is why there would be limits on the size of the transfers and frequency, to avoid alarms going off.
3. Definitely the right progression. I am learning PHP to work on this project because we need this distributed banking with network management or all the alt currencies are going to end up as curiosities and not viable means of value transfer. That is my fear.

I look forward to seeing how your great idea develops!

@FSCbitfan:
Interesting idea but i think that is hard to implement and will have a lot of open questions and problems.
- If anyone in that system handle money in behalve of another you are in the regulatory realm
- Dependency to those limited company who support automatic money transfers, they can be shut down or forced to limit those APIs.
- First we need to solve all the open problems in the most simple version (direct 1 to 1 exchange) before getting to that more complex version. But in future there is for sure more headroom for automatism. The Bank interface will be the weakest part always.

Hello fellow alt currency fans,
I was excited to see this well developed thread because I have the same concern about Bitcoin having all the fiat exits shuttered. I came up with an idea that differs markedly from this great looking proposal. My concept would preserve the general anonymity of both the buyer and seller on both ends.

There are probably holes a mile wide in my idea, but healthy discussion and discovery is what the forum is for.

Here are the notes I scribbled about my concept:

The idea is to do away with centralized exchanges like MtGox, Bitstamp, Btc-e, coinbase or anywhere that the opfor will look to shut down a BTC/Fiat exchange.

Use the alt coin wallets that all users have for the coins and add an exchange software.
1. Each user adds a Dwolla, Paypal, Bank, Western Union or any other money transfer account to the back end of their alt coin wallet. Same security applies with any API. 2FA or any level suggested by the user. This is open source code.
2. The user selects a percentage of their account or a set amount they are willing to exchange for a given time frame. For example, $300/month through Dwolla.
3. The user then becomes part of a network of pooled mini exchangers.
4. A person who wants to exchange alt coins or currency for alt coins then accesses a website that issues a one time wallet or account for them to send funds to. They do not know who the account holder is, nor does the other person know who they are, as they can send money by Western Union or other methods, possibly including deposit into ATM.
5. Then the network of mini exchanges, controlled by software, confirms the deposit and routes the exchange to the anonymous mini exchanges who then handle the transaction. For example, if a Fred wants to exchange 10 BTC for USD (crazy I know..), the network software would poll for the equivalent number of mini exchangers like Wilma, Barney, Dino and however many other mini-exchangers to combine for the total equivalent of $4670 in USD. Each mini-exchanger can either agree to complete their preauthorized exchange or cancel. The network would then go to option 2, 3, etc. This could also be completely automatic if a user/mini-exchanger wishes to honor all requests for exchange per their limits.
6. No one knows who is getting what from whom. Complete anonymity, as much as is possible.
7. Small or large amounts can be handled by combining many mini exchanges.
8. No one person or company to arrest, because everything is only small dollar amounts.
9. The person initiating the exchange sends their coin in to the address where the software would then distribute it to the mini exchangers. Upon confirmation, the software would complete the out exchange through the agreed intermediaries set-up by the mini-exchangers.

Just like we can send checks, ACH's, SWIFT payments, Western Union, Dwolla payments, paypal, etc. this system could disperse the payment process so everything appears to be from multiple sources without the central exchange as the bottle neck.

 

Whadya think?

Interesting: Satoshi has planned a P2P market inside Bitcoin in his original version.

Here the source code:
https://bitcointalksearch.org/topic/v01-68121

Yes the influence of price volatility is discussed in the paper.

Price volatility
A change in the BTC price will only affect Alice in the time period between publishing the deposit tx and starting her bank transfer. If she notice a price change against her favor (price falls, so she pays too much to Bob) she could decide to not continue and take in account to lose her collateral. The price change must be larger than the collateral to lead her to that decision. Assuming that the time period will be less than a few hours (to protect against double spend she should wait at least 1 confirmation or 6 confirmations to be totally safe -> 10 - 60 min.), it is not very likely that with an already low collateral of 10% (like in the example) the price change in such a small time span will exceed 10%.
But nothing prevents the parties to use a higher collateral in times of high volatility.

For Bob the volatility has no influence when he has the possibility to break the contract at the end of the trade. If he does not release the payment/refund tx he will lose his collateral. It does not matter if the value of the collateral is now less than it was in the beginning of the trade as long as it is more than zero.

Maybe the following scenario has already been discussed in this thread, but I missed it:

Bob wants to sell his BTC to Alice so he sends his BTC and colleteral to the multisig address.
Alice agrees to the trade and sends her colleteral to the multisig adress to lock the funds.
Meanwhile the price rallies which is not uncommon for BTC so Alice has second thoughts about her commitment to Bob.
She decides to keep the funds locked up until prices have come down, after all only her colleteral is locked in the tx and she spend the fiat on something else.
...
Bob gets angry with this fancy new program and decides to hit the pub.


What I have described here is a common problem for low latency trades such as localbitcoin or similar. In times of heavy price movement many trades get aborted.
I think the issue could easily be fixed by higher colleterals according to volatility.

@Duane Vick
Your first an second points are valid and they both have been solved for Bankrun.
First, the seller's BTC are locked in a multisig address (a.k.a escrow address) before the buyer sends fiat.
Second, all possibilities of blackmail are removed by having both parties sign a transaction disposing of escrow address coins in only one agreed-upon manner. After that both parties' signing key are deleted by the software.

I see a few things that has to happen to absolutely remove the threat of blackmail. First, the BTC seller has to already have the funds in a state of transfer before cash is sent. Second, the parties to the transaction can't have a say in the final disposition of BTC.

For the first thing to happen, a temporary address has to be created and the coins have to go there so that the seller can't avoid following through with his obligation in the transaction. On settlement, the buyer can simply receive the private key to this address.

For the second thing to happen, there has to be an escrow agent(s) to determine the proper disposition of the held coin. Agents would also need a way to verify the fiat transfer and the presence of the correct amount of BTC in the temporary address according to the contract terms.

I discussed a way to make this possible earlier in this thread and also started my own thread to discuss it. https://bitcointalksearch.org/topic/consensus-fiat-to-crypto-p2p-exchange-concept-475874

Perhaps there is a way to incorporate it into this project.

Re 1:
Are you sure with that? I think that in the 2. tx you need the tx id from the first, so if tx1 has not been created you cannot sign or even create the 2. tx. If you meant that tx1 is not published then I agree. Or maybe I misunderstood...

Re 2: yes that could be powerful, but I have not found a way how it makes sense in our protocol.

Re 4: I was looking for a way to use locktime to make a refund. But I think there is no way in our protocol as Bob would lie that he recieved the fiat and would wait for the timeout to get back his funds.

Yes you are right. But still point one stays valid, he has costs. The relation of costs and acceptance rate will be the key.
If 33% of people would accept a blackmail and the collateral is 50% he would lose for sure.
1 btc trace, 0,5 btc collateral. blackmail deal: both get the half.
deposit tx has 0,5+1,5=2
if he win he gets 1 so a net win of 0,5.
if he loses he loses 0,5.
if 2 times lost: -1
one time win: +0,5
sum -0,5
He will not do that often...

Of course if the accept rate is high and the collateral low he will hit the "break even".
The attack is more dangerous in the 1. scenario (Alice is blackmailer) as in the 2. with the bank tx Alice has the id of Bob.
So Bob has additional risk if trying to blackmail (maybe an  irrational dangerous Alice).

To protect agains scenario 1 we could also introduce asymmetric collaterals so both have the same to lose.
If Alice has to put in 1,1 as collateral and Bob 0,1 collateral + 1 for payment = 1,1 then Alice has no reason to blackmail anymore.
Bob knows she would lose the same, so he would be very irrational to accept if Alice want e.g. 2 btc and would give Bob 0,2 btc.

We have a few diffent weapons to fight all those blackmail risks:
1. Collateral height -> costs for blackmail
2. Low trade volume -> low gain when blackmail, less reason for accepting a blackmail
3. Alice provide identification to Bob: Facebook/Twitter/G+, web page, blog, forums, present in web cam documents which Bob request,... If Bob is not 100% convinced he can cancel.
4. Asymmetric collateral. Alice pays in the same as Bob. Increases the blackmail risk in scenario 2.
5. Use feedback from statistical analysis of the trades tx in the blockchain and/or sentiment of scam rate from postings in forums
to adjust the recommended collateral height.
 
We can let the traders mix those elements in a way like they prefer.
So Alice could make an offer with 50% coll. and accept asym. coll. as well as identification check from Bob, so it will be easy to find a trading partner as it seems she is very trustful, and therefor she will get a better price as well. If Alice is on the other extreme, then the peer should be carefully and better not trade with her.

Yes probably Satoshi has had good reasons to not allow that.

Here is a possible solution for the blackmail attack of changing the payout tx, sign it and send it to the other peer.
That is dangerous because it would be an atomic operation. The victim does not need to trust the blackmailer that he keeps his promise as he has already signed. The victim has the payment tx in his hand and if he sign and publish he gets a part of the money back. That would be a rational behaviour, so the Nash equilibrium is not met anymore.

dansmith_btc has brought up a great idea. Destroy the private key after signing, then nobody could blackmail you to change the payout tx, as you simply cannot do it without the private key.
Lets describe roughly the protocol how it could work (needs a bit more investigation and test with RPC calls to confirm if all is correct).

Bob creates a 3 of 3 Multisig address with 2 pub keys of him and 1 from Alice. Lets call Bobs keypairs Key1, Key2.
Key 1 is used for signing the payout tx after he has received the Fiat from Alice. Key 2 is used to make the output defined in the initial agreed payout tx un-changeable. He will destroy that key after signing, so Alice cannot negotiate later in a blackmail attack to change the outputs to her favor.

Bob creates the deposit tx.
Bob creates the payout tx, signs with Key2 and destroys then Key 2.
Bob signs the deposit tx and sends it together with the payout tx to Alice.
Alice signs the deposit tx and publishes it.

At that moment Alice was with the old protocol in the attack scenario where she could blackmail Bob as Bob has more funds locked.
Now she know that Bob has deleted the key (the software works like that) and Bob has no chance to change the payout tx. The one and only payout tx which can be ever used to release the funds is singed by Bobs Key2 which is already deleted. So no way to create a different one with other outputs.

She has to continue in the protocol to not lose her collateral.
She pays in the Fiat to Bobs bank account.
She signs the payout tx and sends it to Bob. That tx has now 2 signatures: Alice and Key2 from Bob. Key1 from Bob is missing.
After Bob has received the Fiat in his bank account he signs the tx with Key1 and publishes the tx.

But there is still a second attack scenario.
Bob could have secretly kept Key2 (he used some tool to create the payout tx and not destroy Key2) and now try to blackmail Alice. He can create a new tx to his favor and sign with Key1 and Key2 and send it to Alice. Then if Alice would be rational she would take that, sign it and publish it to get at least a part of the payout.

To prevent that we can simply build in the key deletion in the step when Alice signs the payout tx.
If the software deletes the key, Bob knows Alice has no chance to sign a new tx with changed payout.
The one and only valid payout tx is the initial one.

Thanks dansmith_btc. We have a new nice tool in the limited btc toolbox.  

Ah, but please read my message again about how you can subvert a reputation system by simply revealing your *true* identity after establishing contact as "Bob" --> (Hackers Inc).

To repeat, I believe this highlights the need to enforce significant costs for identity creation, which itself brings up the point of how those costs are managed in a decentralised way.

I specifically asked on #bitcoin-dev whether it's possible in any way to encumber a utxo so as to fix its output in anyway. sipa told me it isn't possible and said I could take a look at the "coincovenant" idea for exotic ways to try to make it work (involves SCIP and so forth).

To be fair, it does kind of make sense that utxos should not be encumber-able, since that breaks the fungibility of coins. So, signatures enact control over utxos and can be all kinds of exotic things, but control of that utxo is binary - either you can demonstrate control with the appropriate signature(s), or you can't. No inbetween state - your signature entitles you to pay out to Charlie, but not to Dave. Maybe a coin or altcoin could work like that - I haven't thought about it much - but it seems bitcoin doesn't.

I think the cryptolocker blackmail situation is very different:
1. As you pointed out asymmetry. He has no costs. Alice has cost of her collateral if Bob does not accept the blackmail. If the collateral is higher than in my example, say 50% or 100% then this are considerable costs.
2. Cryptolocker use one "identity" and people can predict his strategy, means that he holds his promise to unlock after payment.
Alice and Bob are changing random strangers. If Bob has the experience once that Alice has kept her promise, that experience does not mean anyhing that another Alice will act the same.

I think that blackmail scenario (2 phase) will not work when assuming a pure rational behaviour.
A rational actor would not accept because he has zero guarantee that the blackmailer will keep his promise. In fact the blackmailer has proven that he does not deserve trust, so to trust him again for paying and hoping he hold his word, is irrational IMO.

That does not mean that it cannot happen. The assumption of rational traders is a weak point as well.
A blackmail creates an irrational behaviour for the other party which could lead to the opposite behaviour of what the blackmailer was intending.
For me, I am pretty sure I would not accept it for pure principle reasons. I would hate that person and not pay him a cent. Even in the 1 phase scenario (then I would act irrational because of my anger, I would prefer to lose 1 BTC rather then to pay 0,5 to that asshole).
So it is very hard to predict how people will react when getting irrational. It is a risk for the attacker as well. Some could run amok and beat up the blackmailer (depending on the attack situation the ID is known to the other).

Another point is that due the bank transfer we are not dealing with a real global exchange. A bank tx from Russia to Chile will be very expensive, so they will not offer those trades. There are different risk levels in different countries and the people in those countries are more cautious as the are used to the situation. That could help as well to lower the real risk.

But it is still the question if we need additional protection (reputation system, escrow,...) to solve those problems.
Unfortunately all those solutions introduce new problems and are imperfect on their own (sybil,...) as well adding complexity which creates problem on its own (usability, security, bugs, new attack vectors,...).

For me it seems a better approach to keep it as simple as possible, limit the trade volume to a less hurting value, set the collateral flexible to the appearance of scams (if a lot of scams put it 100% or more, if low scam rate you can use a lower collateral) and maybe use a simple flexible mutual identification process (exchange facebook/twitter/G+ accounts,...).

A flexible combination could meet different needs as well.
If a user prefers to put in a high collateral and not use the mutual identification process it is ok as well. If the collateral is very low he will not find offer taker if he does not accept mutual identification.
It could be a flexible setup of a few simple adjustments which will never prevent scam to 100% but make it less likly and harder and more expensive for the attacker.

We also need to consider that there is no perfect save solution.
If fact many of our existing solution in the financial area are terribly insecure:
Credit cards would never have passed a security audit in the btc community. NEVER! It is a terrible concept.
Paypal the same.
But both are super mainstream.
Because they took into account a scam rate and covered the costs with a hefty fee. The credit card fees can be seen as an insurance fee.

What I want to say with that is we have to be also pragmatic. Many imperfect solutions work pretty well in reality.
That does not mean we should ignore weaknesses!
In contrary I am very thanksful for the good analysis posted here!
Thats the power of open source, 1000 eyes see more then 2 eyes.

We will keep on to investigate alternative protection mechanisms for the remaining open risks. Some are described in the paper (updated recently), others need more investigations.

For the more serious blackmail problem with the 1 phase blackmail attacker, I think we found a solution. I will post that in a new post extra... already way too long post....

Sorry I am not native english speaker and my english is not real good I know.
If you have time to help out here it would be great. I send you a PM then I can give you write access.

There is a fine difference. Bad intention or just failure without proof of bad intention.
Assume a navie protocal where Alice pays first then Bob. If Bob never pays and Alice appears with a laywer at his house, he always can say, sorry i had an accident, or was ill or forgot... nobody could proof he was a scammer.
In our protocol a blackmail is clear an attempt to scam. If Alice appears with a laywer at his house, he has pretty bad cards.
Knowing that Alice know his real ID from the bank details, he should fear some real troubles if he tries to scam Alice. He has no idea if Alice is a innocent girl or the sister of a mafia boss.

I'm pretty sure that there's a good solution. 

I want to think about it for a while and work out the details, but right off the bat, we need to remember some of the tools that are available.

1)  A transaction to spend bitcoins from a given utxo can exist and be witnessed (possibly even signed) by both Alice and Bob before the utxo itself is created.  Either one may be "holding" this transaction and ready to release it when the utxo appears on the blockchain.

2)  A script can hash any secret and compare the result to a blob, releasing the coins to spend if the hash matches.  So if Alice creates the secret she can create a transaction that includes the hash of the secret, while never giving the secret away.  But if she uses the secret to spend the coins, then Bob can learn the secret from the blockchain - and that could enable him to spend a different utxo, possibly from a different transaction. 

3)  A script can release coins on any of several conditions.  For example, a 2-of-2 multisig *OR* a secret whose hash matches. 

4)  A transaction, even one signed by all parties involved, can be invalid until a given lock time - thus even if it is released on the network it will not take effect until someone has had a chance to execute a different transaction.   So in the event that someone is being obnoxious and refusing to cooperate, "refund" transactions could take place (or become available for the other party to exercise) after some delay if the obnoxious person refuses to go through with the original transaction as mutually intended.

I just can't believe that with all these tools available we can't manage to lock down the ratio of the final payouts before the money is sent to  the txout where it gets paid out from.

Yes, I have been thinking about this since I made the post and find myself having similar thoughts.

Take the case of cryptolocker. The reason that victims pay out is, at least partially, that the cryptolocker "team" has shown evidence of following up on their commitments. To be fair, the power asymmetry is absolute here - cryptolocker loses nothing in the default case. So it's not the same.

I came to the conclusion that the only defence is in the cost of identity creation. Even if you have a well defined reputation system, it can be somewhat subverted like this - the attackers can continually create a variety of identities and then in PM tell the victim their *real* identity (Hackers Inc), using a PGP key or something less technical but enough to convince the average user, and their "off channel" reputation as reliable in completing the transaction once ransom is paid will then come into effect.
To avoid that, the cost of identity creation has to be at least around the size of a large transaction, otherwise it might well be economically effect to carry out these "two phase" attacks. And in a purely P2P solution, how is the cost of an identity enforced anyway? Someone or something (an oracle?) has to be the arbiter of whether a particular identity has violated protocol rules.
The other alternative - a fidelity bond/sacrifice cost - each new identity destroys $1000 before starting to use the system - is hardly palatable.