tlsnotary - cryptographic proof of fiat transfer for p2p exchanges

[nomailing]

The questions you raise wrt AML, orderbook spam and randomly chosen escrow are all valid and warrant consideration. They will however be not implemented for the proof-or-concept launch. Really what I'm concerned about at this juncture is providing free tools which existing crypto-only exchanges can plug into their infrastructure.

Yeah, I know it's only a proof-of-concept implementation. And it's a very good idea to provide this as a tool to other p2p exchanges. I just wanted to raise the issue so that some people might start thinking about solutions esspecially to the AML problem. Because, if this problem is not solved, everybody who would use the system would have high risks to be involved in criminal activities. Still, I think, it is possible to solve it in a p2p way.

wrt SSL:
a banking session consists of one SSL session. However a single SSL session contains dozens on SSL connections. Each of those connections uses a unique encryption/decryption key.
You are right in that banks don't allow renegotiation, but we don't use it anyway. Renegotiation implies starting a new SSL session, not a new SSL connection.

You can try it out yourself and ascertain that there are multiple SSL connections withing an SSL session, this way:
1. You must use Firefox and add an environment variable SSLKEYLOGFILE=/home/user/sslkeylog
(on Linux we use export SSLKEYLOGFILE=/home/user/sslkeylog and then launch Firefox from the same terminal)
2. Start Firefox and visit a https website like https://www.mozilla.org
3. Look in you sslkeylog file: it will contain dozens of CLIENT_RANDOM lines.
Each of those lines can usually decrypt only a single GET request and server's response.

Start clicking around and you will see how the entries in sslkeylog grow. For every click you make, a new SSL connection is started.

Thank you for the instructions! I will try it when I am back at home.

[1715064370]

1715064370

[1715064370]

1715064370

[1715064370]

1715064370

[1715064370]

1715064370

[Mike Hearn]

Wow cool. It's funny because I was just brainstorming this idea with Stefan in Amsterdam and we came up with the same idea of relaying the connections through a proxy. Actually I suggested two different ideas:

 - Implement a TLS extension that lets you ask the server to sign a running hash of a connection (no proxies required)

 - Proxy traffic through an intermediary that just signs hashes of the contents of each session. At the end you can grab the signed hashes and present them along with a recording to a mediator who then decrypts them and can see there was no tampering.

For the AML case, I think using NFC passports can help a lot. There's an app on the Android market that shows how smartphones can read passport data. It's all digitally signed so it should be unforgeable (unless you can convince a government to officially issue a bogus passport). I'd do the following combination:

• Request the buyer to install (a variant of) the NFC passport app and send the passport data to the seller. Seller of course has to be careful to destroy the important parts after verifying the signatures so if they get hacked, the data cannot be stolen!
• Request the buyer to do a Skype/G+ Hangouts session so you can match their face to their passport.
• Now check the wire details against the passport data.

This should prevent phishers from cashing out hacked bank accounts through you.

[dansmith]

- Proxy traffic through an intermediary that just signs hashes of the contents of each session. At the end you can grab the signed hashes and present them along with a recording to a mediator who then decrypts them and can see there was no tampering.

This is what the oracle will be doing, it first dumps all the passing traffic into a file using wireshark or a tcp forwarder, then produces a hash.

For the AML case, I think using NFC passports can help a lot...

Great idea, thanks!

How about this for an anti-phishers idea:
Seller requests the potential buyer to post a certain unique reference string on their facebook public page. The name/surname of the person who posted the message on their facebook page should match the name of the buyer of BTC.

[Mike Hearn]

That might be OK sometimes, but Facebook/Google/consumer accounts are fairly easy to hack especially if you are already capable of hacking the users online bank. The advantage of the NFC passport approach is even if an attacker has utterly owned someones laptop or desktop computer, they can't access the passport data as people typically don't have it on their computers.

The big problem of course is, they can access passport data if they hack the seller and steal whatever was stored. Some of the recent breakthroughs in crypto (SCIP/TinyRAM) can potentially help address that by allowing the buyer to send only a proof of a valid passport rather than the actual passport data itself, but failing that, making sure the default tools sellers use delete the data ASAP would be a workable approach.

