Topic: tlsnotary - cryptographic proof of fiat transfer for p2p exchanges - page 6. (Read 42851 times)

I know that many people drive drunk.
This may be against the law (and really f*cking stupid), but they do it anyway.

People do stupid things all the time, and most parents teach their children that just because other people are doing stupid things, that doesn't mean they should do them too.

You aren't just 'using a proxy', you are deliberately another person access to your supposedly secure bank connection.
This is a bad idea.
If you bank finds out that you have done it, they may well cancel your account, and would certainly refuse to compensate you for any fraud that happened on your account.

I know that many people are sharing their bank account credentials with another company (i.e. http://de.wikipedia.org/wiki/Sofort%C3%BCberweisung). This is maybe against the TOS of the banks, but they do it anyway.
Furthermore antitrust agencies have said that these TOS are invalid, because they would exclude some companies from the market (c.f. http://www.bvdw.org/mybvdw/media/view/prozess-giropay-vs-sofortueberweisungde-bundeskartellamt-nimmt-stellung-agb-der-banken-kartellrechtswidrig?media=2775).
So in practice you see that people do share even their login credentials. And you can see that it is allowed to do that.
Now, the system described here would not even share your login-credentials. I don't think that banks could deny someone to use a proxy server. In the end every internet traffic is routed via some other servers. So how should they have some TOS to prevent that?
In the end you don't even have to share your session key with someone. It might be enough to submit it to the Amazon AWS server which will then just provide the proof-of-payment. And the Amazon AWS server is not really a person, it is just a software which is running in between and no real person has access to your keys.

And any sensible buyer would say: "Hell, no, I'm not going to do that."
This has to be against the TOS of any online banking service, and would leave the buyer open to fraud with no protection from their bank, if it is found out that they have shared their session like this.

yes, I completely agree. That is what I wanted to say by identity=[ public_key, hash(bank-account-number) ].
So you would associate your public_key with a hash of your bank-account-number. Of course, to submit your identity to the other peers, you would have to sign it with your corresponding private_key and thereby linking your public_key to your bank-account.

Thanks for your efforts in understanding and critiquing.

I have always thought that, indeed, it's better if the escrow is chosen at random. I think I proposed something similar among these pages. The alpha test will not include this feature.

But I think maybe you haven't understood fully the power that the oracle brings: if the seller suspects that the escrow is in cahoots with the buyer after a dispute, there is nothing stopping him from asking for independent verification: he requests an access key to the system and the ssl session key so that he can also verify by accessing the oracle, what the html page says (remember: the buyer has provided a key for ONE html page which provides proof of his transfer without exposing his login credentials).
If the escrow refuses to hand over those keys he has proved he is a fraud. If he hands over the wrong session key it will decrypt nothing - again proving fraud.
It works only because you can prove exactly what program is running on the oracle, and it cannot be tampered with, including by the escrow.

It's true though that a given escrow could commit exactly one fraud via this method, since he's in control of a 2 of 3 multisig address. Until we are able to construct an oracle which interprets all html bank statements correctly, this will always be true.

This problem *could* be mitigated by the escrow posting collateral to another multisig, such that his bitcoins are lost if he commits this transparent fraud. Then we have to be careful not to create a centralised system - with one or more "super-escrows" acting as police over other escrows. This might be too much centralisation, although I am not completely against a system like that. And if you try to distribute a LOT you might get another problem - 13 of 13 multisig is all very well, but what if 1 of the 13 dies?

So this comes back to your (and my) point that the system works much better if escrows are chosen randomly - but don't ignore the HUGE step forward that an oracle represents.


Yes, at first glance, this looks like one viable approach for random choice. I guess there would be a few ways to do it.

However I want to ask about identity: earlier in the thread you suggested it was better to make identities stick to bank accounts rather than hash(BTC add, bank account), and I realised that this was a good point, because anyone can create a BTC address any time, and so could create identities too easily.
I think this is an important issue and I'm not sure about it.

The identity has to have two properties: there should be at least some cost to creating one, but also it should be impossible to impersonate. Public bank account details satisfy the first but not the second. So maybe the best is indeed to combine a bitcoin address with a bank account but not in such a simple way as hash(BTC+BA). It could be requiring a signed message with the bitcoin address used at account creation time, as well as provision of hash of bank details. That way an attempt to create a second account with the same bank account but different bitcoin address would not be allowed, because the hash of the bank account would be a collision.

I am still confused how you want to make sure that the escrow is not in cahoots with the buyer. If the buyer can arbitrarily choose an escrow, as you said, then he could also just setup his own escrow service and thereby completely scam the seller. Maybe I just don't get your idea, how you want that the buyer can choose the escrow...?

I think this decentralized exchange needs two important things:
1) The escrow has to be chosen pseudo-randomly such that neither the buyer nor the seller have influence on this decision.
2) The p2p-system must prevent sybil attacks, where an attacker could flood the system with his own escrow services and use them to scam other traders.

