Topic: tlsnotary - cryptographic proof of fiat transfer for p2p exchanges - page 11. (Read 42851 times)

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

I think this is an important idea and you should continue working on it.

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.

Provided the data from the bank has the right characteristics, why couldn't an oracle be used as the escrow "agent"?

Interesting.

+1

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!

Colored coin is a great idea, but I don't think anything like an emitter is very P2P. To be strongly resistant to crackdown, the bank transfer must be carried out between buyers and sellers, rather than sellers and a service provider.

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.

Colored coins (CC) facilitate decentralized real-time exchange. This is mainly aimed at full-time traders.
For casual purchases the SSL dump scheme seems better fitted.


You can use CC to represent property, like 1 USD. There must be an emitter of . The emitter accepts USD and issues CC in return. With CC, full time traders don't need to make a money wire into the exchange and risk the exchange being shut down and all their USDs frozen. Full time traders can now trade BTC for CC (on the blockchain) in a high-frequency trading fashion. Later the trader can take his CC back to the emitter and redeem the USD.
Needless to say, the emitter charges a small fee for the service of issuing CC.

As far as the rest of your post, I concur with everything.
Now, let me process your "Another thought"...

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.

Can colored coins address this fiat transfer problem in any way? My rudimentary understanding is that it's a way of using coins to represent property. I can't see how it would help with the problem being discussed in this thread?


OK, that's another model. I can see why it might be preferable. Not sure, but it's not a critical issue either way.

Yes, but to me that's the essential ingenuity of the P2P aspect; as the network grows it becomes more and more impossible for the bank to find anything to attack (no CPOF etc etc). I don't see a negative here, only a positive.

Quite, incentive is key. The software can help us provide the appropriate incentive.
EDIT: to answer your point more fully, your "gateway user" could be anyone on the network, and your "escrow agent" could be a special class of user (that little bit of quasi-centralization might be safer if thus abstracted from the direct bank connection).

This doesn't look like a problem realistically.
If the gateway user (in your terminology) is not chosen by each counterparty in the transaction, but by the P2P software, there is no realistic chance of collusion. (Any escrow model is of course broken if the escrow is colluding with one side of the transaction.)

I'm feeling more and more positive about the feasibility of this, *except* that from a technical standpoint it's really pretty complex.

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.

Are you still working on this dansmith?

It's taken me a while, but I'm getting a clearer picture of this now, slowly. First, I'd like to know why you think the proxy model (option #2 in the previous post) is vulnerable to banks shutting them down? The escrow agent could be chosen at random from a group of P2P clients. Surely the bank has no way of knowing anything about it. Just as they would accept my connection from another state or country.

And in that version (#2) how exactly would a user spoof the bank's side of the connection? I get that they have the master key to encrypt data, but if the escrow is sending requests to the bank IP, surely the response has to come from there too?

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

This!

The bank only signs the symmetric key, not the content. What stops the user impersonating the bank's server after the fact?

@Xenland, yes I was addressing you.

You are worrying that escrow basically is listening in on your banking session.
What are the worst outcomes from that. Grading from worst to less severe.

1. The escrow (or an attacker who compromised the escrow) makes a fraudulent bank transfer from your bank account while the SSL session is active. This probably also means that the attacker will not disclose the SSL key to the plugin after you're finished banking (The attacker doesn't want your plugin to examine your SSL logs an alert you that the wrong amount of money was sent). Your plugin will treat the fact that the attacker didn't send you the SSL keys immediately as a red alert.
Solution: as soon as your plugin alerts you. Pick up your phone and call the bank and cancel the transfer, call the police. The escrow loses business and reputation. You get your money bank.

2. The escrow (or attacker) knows your log-in and password.
Solution: this is the last kink that I need to work out in my model using some smart crypto technique. There is no reason why escrow should know that in the first place. It is hard to rip this bit out of the SSL sessions trafic.

3. The escrow (or attacker) sees your name, bank statements, transaction history.
Yes, you can't hide your name.
Solution: when doing the escrow-controlled SSL session , don't go around clicking all your page. Go straight to the payments section and make a payment and log out.

I guess this covers all threats from allowing an escrow to control the SSL session.
I'm hoping to soon find solution to number 2.

okay so what about "approval" the other party will review the SSL dumps and make sure the tx has been made? its hard to process HTML let alone make sure the balance went through that takes some brain power with out a specific outputs.

It is hard, indeed. We need to create per-bank tools/parsers which simply parse the HTTP request. It's not that hard actually, we don't need to parse the HTML. Because when user enters the sum and clicks send, his browser sends a simple HTTP POST request and bank responds with OK or Error (I'd hope that's the case, this needs checking on a per-bank basis).

If your talking to me I'm slightly sarcastic as I'm just worried about the escrow "controlling the clickes" if they have the ssl keys. but im assuming they send the keys "after" the tx has been made.... okay so what about "approval" the other party will review the SSL dumps and make sure the tx has been made? its hard to process HTML let alone make sure the balance went through that takes some brain power with out a specific outputs.