[nomailing]

For the AML case, I think using NFC passports can help a lot. There's an app on the Android market that shows how smartphones can read passport data. It's all digitally signed so it should be unforgeable (unless you can convince a government to officially issue a bogus passport). I'd do the following combination:

• Request the buyer to install (a variant of) the NFC passport app and send the passport data to the seller. Seller of course has to be careful to destroy the important parts after verifying the signatures so if they get hacked, the data cannot be stolen!
• Request the buyer to do a Skype/G+ Hangouts session so you can match their face to their passport.
• Now check the wire details against the passport data.

This should prevent phishers from cashing out hacked bank accounts through you.

Unfortunately, in many countries this approach just wouldn't work, because they don't offer a compatible electronic passport.
For example, I live in Germany, and have an eID. But the German eID system does not allow everyone to validate the passport of another person. As far as I know only service providers (like banks etc.) are allowed to apply at authorities to be able to run an eID-server to allow customers to authenticate.
So it seems that our eID does not allow the authentication of citizens to other citizens. It only allows authentication of citizens to some registered service providers.

I am not sure, but isn't the eID system in other European countries compatible to the German eID and wouldn't work either? (see http://en.wikipedia.org/wiki/Electronic_identity_card)
Would be nice, if someone with a good understanding of these eIDs could clarify.

[waxwing]

A banking session usually consists of multiple SSL connection, each havng a unique decryption key. So the buyer will forward to escrow only that key which is required to decrypt that particular HTML statement. This is enough to prevent the escrow from learning the login credentials (as those credentials reside in a different SSL connection and hence require a different decryption key).

Are you sure about this point? I always thought that a banking session consists of only one single SSL connection... And I thought some banking websites do not even allow SSL-renegotiation. Did you try this out on several websites?

This point is not 100% resolved (I mean whether the login can be kept out of the exposed data); most banking sessions will involve more than one SSL session, as dansmith points out in another post. But there is no guarantee that the relevant data will be in a separate session from the login. We will make our best effort to do that when the ssl data stream makes it possible. We have also considered stripping POSTs from the exposed data, but we haven't done it and it has its own issues.

However I would make this point, having tried out this system with two banks already:
Modern internet banking almost always involved some additional security feature: usually 2FA, or at the very least, some hiding mechanism such that the entire password is not exposed even over an encrypted connection.
Thus, I have shared my unencrypted banking sessions with dansmith Now, I trust him, but even if I didn't, he does not have my passwords let alone my 2FA device! If I was more paranoid, I could also change my password..

You may say, but he has my bank account number and maybe my balances and so on. True, but with regard to account number: you're going to have to expose that to use this system, specifically to your counterparty, who you're not going to know (if you did - why would you be using this system?). Admittedly one doesn't want to share one's balance with anyone, but it is very rare in this system that anyone will see it.

The "TLDR" is, I guess: FULL dispute resolution should only be caused by fraud by your counterparty (or yourself   ), and it MAY expose personal details, but it SHOULD NOT endanger your banking security; worst case it will expose some personal information to the escrow (not to the counterparty of course).

Anyway, this system should be able to allow decentralized fiat/bitcoin exchange. But when I think about the big picture to use this for a p2p exchange I still think there are some challenges and I am wondering how you plan to tackle them:
1. Did you thought about the legal aspects as well? I am wondering if AML laws would forbid to use such a system, because you might not know the person from whom you would accept the fiat transfer. Therefore criminals could use this system to transfer money from hacked bank accounts into Bitcoin and disappear. Therefore it would involve high risks to use this system and accept these anonymous fiat transfers!

A couple of comments:
If banks just implemented digital signatures, I would forget about this ssl stuff; it would be unnecessary. Think about why they don't do it. It's because they gain no advantage from signing their statements. It means you can sue them if they make a mistake.
Now think about a world in which they did sign their statements digitally. We could do exactly the same thing as in this thread, simply send fiat to random people on the internet, based on having the BTC in a 2 of 3 escrow. There would be no possibility of fraud, as long as you trusted bank signatures.
Now think about this: if banks did this, wouldn't your legality questions still apply?
Are we really asking whether we have the right to send the money in our CURRENT (AmE: checking) accounts (which is supposed to be like cash) to other people as we choose?
Yes, I know your questions are real and neither I nor dansmith are naive about this. I'm just pointing out how ridiculous it is.
For what it's worth, I am sure that this system will implement a reasonable upper limit on transactions to avoid triggering AML. Don't even get me started about "structuring".

2. The system needs a decentralised orderbook with spam prevention

This is a long way down the road (if ever). In our initial implementation users will simply agree on a price (like they do on localbitcoins). dansmith may be working on something that involves an order book, but I'll let him speak for himself on that.

3. How do you make sure that the escrow is chosen randomly

I have a general idea about this, for the future: imagine escrows in a P2P network, with nodes incentivised by getting a proportional percentage of all network transaction fees, and (crucially) we have MORE than one escrow (i.e. buyer-escrow1-escrow2-seller). Thus the auditing function cannot be corrupted by a single agent. The beauty of it is it's incredibly simple to hook up another link in the network chain. Moreover the network could use a concensus mechanism to randomly assign who does this particular transaction, and they wouldn't be incented to muck it up if they were all getting a fixed percentage of all fees.
Just ideas. For now we have a 1 escrow model.

Maybe you could solve all three problems together if you have a very simple semi-anonymous identity system where each identity is associated with a hash of the bank-account-number? This could solve all three issues together:

I believe we had originally conceived that identity = hash(BTC address, bank account number), but thinking about it again, you are right - we should use bank account info only, as it's more costly to set up a new one (although hardly objectively costly). Not perfect, but it's something.

1. The AML problem would be mitigated, because you would only accept high volume fiat transfers from users having a history of trades.

See my comment above about large transactions.

Thereby you can be much more sure that the account really belongs to that user. In this scenario new users would initially have to build trust by trading only a small amount like 1 USD or 1 EUR and thereby validate that they are really the owners of the bank accounts. This would be similar to how some centralised exchanges validate the bank-accounts of users due to AML laws.
2. You could prevent spam because massive orders using the same bank-account could be discarded by the p2p clients.
3. The p2p system could randomly choose escrow users from the public list of user-ids.

Earlier in the thread we discussed stuff like this a bit; Sybil attack mitigation. dansmith is thinking in terms of collateral by buyer and seller; I am still concerned that it would be much better if non-bitcoin holders could buy using the system. I'm open to be convinced though.

The system would still be quite anonymous, because it stores only the hash of the bank-account-number. Therefore only your direct trading partners would see your real identity because you anyway would have to reveal your bank account details to them. But they could use this decentralized hash store to check for your trading history to make sure that you are not a scammer.

Yes, it should work like that. Clearly escrows can and would blacklist identities who were proven to be fraudulent (albeit new identities can be created).
I'll only add that I'm not a big fan of overestimating reputation. If you think carefully about the system you'll realise that what really matters is the reputation of the escrow, rather than the counterparties. The whole system is designed for you not to have to trust your counterparty at all. But that doesn't mean I dismiss these ideas you mention at all.
We're putting a lot of work into finding ways for the escrow to need as little trust as possible (see dansmith's other posts).