Here are my thoughts on this problem (if it is a problem at all?), and how it might be possible to solve both points:
The idea is to use the block hashes of the bitcoin blockchain as a pseudo random stream to select an escrow.
For example:
All exchange users (buyers,sellers,escrows) have an identity=[ public_key, hash(bank-account-number) ]. If buyer and seller agree to a trade (i.e. through a bitmessage order book as you said), then this trade will be broadcasted to all users. Therefore both trading partners and their identities and the amount will be available for the public. Similar to bitcoin transactions you can compute a hash of this trade. Now based on the hash of the trade and the hash of the next bitcoin block, another user is pseudo-randomly selected. The selection might work like this:
each exchange userXY can calculate his individual score to be the escrow in the broadcasted trade:
score_userXY = hash(identity_userXY XOR hash(trade) XOR hash(next_bitcoin_block))
Everyone can claim to be the escrow service, but only the user with the lowest score will win and be the escrow for this particular trade. By this procedure, the p2p-exchange has pseudo randomly selected the escrow...

Hope my explanation somehow makes sense and could be helpful in any way...

I'm not sure exactly what you mean by "completely decentralized" but basically I think you need me to give an overview of the current setup. This is the setup that dansmith is planning to release for testing soon:

There are four parties involved, although one is not human.
The buyer, the seller, the "oracle" and the escrow. The oracle is set up on an Amazon aws instance in such a way that anyone can verify that it is running the correct code. That code exists to audit an internet banking session. More on that in a minute.
The buyer would need to test his internet banking (or just know) in advance to make sure that it shows clear proof of a previously sent wire transfer. If it does, he can use the system like this: choose an escrow and his/her corresponding oracle machine. Then, find a seller similar to how currently done on localbitcoins, i.e. on a website or similar public board like a bitmessage channel for example, with compatible bank account. Discuss and come to agreement on price etc. Then bitcoins are placed in 2 of 3 multisig with escrow by seller. When that's confirmed, buyer does internet banking without any auditing, just directly.

Lastly (the important bit, that usually will not happen), if there's a dispute from the seller after the appropriate waiting time, the escrow asks the buyer to log in to oracle machine with previously agreed credentials and run internet banking using the firefox plugin which enables (a) the internet banking to be proxied through the oracle machine and (b)some ssl stuff, in particular a button to press to clear the ssl cache so that the buyer controls which html pages will get exposed.
Finally, the buyer will send the specific ssl session key that allows the escrow to read that specific html page showing proof of his wire transfer (in particular, of course, the bank account number sent to and the amount). This will enable the escrow to resolve the dispute.

Hope that helps.

Edit: you may be wondering, as I did initially, what extra value the oracle brings if we still have to trust the escrow to interpret the html records. The point is that the oracle represents a uniquely trustable agent, so the network audit record that it stores has a privileged position. If a buyer decided that the escrow was lying in his interpretation of the html result, he could call for a second opinion from another escrow, who could also see the html (if the buyer gave him the keys). Thus outright lying by an escrow would not hold.

Thank's for the update. how are you implementing the synchronization of buyer, seller and escrow? Hopefully it is completely decentralized in a p2p system.
Do you already have some specific system in mind?

+1 That all sounds great.

