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? 

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.

Exactly that is what I suggested just a few posts ago (https://bt.irlbtc.com/view/173220.msg3279085#msg3279085).


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

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.

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. <Some of the details here need fleshing out> 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.

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.

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.

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 just say, that it cannot be against the law. If you connect to your banking website, then your connection is routed via many different software components. And in the end the Amazon AWS instance will also just be another software which is routing your traffic to the bank. So how should they prohibit this?
I would not even share my login-credentials with any other person, because it is just a software.

Do you think it is against the law to enter your bank-account password into Internet Explorer, because this will effectively share your login information with Microsoft? Because there you even cannot be sure, because it is closed source. With the Amazon AWS instance it would be open source and therefore you can be sure that you don't share your password.

So why do you think, it is more stupid to trust some open-source software running on Amazon AWS in comparison to trusting some closed-source software like Internet-Explorer or any other router software which is between you and your bank?

My first response to the concept was also suspicion. However this is not what it seems at first sight.
First consideration: it is common practice for people to give copies of their bank statements to various agencies as proof of income (this is even required in some cases to get visas). This is not really different in terms of privacy, the difference is that what we're doing represents actual proof, something that cannot be forged.

Secondly, make sure you understand exactly what is being exposed. The proxy only holds encrypted records, exactly as, say, your ISP does when they forward your internet traffic to your bank. When a buyer CHOOSES to expose ONE html page, by sharing ONE specific ssl session key, they are not exposing anything else to any other party, trusted or otherwise.

Lastly, as to it being against TOS. I investigated this a bit. I found clauses in some internet banking service conditions that suggested this is not allowed, while in others there was no suggestion that sharing the data is not allowed. The former are unrealistic and frankly nonsense, since as I already pointed it out any person sharing their bank statement in any way would be violating such a TOS agreement.