[waxwing]

Wow cool. It's funny because I was just brainstorming this idea with Stefan in Amsterdam and we came up with the same idea of relaying the connections through a proxy. Actually I suggested two different ideas:

 - Implement a TLS extension that lets you ask the server to sign a running hash of a connection (no proxies required)

Great to have some input from you on all this Mike.
Can I ask for some expansion on this TLS extension idea? Are you talking about the bank server? (if no proxy I'm not sure what else you would mean). Clearly we can't expect banks' cooperation, and in fact if they were prepared to cooperate they could just sign their statements and ssl logging would be unnecessary.

As for the stuff about AML and passport data .. still thinking about it. Interesting points.

[Mike Hearn]

Unfortunately, in many countries this approach just wouldn't work, because they don't offer a compatible electronic passport.

You don't have a passport? All new passports have to be e-Passports now as far as I'm aware, it's a part of a global upgrade. And those contain plain data readable by anyone.

Yes, the TLS extension means something that the banks server supports. I suspect most banks just use OpenSSL or the Microsoft equivalent out of the box. If the extension were to be active by default then banks would likely not disable it unless they had some good reason to. But yeah, I was thinking more of the use case of things like exchanges easily signing data, etc.

[nomailing]

Unfortunately, in many countries this approach just wouldn't work, because they don't offer a compatible electronic passport.

You don't have a passport? All new passports have to be e-Passports now as far as I'm aware, it's a part of a global upgrade. And those contain plain data readable by anyone.

Sorry, if I was unclear about it. Of course I have an e-Password. But the German e-Passport does not allow me/individuals/citizens to download any personal information from the passports. The only direct access that a citizen can do is to change the PIN. You can use the electronic ID at home with card readers to digitally authenticate yourself to the government/police/banks/organisations, who previously have to apply at the government to have this ability.
Therefore, I said the German eID is not compatible with what you propose, because we cannot even download our own digital ID information from our own passports. We can only use it to authenticate to specific service providers, but not to random citizens.
And I assume that many other European countries have the same data privacy concerns and therefore restrict the access in a similar way.

[Mike Hearn]

I'm 99% sure you can download data from your e-Passport. They are standardised by the ICAO. Germany isn't allowed to have some random custom thing, otherwise it wouldn't be readable by e-Passport readers in other countries. In particular I never heard of passports having PIN numbers, so I wonder if you're mixing it up with something else?

If you have an Android phone you could try using the NFC Passport app from the Play Store and see what happens. Unfortunately Nexus devices have a bug in them which means sometimes reading fails, but that's an issue with the OS that will be fixed in KitKat and not to do with the passports themselves.

[nomailing]

I'm 99% sure you can download data from your e-Passport. They are standardised by the ICAO. Germany isn't allowed to have some random custom thing, otherwise it wouldn't be readable by e-Passport readers in other countries. In particular I never heard of passports having PIN numbers, so I wonder if you're mixing it up with something else?

If you have an Android phone you could try using the NFC Passport app from the Play Store and see what happens. Unfortunately Nexus devices have a bug in them which means sometimes reading fails, but that's an issue with the OS that will be fixed in KitKat and not to do with the passports themselves.

yes, you are right, I mixed it up with the German identity card, which has a PIN. Somehow I didn't thought about the passport having a different mechanism.

[dserrano5]

Unfortunately, in many countries this approach just wouldn't work, because they don't offer a compatible electronic passport.

You don't have a passport? All new passports have to be e-Passports now as far as I'm aware, it's a part of a global upgrade.

My significant other has had a passport issued to her within the last month, and it's still like all the older spanish ones.

[Mike Hearn]

It doesn't have the little chip symbol on the front? Well that's disappointing. Wikipedia has a list of countries and their rollout statuses:

http://en.wikipedia.org/wiki/Biometric_passport

Germany is on the list as implementing the scheme since 2005, so I'm not sure how your SO managed to get a non-RFID passport. The countries that lag behind the most are places like Azerbaijan and Armenia.

Note that we're talking just about the chip here. It doesn't have to be biometric. I have an e-Passport but it's not (as far as I know) biometric.

[nomailing]

It doesn't have the little chip symbol on the front? Well that's disappointing. Wikipedia has a list of countries and their rollout statuses:

http://en.wikipedia.org/wiki/Biometric_passport

Germany is on the list as implementing the scheme since 2005, so I'm not sure how your SO managed to get a non-RFID passport. The countries that lag behind the most are places like Azerbaijan and Armenia.

Note that we're talking just about the chip here. It doesn't have to be biometric. I have an e-Passport but it's not (as far as I know) biometric.

i have some concerns about using passport data for AML:

1) I would not like to share this data with anyone, where I cannot be sure if they will delete it. So is it maybe possible to just send this data to a server running on the amazon cloud, and knowing by the hash of the virtual machine that it will delete your data after checking the validity?