A couple of small updates for those following the thread.
We have found a way to ensure that the login and other private information is not exposed. Experiments have verified that it's possible to send ONLY one html page when there is a dispute. I can't say that it will ALWAYS work, but I think it probably will always work - it has done so far.

If the audit is performed concurrent with the transaction, this means sending only an acknowledgement of sending page - which (for my bank at least) means just sending the receiving and sending account details and the amount (and not exposing account balances).

If the audit is performed after the transaction,as currently implemented by dansmith, (in case of dispute only), and as I know most people will prefer, this would mean exposing some kind of statement page - the details will depend on the user's bank, which he or she should verify before using the system.

dansmith is making very rapid progress with the lightweight, oracle-style code based on AMI instances that he described briefly earlier, but I'll let him give you his update on that.

As for me I have been writing a much "bigger" style of app, synchronising buyer, seller and escrow; this model will almost certainly not be used, at least initially, but it has given me plenty of opportunities to test the core architecture and I've been able to verify through hundreds of tests that the ssl logging is working as we want. I even managed to handle dropped connections, although that won't actually impact the initial version that ds is releasing.

On identities: here is my current opinion.
The whole aspect of reputation and collateral is not completely clear to me yet, but I much prefer models based on limiting amounts until a user has transactions under their belt, such as that proposed by nomailing in post 117 in this thread (although probably not as restrictive as that).

I believe that users should approach the system with two things in mind: (a)direct counterparty risk through fraud is eliminated by this system and (b)indirect counterparty risk (mainly, receipt of stolen funds) is their responsibility as a user, and we HELP them to make an informed decision by providing background information, but they should follow good practice. I.e. follow the advice to sellers given on the localbitcoins website, including identity checks but FAR more importantly, limiting transaction size with untrusted buyers.
I much prefer this to a collateral method of disincentive.

In particular I would like to preserve the property that the system would allow at least SOME kind of bitcoin buying by bitcoin non-owners (imagine that you could tell people they can just "buy some bitcoins" direct from their bank account with no security concerns; they would only be able to buy a small amount, maybe max $100, but think how powerful that is in terms of spreading the word).


Would really welcome further thoughts on this, I think it's pretty crucial.

You're tying yourself up in knots trying to program for some insane regulatory hurdles that your users will most likely never encounter ... a simple cost/benefit will show you are wasting your time if AML of specific country's (of which there are hundreds)  is your driving s/ware design concerns.

E.g. leave a space where others can add-in a module or etc if they want it ... wash your hands of it and concentrate on the core. (charge them later for the extra)

Exactly that is what I suggested just a few posts ago (https://bitcointalksearch.org/topic/m.3279085).


I would definitely call this AML. As you said it is theft of fiat money, but at the same time you would be converting this into bitcoins. And if the criminal can transfer it to bitcoin, then he already has done the most difficult part of money laundering. Then he could just setup a site and anonymously donate bitcoins to himself and it is legal money.

Look at the example of bitcoin24. It was seized 4 months ago, because money was transferred from stolen bank accounts to the exchange and converted to bitcoins. This was called AML. So I do not see your point, why you wouldn't call this money laundering? Of course, AML compliance would be even more, but to prevent exchange of stolen fiat to bitcoin is a major part of AML.


*EDIT* But, probably, it's not very useful to further discuss about definitions of AML. So, I can agree to your definition of AML, if you want. It was not my intention to focus on this term. I just wanted to point out, that the p2p-exchange should use an identity=[pub_key,hash(IBAN)]. The drawback is that this will reveal all your historic trades to everyone who knows your IBAN. I thought that someone would have a better solution at hand. Actually, the idea of Mike Hearn using the passport data might be another better technical solution...

OK.


Sure. I just wouldn't call that "AML". The idea of hashing one's IBAN for example, could be enough.


No, that would be theft. Money laundering would be when/if the thief makes the stolen money a fake part of some official, declared income. That normally only needs to happen for large amounts of money, as for anything small, the thief could just spend it under the radar, without having to launder anything.

I'm being pedantic because "money laundering" is increasingly becoming a magic word, like "terrorism", used to justify all sorts of things.

I am talking about the big traders (>100€) and not about the p2p system itself. Of course, small traders might be lucky and not be a victim.
So, I just wanted to stress out, that these considerations are on a completely different level in comparison to considerations if p2p filesharing is legal or if bitcoin is legal. Because you are using the banking system to do money transfers from users whom you might not know. Therefore, if you want to have a usable system, then you have to deal with these issues.

No, I haven't said it is dumb to trade on localbitcoins. They have some mechanisms which prevent users to massively cash out hacked bank accounts. If you read my posts, you will see, that what I actually proposed is similar to the rating system on localbitcoins, but it would work in the p2p system.
Let me give you a counter question: Do you think, that localbitcoins would work without any rating system?
So my whole point is that the p2p system needs some mechanism to prevent hacked bank accounts wiring money. Actually, this is some minimal AML compliance, because if someone wants to cash out hacked bank accounts it is basically money laundering. This is not just important to comply with the law, but it is a fundamental part of the exchange to work.

AML laws typically have thresholds on them so people can't get whacked just for using cash in reasonable, day to day amounts.

The thresholds fall constantly either because they don't get adjusted for inflation, or are deliberately lowered. Overall the trend is for governments to try "boiling the frog" when it comes to cash transactions (yes I know frogs don't really boil alive).

