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.

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.

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



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

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.

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.

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.

See my comment above about large transactions.

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.

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

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.

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.

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

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.

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.


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.


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.


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

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

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.