2) An attacker might have got your passport data just by wirelessly reading it out from your passport from in front of your house. So would it be enough as an identification?

A side question: Wouldn't it be nice if all countries would issue passports which would allow you to digitally sign documents? Similar to the German eID, which uses cryptography to allow active authentication to service providers.

I still think the idea of linking your p2p-exchange-identity to hash(bank-account-number) would be more usable for AML. The only downside would be that everyone who knows yours bank-account-number would be able to see your trading-history.

[dserrano5]

It doesn't have the little chip symbol on the front? Well that's disappointing. Wikipedia has a list of countries and their rollout statuses:

http://en.wikipedia.org/wiki/Biometric_passport

I didn't know about that symbol. I just asked her and the symbol is there indeed. I expected the new passport to be radically different, as it happened with our ID card here.

[Mike Hearn]

No, they look exactly the same except for the symbol (and the embedded chip which you can't see). So you do indeed have one, as I suspected.

1) I would not like to share this data with anyone, where I cannot be sure if they will delete it. So is it maybe possible to just send this data to a server running on the amazon cloud, and knowing by the hash of the virtual machine that it will delete your data after checking the validity?

There are several ways to do this. Using trusted computing is one way yes. Using AWS is a neat hack to achieve that cheaply (if it works), but you could also use Intel TXT or SGX when it comes out.