Whether you are in compliance or not is difficult to say because the laws are so hopelessly vague. In most jurisdictions it won't be an issue. If you start doing a lot of local trading and it is some significant income for you, you may or may not attract attention, and if it turns out that some SR dealers are cashing out through you and the police catch wind of that, then you might be in trouble regardless of the thresholds.

Really, it's a mess. But as I said. AML is just one aspect of that. Stopping hacked bank accounts wiring money to you is an equally important aspect that killed off a few of the early more amateurish exchanges.

Are you talking about big traders operating under such system, or the system itself?
Because saying the latter is like saying e-bay is legally responsible for, say, regulatory compliance in the selling of every electronics (or whatever) that goes through them. I know some jurisdictions are that authoritarian (Brazil comes immediately to my mind), but there must be some others where you could place your business and just be fine...


I've used localbitcoins sometimes, and I doubt they have any AML compliance on their side. I obviously don't have on my side, I'm just an individual trading a few bucks, not a professional. So... are you calling me dumb? 

The problem of cashing out hacked bank accounts is reason enough that people have to do this. Even with no government in place at all banks own your money so they can blacklist wire destinations at any time, and they do. They don't care that it was their fault (or their customers fault), they just see repeated reports of "Someone wired my money to IBAN 1234 and it was fraudulent" and decide there's a simple fix.

I think you underestimate the implications if you are doing money transfers in the normal banking system without AML in place. This would be criminal activity and is not comparable to some kind of p2p downloading of copyrighted files or mining p2p-coins or whatever.
If you would setup the system without AML, then:
1) smart people will just not use it, because they are aware of the risks
2) dumb people will use it and will be victims. Sooner or later they will get letters from law enforcement that they were doing criminal buisness.
3) hackers will use it to cash out hacked bank accounts

I don't think that is what you want. Also think about the implications that would have on the bitcoin system itself. So better think about AML if you are trying to interface a p2p-trading system with the legacy banking system.

Try not to get side-tracked with the AML stuff, it is an unnecessary complication ... it's p2p not "Big Brother says"

I think that approach makes a lot of sense, nomailing. The exact details like times, amounts could be changed of course.

It's worth keeping in mind: how is our proposed system different from others? If you make a transfer via localbitcoins using wire transfer (pretty popular from looking at the site), you are in the same situation as you are with our system. What is different is (a) having ACTUAL verification of transfer so escrow can work properly (not some stupid photoshopped bank statement), and even automatically most of the time, and (b) we CAN move to a really decentralized model (and I hope we will).

If you read the localbitcoins advice to users, they basically leave it up to the seller to verify identify if it seems to be necessary, as well as take a number of other precautions (see "Risk assessment and migitation" on the page https://localbitcoins.com/guides/how-to-sell-bitcoins-online). And when it comes to resolving dispute they say "Localbitcoins staff will resolve dispute". Yes, exactly...