@greBit


I realize that I am actually proposing two solutions:
#1. Escrow controls the SSL key
#2. User controls the SSL key, but all user's communication with the bank goes through escrow's proxy.

#2 is easy for bank to shutdown. The bank will simply block the escrow proxy's IP address. Hence I concentrate on #1 as a more resilient solution. So, to answer your question in #1 context:

Every packet that the user sends/receives to/from the bank is first submitted to the escrow for decryption/encryption with SSL key.
After the SSL session is completed, escrow releases the SSL key to the user. This is needed so that the user can check out his bank session and confirm that escrow wasn't spoofing any packets.

You see, there is no room in this set up for the user to impersonate the bank. The SSL masterkey is unique to the SSL session. Even though the user knows the SSL key after the fact, he can do nothing with it apart from decrypting his own logs.  He cannot use this masterkey for a future SSL session, because there will be a new SSL key for every new session.

Does it explain it?

P.S. I guess I should stop calling it SSL master key - it conveys a feeling as if it was a super-key used for every connection. In the SSL RFC it is called "master secret"

Not development-wise. I simply put out the idea. After I discovered that "colored coins" will get us faster to a decentralized exchange, as opposed to SSL dumps which is a temporary crutch, I am totally immersed with colored coins.

waxwing, I applaud your grasping the technicalities of this matter so quickly.
I know it is hard to wrap one's mind around initially.


(First let me define the terms. The person who will be selected from a P2P group should not be called "escrow agent", but rather should be called "the gateway user". The gateway user works on behalf of the escrow agent. The gateway user will submit SSL logs to the escrow agent when the banking session is finished.)

Yes, if it is randomly chosen from a p2p group, then it will fly.
The caveat is that eventually the same member of the p2p group will be chosen multiple times. The bank may flag such a member as a potential participant in a p2p exchange.
Another caveat is that altruistic bitcoiners will not subscribe to be added to a pool of potential proxies unless they have an incentive. The incentive will be that those who add themselves to the pool are themselves participants in a p2p exchange. But again, there may not be a significant amount of participants and so the participants will be proxying bank sessions many times a day which will get them flagged by the bank.

Correct me if I misunderstood what you are asking.

with #2 spoofing of the bank-side traffic by the payer is impossible indeed. The escrow receives the traffic from the bank.
With your p2p pool idea though, if the payer and the gateway user are in cahoots, then the user can give the gateway user the encryption key. Then the gateway user can spoof the SSL dumps as if they were coming from the bank and submit those spoofed dumps to the escrow agent.

Feel free to ask for further clarification.

Another thought:
since the only "attack vector" is the BTC seller fraudulently denying receipt of the USD into his bank account (and his account number was specified on user creation, or in any case in advance of the tx), we don't have to enable the SSL "snooping" procedure by default.
The BTC buyer/USD seller never needs to be involved in this, which is good because the process of actually *sending* a wire is particularly sensitive.

What we could do is to only initiate this process when there is a dispute that needs to be arbitrated, and only apply it to the BTC seller:
If BTC seller denies receipt of funds, escrow agent (who currently has the BTC locked in a 2 of 3 scheme) requests initiation of bank account verification process. This involves using the browser plugin as you described, and *after* login, the SSL session is "snooped"/dumped. The key would be that you would demand the BTC seller to display his *statement* for the period in question, and by doing so you would be able verify whether or not he received the contracted amount from the BTC buyer during the specified date/time period.
If the statement clearly shows that the amount WAS received, then you have one embarrassed liar of a BTC seller. Escrow releases BTC to buyer and BTC seller is possibly banned or black-marked; they could rejoin the network under a different BTC address, but they'd need a new bank account for what that's worth.

It's a technically difficult process but the key point is that it only needs to happen when there's a dispute. And if it works, it would remove a lot of the incentive for anyone to try to con the system, so it would be even less likely to occur.

What you proposed simplifies the scheme by orders of magnitude but defeats the initial idea of near-real-time trading.

The weak point is that the buyer will simply waste the sellers time by putting in an order and then refusing to send funds because the BTC market price shifted unfavourably to the buyer. This was already observed on bitcoin.de which is a p2p exchange. This has the effect of discouraging the seller to participate on such exchanges.

By using the SSL scheme, as soon as the buyer presses the "Buy BTC" button, the browser plugin immediately transfers the funds and informs the seller that money's been sent. Such an exchange would attract way more sellers than bitcoin.de's model.

I should first say thanks for the detailed responses, it's been very useful for me.
OK, that's clear - I was never looking for a real time fiat-BTC system, but only a way of transferring fiat into BTC that wasn't vulnerable to an attack on a central point of failure. I realise that a lot of people are focusing on the real time aspect.

That's a very interesting point you raise.

First, the terms of the contract should be clear to the user at the moment of accepting it, i.e. the price they promise to pay.
I don't think a small delay (in my non-real time system) is either here or there. There will be some indicative time requirement per user depending on their circumstances. If they delay too long, the other side will pull out and they might lose some reputation.

But if we imagine a high-volatility scenario where Bitcoin price is collapsing, I can see that this model is going to be ineffective. The buyers of BTC will just pull out whenever they don't think the price looks good any more (over a period of hours). That's inevitable in a non-real time system. The same is of course true with localbitcoins - if there is huge price volatility there will be a lot of time wasting going on with people backing out of deals. But backing out is a second order problem, the system can still function in terms of not being amenable to fraud.

(I'm sure colored-coins, smart property type ideas can be a solution to the real time problem by having an intermediate step without exchange rate risk. I'm sure you and others are looking into that )

It just sounds a bit technically infeasible to me. I often wire money, and quite aside from the difficult of parsing my bank's data automatically, you'll have to deal with all kinds of edge cases like, you press "send wire" and it sends back a kind of warning page saying it's after banking hours or something, and then you press another button and... I understand we can build parsers for each bank individually, but I can't see it working like that. On the other hand, using the SSL session dump for *auditing* seems very workable, even if that is still pretty hard!

Interesting.

I think the data from the bank can always be faked, however for SSL connection, they will somehow be signed by the bank, and thus can be potentially used as proof of transfer.

@waxwing
Yes, the real-time scheme involves maintaining parsers for each bank taking into account corner cases.
Your auditing scheme is way easier to implement, because no parsers are needed. The escrow agent can examine SSL logs manually in rare cases of dispute.

As was pointed out earlier in the thread, the bank only signs at the beginning, after that the bank and the user share the master secret that's used for encryption of the data during the session. This means that the user can imitate the bank, but if the proxy stands between them, that's not a problem.

If the bank actually did cryptographically sign its outputs and send that in a decrypted form on request (e.g. a bank statement), we wouldn't need any of these shenanigans, but .. they don't.