Alternatively, the approach I'm more interested in, is using the new SCIP/TinyRAM stuff to generate a proof that you have a valid passport, which is not itself passport data. That proof can be quickly checked using any old hardware and can be generated without sending the data anywhere at all.

Right now the Amazon approach is probably the easiest to achieve, but I'd prefer the SCIP approach longer term.

2) An attacker might have got your passport data just by wirelessly reading it out from your passport from in front of your house. So would it be enough as an identification?

That isn't possible. Firstly, we're talking NFC here, it's not that easy. Yes I know about people who use giant parabolic aerials and such to read NFC chips from further away than you might imagine, but there are mitigations against such things in e-Passports:

1) The data is encrypted under a key that is derived from data printed inside the booklet. To read an NFC passport is actually a two step process. Firstly you scan the MRZ (the part with <<< symbols) or type in the details by hand (passport number, expiry date, issue date). Secondly you read the chip and decrypt what you find there with the key derived from the first part.

2) American passports actually have EM shielding in the outer part of the booklet so you can't read the chips even with amazing aerials when the booklet is closed.

And I guess of course most people don't carry their passport around with them all the time.

A side question: Wouldn't it be nice if all countries would issue passports which would allow you to digitally sign documents? Similar to the German eID, which uses cryptography to allow active authentication to service providers.

It would be nice. Some e-Passports actually can do that. It's intended for anti-cloning of the chip. The chip contains a private key that is used to sign challenges. I thought originally that could be used to sign another key that would then act as a time-limited extension of your passport. Unfortunately it's an optional feature and many countries don't bother implementing it, presumably for cost reasons.

Most countries don't have a real citizen PKI beyond the ICAO international one, which is unfortunate. To nobody's surprise Germany and Estonia are ahead of the rest of the world there.

Of course, nothing stops you implementing support for a country-specific PKI scheme like eID. It looks like the Bundesdruckerei has a thing called "sign me". That might be useful, but I couldn't find any technical detail about the protocols.

http://www.bundesdruckerei.de/de/node/798

I still think the idea of linking your p2p-exchange-identity to hash(bank-account-number) would be more usable for AML. The only downside would be that everyone who knows yours bank-account-number would be able to see your trading-history.

I must have missed that one. How does it help? Remember the threat you're facing is not just regulatory, but people cashing out hacked bank accounts. In that case you have to verify the identity of the person actually initiating the payment to you.

[nomailing]

No, they look exactly the same except for the symbol (and the embedded chip which you can't see). So you do indeed have one, as I suspected.

1) I would not like to share this data with anyone, where I cannot be sure if they will delete it. So is it maybe possible to just send this data to a server running on the amazon cloud, and knowing by the hash of the virtual machine that it will delete your data after checking the validity?

