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