There are several ways to do this. Using trusted computing is one way yes. Using AWS is a neat hack to achieve that cheaply (if it works), but you could also use Intel TXT or SGX when it comes out.

Alternatively, the approach I'm more interested in, is using the new SCIP/TinyRAM stuff to generate a proof that you have a valid passport, which is not itself passport data. That proof can be quickly checked using any old hardware and can be generated without sending the data anywhere at all.

Right now the Amazon approach is probably the easiest to achieve, but I'd prefer the SCIP approach longer term.

2) An attacker might have got your passport data just by wirelessly reading it out from your passport from in front of your house. So would it be enough as an identification?

That isn't possible. Firstly, we're talking NFC here, it's not that easy. Yes I know about people who use giant parabolic aerials and such to read NFC chips from further away than you might imagine, but there are mitigations against such things in e-Passports:

1) The data is encrypted under a key that is derived from data printed inside the booklet. To read an NFC passport is actually a two step process. Firstly you scan the MRZ (the part with <<< symbols) or type in the details by hand (passport number, expiry date, issue date). Secondly you read the chip and decrypt what you find there with the key derived from the first part.

2) American passports actually have EM shielding in the outer part of the booklet so you can't read the chips even with amazing aerials when the booklet is closed.

And I guess of course most people don't carry their passport around with them all the time.

A side question: Wouldn't it be nice if all countries would issue passports which would allow you to digitally sign documents? Similar to the German eID, which uses cryptography to allow active authentication to service providers.

It would be nice. Some e-Passports actually can do that. It's intended for anti-cloning of the chip. The chip contains a private key that is used to sign challenges. I thought originally that could be used to sign another key that would then act as a time-limited extension of your passport. Unfortunately it's an optional feature and many countries don't bother implementing it, presumably for cost reasons.

Most countries don't have a real citizen PKI beyond the ICAO international one, which is unfortunate. To nobody's surprise Germany and Estonia are ahead of the rest of the world there.

Of course, nothing stops you implementing support for a country-specific PKI scheme like eID. It looks like the Bundesdruckerei has a thing called "sign me". That might be useful, but I couldn't find any technical detail about the protocols.

http://www.bundesdruckerei.de/de/node/798

Thank you for the explanations.

I still think the idea of linking your p2p-exchange-identity to hash(bank-account-number) would be more usable for AML. The only downside would be that everyone who knows yours bank-account-number would be able to see your trading-history.

I must have missed that one. How does it help? Remember the threat you're facing is not just regulatory, but people cashing out hacked bank accounts. In that case you have to verify the identity of the person actually initiating the payment to you.

The idea is the following:

1) A new user of the p2p-trading system would create his identity=[ generated_public_key, hash(bank-account-number) ]. Thereby you link your bank account to your trading idenity given by your generated private key.
2) Initially other users will give you just a minimum trust, because they cannot be 100% sure the bank-account is really yours. With this minimum trust other users will allow you to just buy 0.01 BTC for 1 EUR/USD for example, because this is just a very small amount.
...One month later...
3) The same user has now gained much more trust, because the old trading partner has not yet received any complains that the bank account was hacked. Therefore the user can now buy 0.1 BTC for 10 EUR/USD, because other p2p users can be more sure that the identity=[ generated_public_key, hash(bank-account-number) ] does not belong to some hacker who wants to cash out hacked bank accounts...
...One month later...
4) The user has gained much more trust, because his idenity is already two month old and so far none of his trading-partners received any complains.
This goes on and on until you have build a lot of trust and you can actually trade amounts like 10.000 EUR/USD

The nice part about this is that you need two access-keys to use your p2p-account: your bank login AND your generated private key for using the p2p-system.
If some criminal gains access to some bank-account he cannot immediately cash out much money. He could only cash out 1 EUR/USD. He would have to wait 1 or 2 months to really cash out a lot of money, but at that time the victim will already have regained access to his bank-account.

So you automatically gain trust just by waiting a few months. You wouldn't even need to trade for two months. Just by waiting you will upgrade your p2p-idenity to very much trust.

[waxwing]

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

[marcus_of_augustus]

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

[nomailing]

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

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.