tlsnotary - cryptographic proof of fiat transfer for p2p exchanges

[Mike Hearn]

The problem of cashing out hacked bank accounts is reason enough that people have to do this. Even with no government in place at all banks own your money so they can blacklist wire destinations at any time, and they do. They don't care that it was their fault (or their customers fault), they just see repeated reports of "Someone wired my money to IBAN 1234 and it was fraudulent" and decide there's a simple fix.

[caveden]

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

Are you talking about big traders operating under such system, or the system itself?
Because saying the latter is like saying e-bay is legally responsible for, say, regulatory compliance in the selling of every electronics (or whatever) that goes through them. I know some jurisdictions are that authoritarian (Brazil comes immediately to my mind), but there must be some others where you could place your business and just be fine...

1) smart people will just not use it, because they are aware of the risks

I've used localbitcoins sometimes, and I doubt they have any AML compliance on their side. I obviously don't have on my side, I'm just an individual trading a few bucks, not a professional. So... are you calling me dumb? 

[Mike Hearn]

AML laws typically have thresholds on them so people can't get whacked just for using cash in reasonable, day to day amounts.

The thresholds fall constantly either because they don't get adjusted for inflation, or are deliberately lowered. Overall the trend is for governments to try "boiling the frog" when it comes to cash transactions (yes I know frogs don't really boil alive).

Whether you are in compliance or not is difficult to say because the laws are so hopelessly vague. In most jurisdictions it won't be an issue. If you start doing a lot of local trading and it is some significant income for you, you may or may not attract attention, and if it turns out that some SR dealers are cashing out through you and the police catch wind of that, then you might be in trouble regardless of the thresholds.

Really, it's a mess. But as I said. AML is just one aspect of that. Stopping hacked bank accounts wiring money to you is an equally important aspect that killed off a few of the early more amateurish exchanges.

[nomailing]

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

Are you talking about big traders operating under such system, or the system itself?
Because saying the latter is like saying e-bay is legally responsible for, say, regulatory compliance in the selling of every electronics (or whatever) that goes through them. I know some jurisdictions are that authoritarian (Brazil comes immediately to my mind), but there must be some others where you could place your business and just be fine...

I am talking about the big traders (>100€) and not about the p2p system itself. Of course, small traders might be lucky and not be a victim.
So, I just wanted to stress out, that these considerations are on a completely different level in comparison to considerations if p2p filesharing is legal or if bitcoin is legal. Because you are using the banking system to do money transfers from users whom you might not know. Therefore, if you want to have a usable system, then you have to deal with these issues.

1) smart people will just not use it, because they are aware of the risks

I've used localbitcoins sometimes, and I doubt they have any AML compliance on their side. I obviously don't have on my side, I'm just an individual trading a few bucks, not a professional. So... are you calling me dumb? 

No, I haven't said it is dumb to trade on localbitcoins. They have some mechanisms which prevent users to massively cash out hacked bank accounts. If you read my posts, you will see, that what I actually proposed is similar to the rating system on localbitcoins, but it would work in the p2p system.
Let me give you a counter question: Do you think, that localbitcoins would work without any rating system?
So my whole point is that the p2p system needs some mechanism to prevent hacked bank accounts wiring money. Actually, this is some minimal AML compliance, because if someone wants to cash out hacked bank accounts it is basically money laundering. This is not just important to comply with the law, but it is a fundamental part of the exchange to work.

[caveden]

I am talking about the big traders (>100€) and not about the p2p system itself. Of course, small traders might be lucky and not be a victim.

OK.

So my whole point is that the p2p system needs some mechanism to prevent hacked bank accounts wiring money.

Sure. I just wouldn't call that "AML". The idea of hashing one's IBAN for example, could be enough.

if someone wants to cash out hacked bank accounts it is basically money laundering.

No, that would be theft. Money laundering would be when/if the thief makes the stolen money a fake part of some official, declared income. That normally only needs to happen for large amounts of money, as for anything small, the thief could just spend it under the radar, without having to launder anything.

I'm being pedantic because "money laundering" is increasingly becoming a magic word, like "terrorism", used to justify all sorts of things.

[nomailing]

Sure. I just wouldn't call that "AML". The idea of hashing one's IBAN for example, could be enough.

Exactly that is what I suggested just a few posts ago (https://bitcointalk.org/index.php?topic=173220.msg3279085#msg3279085).

if someone wants to cash out hacked bank accounts it is basically money laundering.

No, that would be theft. Money laundering would be when/if the thief makes the stolen money a fake part of some official, declared income. That normally only needs to happen for large amounts of money, as for anything small, the thief could just spend it under the radar, without having to launder anything.

I'm being pedantic because "money laundering" is increasingly becoming a magic word, like "terrorism", used to justify all sorts of things.

I would definitely call this AML. As you said it is theft of fiat money, but at the same time you would be converting this into bitcoins. And if the criminal can transfer it to bitcoin, then he already has done the most difficult part of money laundering. Then he could just setup a site and anonymously donate bitcoins to himself and it is legal money.

Look at the example of bitcoin24. It was seized 4 months ago, because money was transferred from stolen bank accounts to the exchange and converted to bitcoins. This was called AML. So I do not see your point, why you wouldn't call this money laundering? Of course, AML compliance would be even more, but to prevent exchange of stolen fiat to bitcoin is a major part of AML.


*EDIT* But, probably, it's not very useful to further discuss about definitions of AML. So, I can agree to your definition of AML, if you want. It was not my intention to focus on this term. I just wanted to point out, that the p2p-exchange should use an identity=[pub_key,hash(IBAN)]. The drawback is that this will reveal all your historic trades to everyone who knows your IBAN. I thought that someone would have a better solution at hand. Actually, the idea of Mike Hearn using the passport data might be another better technical solution...

[marcus_of_augustus]

You're tying yourself up in knots trying to program for some insane regulatory hurdles that your users will most likely never encounter ... a simple cost/benefit will show you are wasting your time if AML of specific country's (of which there are hundreds)  is your driving s/ware design concerns.

E.g. leave a space where others can add-in a module or etc if they want it ... wash your hands of it and concentrate on the core. (charge them later for the extra)

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

A couple of small updates for those following the thread.
We have found a way to ensure that the login and other private information is not exposed. Experiments have verified that it's possible to send ONLY one html page when there is a dispute. I can't say that it will ALWAYS work, but I think it probably will always work - it has done so far.

If the audit is performed concurrent with the transaction, this means sending only an acknowledgement of sending page - which (for my bank at least) means just sending the receiving and sending account details and the amount (and not exposing account balances).

If the audit is performed after the transaction,as currently implemented by dansmith, (in case of dispute only), and as I know most people will prefer, this would mean exposing some kind of statement page - the details will depend on the user's bank, which he or she should verify before using the system.

dansmith is making very rapid progress with the lightweight, oracle-style code based on AMI instances that he described briefly earlier, but I'll let him give you his update on that.

As for me I have been writing a much "bigger" style of app, synchronising buyer, seller and escrow; this model will almost certainly not be used, at least initially, but it has given me plenty of opportunities to test the core architecture and I've been able to verify through hundreds of tests that the ssl logging is working as we want. I even managed to handle dropped connections, although that won't actually impact the initial version that ds is releasing.

On identities: here is my current opinion.
The whole aspect of reputation and collateral is not completely clear to me yet, but I much prefer models based on limiting amounts until a user has transactions under their belt, such as that proposed by nomailing in post 117 in this thread (although probably not as restrictive as that).

I believe that users should approach the system with two things in mind: (a)direct counterparty risk through fraud is eliminated by this system and (b)indirect counterparty risk (mainly, receipt of stolen funds) is their responsibility as a user, and we HELP them to make an informed decision by providing background information, but they should follow good practice. I.e. follow the advice to sellers given on the localbitcoins website, including identity checks but FAR more importantly, limiting transaction size with untrusted buyers.
I much prefer this to a collateral method of disincentive.

In particular I would like to preserve the property that the system would allow at least SOME kind of bitcoin buying by bitcoin non-owners (imagine that you could tell people they can just "buy some bitcoins" direct from their bank account with no security concerns; they would only be able to buy a small amount, maybe max $100, but think how powerful that is in terms of spreading the word).


Would really welcome further thoughts on this, I think it's pretty crucial.

[nomailing]

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.

A couple of small updates for those following the thread.
We have found a way to ensure that the login and other private information is not exposed. Experiments have verified that it's possible to send ONLY one html page when there is a dispute. I can't say that it will ALWAYS work, but I think it probably will always work - it has done so far.

If the audit is performed concurrent with the transaction, this means sending only an acknowledgement of sending page - which (for my bank at least) means just sending the receiving and sending account details and the amount (and not exposing account balances).

If the audit is performed after the transaction,as currently implemented by dansmith, (in case of dispute only), and as I know most people will prefer, this would mean exposing some kind of statement page - the details will depend on the user's bank, which he or she should verify before using the system.

dansmith is making very rapid progress with the lightweight, oracle-style code based on AMI instances that he described briefly earlier, but I'll let him give you his update on that.

As for me I have been writing a much "bigger" style of app, synchronising buyer, seller and escrow; this model will almost certainly not be used, at least initially, but it has given me plenty of opportunities to test the core architecture and I've been able to verify through hundreds of tests that the ssl logging is working as we want. I even managed to handle dropped connections, although that won't actually impact the initial version that ds is releasing.

Thank's for the update. how are you implementing the synchronization of buyer, seller and escrow? Hopefully it is completely decentralized in a p2p system.
Do you already have some specific system in mind?

On identities: here is my current opinion.
The whole aspect of reputation and collateral is not completely clear to me yet, but I much prefer models based on limiting amounts until a user has transactions under their belt, such as that proposed by nomailing in post 117 in this thread (although probably not as restrictive as that).

I believe that users should approach the system with two things in mind: (a)direct counterparty risk through fraud is eliminated by this system and (b)indirect counterparty risk (mainly, receipt of stolen funds) is their responsibility as a user, and we HELP them to make an informed decision by providing background information, but they should follow good practice. I.e. follow the advice to sellers given on the localbitcoins website, including identity checks but FAR more importantly, limiting transaction size with untrusted buyers.
I much prefer this to a collateral method of disincentive.

In particular I would like to preserve the property that the system would allow at least SOME kind of bitcoin buying by bitcoin non-owners (imagine that you could tell people they can just "buy some bitcoins" direct from their bank account with no security concerns; they would only be able to buy a small amount, maybe max $100, but think how powerful that is in terms of spreading the word).

+1 That all sounds great.

[waxwing]

Thank's for the update. how are you implementing the synchronization of buyer, seller and escrow? Hopefully it is completely decentralized in a p2p system.
Do you already have some specific system in mind?

I'm not sure exactly what you mean by "completely decentralized" but basically I think you need me to give an overview of the current setup. This is the setup that dansmith is planning to release for testing soon:

There are four parties involved, although one is not human.
The buyer, the seller, the "oracle" and the escrow. The oracle is set up on an Amazon aws instance in such a way that anyone can verify that it is running the correct code. That code exists to audit an internet banking session. More on that in a minute.
The buyer would need to test his internet banking (or just know) in advance to make sure that it shows clear proof of a previously sent wire transfer. If it does, he can use the system like this: choose an escrow and his/her corresponding oracle machine. Then, find a seller similar to how currently done on localbitcoins, i.e. on a website or similar public board like a bitmessage channel for example, with compatible bank account. Discuss and come to agreement on price etc. <Some of the details here need fleshing out> Then bitcoins are placed in 2 of 3 multisig with escrow by seller. When that's confirmed, buyer does internet banking without any auditing, just directly.

Lastly (the important bit, that usually will not happen), if there's a dispute from the seller after the appropriate waiting time, the escrow asks the buyer to log in to oracle machine with previously agreed credentials and run internet banking using the firefox plugin which enables (a) the internet banking to be proxied through the oracle machine and (b)some ssl stuff, in particular a button to press to clear the ssl cache so that the buyer controls which html pages will get exposed.
Finally, the buyer will send the specific ssl session key that allows the escrow to read that specific html page showing proof of his wire transfer (in particular, of course, the bank account number sent to and the amount). This will enable the escrow to resolve the dispute.

Hope that helps.

Edit: you may be wondering, as I did initially, what extra value the oracle brings if we still have to trust the escrow to interpret the html records. The point is that the oracle represents a uniquely trustable agent, so the network audit record that it stores has a privileged position. If a buyer decided that the escrow was lying in his interpretation of the html result, he could call for a second opinion from another escrow, who could also see the html (if the buyer gave him the keys). Thus outright lying by an escrow would not hold.

[nomailing]

he can use the system like this: choose an escrow and his/her corresponding oracle machine.

I am still confused how you want to make sure that the escrow is not in cahoots with the buyer. If the buyer can arbitrarily choose an escrow, as you said, then he could also just setup his own escrow service and thereby completely scam the seller. Maybe I just don't get your idea, how you want that the buyer can choose the escrow...?

I think this decentralized exchange needs two important things:
1) The escrow has to be chosen pseudo-randomly such that neither the buyer nor the seller have influence on this decision.
2) The p2p-system must prevent sybil attacks, where an attacker could flood the system with his own escrow services and use them to scam other traders.

Here are my thoughts on this problem (if it is a problem at all?), and how it might be possible to solve both points:
The idea is to use the block hashes of the bitcoin blockchain as a pseudo random stream to select an escrow.
For example:
All exchange users (buyers,sellers,escrows) have an identity=[ public_key, hash(bank-account-number) ]. If buyer and seller agree to a trade (i.e. through a bitmessage order book as you said), then this trade will be broadcasted to all users. Therefore both trading partners and their identities and the amount will be available for the public. Similar to bitcoin transactions you can compute a hash of this trade. Now based on the hash of the trade and the hash of the next bitcoin block, another user is pseudo-randomly selected. The selection might work like this:
each exchange userXY can calculate his individual score to be the escrow in the broadcasted trade:
score_userXY = hash(identity_userXY XOR hash(trade) XOR hash(next_bitcoin_block))
Everyone can claim to be the escrow service, but only the user with the lowest score will win and be the escrow for this particular trade. By this procedure, the p2p-exchange has pseudo randomly selected the escrow...

Hope my explanation somehow makes sense and could be helpful in any way...

[waxwing]

he can use the system like this: choose an escrow and his/her corresponding oracle machine.

I am still confused how you want to make sure that the escrow is not in cahoots with the buyer. If the buyer can arbitrarily choose an escrow, as you said, then he could also just setup his own escrow service and thereby completely scam the seller. Maybe I just don't get your idea, how you want that the buyer can choose the escrow...?

I think this decentralized exchange needs two important things:
1) The escrow has to be chosen pseudo-randomly such that neither the buyer nor the seller have influence on this decision.
2) The p2p-system must prevent sybil attacks, where an attacker could flood the system with his own escrow services and use them to scam other traders.

Thanks for your efforts in understanding and critiquing.

I have always thought that, indeed, it's better if the escrow is chosen at random. I think I proposed something similar among these pages. The alpha test will not include this feature.

But I think maybe you haven't understood fully the power that the oracle brings: if the seller suspects that the escrow is in cahoots with the buyer after a dispute, there is nothing stopping him from asking for independent verification: he requests an access key to the system and the ssl session key so that he can also verify by accessing the oracle, what the html page says (remember: the buyer has provided a key for ONE html page which provides proof of his transfer without exposing his login credentials).
If the escrow refuses to hand over those keys he has proved he is a fraud. If he hands over the wrong session key it will decrypt nothing - again proving fraud.
It works only because you can prove exactly what program is running on the oracle, and it cannot be tampered with, including by the escrow.

It's true though that a given escrow could commit exactly one fraud via this method, since he's in control of a 2 of 3 multisig address. Until we are able to construct an oracle which interprets all html bank statements correctly, this will always be true.

This problem *could* be mitigated by the escrow posting collateral to another multisig, such that his bitcoins are lost if he commits this transparent fraud. Then we have to be careful not to create a centralised system - with one or more "super-escrows" acting as police over other escrows. This might be too much centralisation, although I am not completely against a system like that. And if you try to distribute a LOT you might get another problem - 13 of 13 multisig is all very well, but what if 1 of the 13 dies?

So this comes back to your (and my) point that the system works much better if escrows are chosen randomly - but don't ignore the HUGE step forward that an oracle represents.

Here are my thoughts on this problem (if it is a problem at all?), and how it might be possible to solve both points:
The idea is to use the block hashes of the bitcoin blockchain as a pseudo random stream to select an escrow.
For example:
All exchange users (buyers,sellers,escrows) have an identity=[ public_key, hash(bank-account-number) ]. If buyer and seller agree to a trade (i.e. through a bitmessage order book as you said), then this trade will be broadcasted to all users. Therefore both trading partners and their identities and the amount will be available for the public. Similar to bitcoin transactions you can compute a hash of this trade. Now based on the hash of the trade and the hash of the next bitcoin block, another user is pseudo-randomly selected. The selection might work like this:
each exchange userXY can calculate his individual score to be the escrow in the broadcasted trade:
score_userXY = hash(identity_userXY XOR hash(trade) XOR hash(next_bitcoin_block))
Everyone can claim to be the escrow service, but only the user with the lowest score will win and be the escrow for this particular trade. By this procedure, the p2p-exchange has pseudo randomly selected the escrow...

Hope my explanation somehow makes sense and could be helpful in any way...

Yes, at first glance, this looks like one viable approach for random choice. I guess there would be a few ways to do it.

However I want to ask about identity: earlier in the thread you suggested it was better to make identities stick to bank accounts rather than hash(BTC add, bank account), and I realised that this was a good point, because anyone can create a BTC address any time, and so could create identities too easily.
I think this is an important issue and I'm not sure about it.

The identity has to have two properties: there should be at least some cost to creating one, but also it should be impossible to impersonate. Public bank account details satisfy the first but not the second. So maybe the best is indeed to combine a bitcoin address with a bank account but not in such a simple way as hash(BTC+BA). It could be requiring a signed message with the bitcoin address used at account creation time, as well as provision of hash of bank details. That way an attempt to create a second account with the same bank account but different bitcoin address would not be allowed, because the hash of the bank account would be a collision.

[nomailing]

The identity has to have two properties: there should be at least some cost to creating one, but also it should be impossible to impersonate. Public bank account details satisfy the first but not the second. So maybe the best is indeed to combine a bitcoin address with a bank account but not in such a simple way as hash(BTC+BA). It could be requiring a signed message with the bitcoin address used at account creation time, as well as provision of hash of bank details. That way an attempt to create a second account with the same bank account but different bitcoin address would not be allowed, because the hash of the bank account would be a collision.

yes, I completely agree. That is what I wanted to say by identity=[ public_key, hash(bank-account-number) ].
So you would associate your public_key with a hash of your bank-account-number. Of course, to submit your identity to the other peers, you would have to sign it with your corresponding private_key and thereby linking your public_key to your bank-account.

[murraypaul]

Lastly (the important bit, that usually will not happen), if there's a dispute from the seller after the appropriate waiting time, the escrow asks the buyer to log in to oracle machine with previously agreed credentials and run internet banking using the firefox plugin which enables (a) the internet banking to be proxied through the oracle machine and (b)some ssl stuff, in particular a button to press to clear the ssl cache so that the buyer controls which html pages will get exposed.
Finally, the buyer will send the specific ssl session key that allows the escrow to read that specific html page showing proof of his wire transfer (in particular, of course, the bank account number sent to and the amount). This will enable the escrow to resolve the dispute.

And any sensible buyer would say: "Hell, no, I'm not going to do that."
This has to be against the TOS of any online banking service, and would leave the buyer open to fraud with no protection from their bank, if it is found out that they have shared their session like this.

[nomailing]

And any sensible buyer would say: "Hell, no, I'm not going to do that."
This has to be against the TOS of any online banking service, and would leave the buyer open to fraud with no protection from their bank, if it is found out that they have shared their session like this.

I know that many people are sharing their bank account credentials with another company (i.e. http://de.wikipedia.org/wiki/Sofort%C3%BCberweisung). This is maybe against the TOS of the banks, but they do it anyway.
Furthermore antitrust agencies have said that these TOS are invalid, because they would exclude some companies from the market (c.f. http://www.bvdw.org/mybvdw/media/view/prozess-giropay-vs-sofortueberweisungde-bundeskartellamt-nimmt-stellung-agb-der-banken-kartellrechtswidrig?media=2775).
So in practice you see that people do share even their login credentials. And you can see that it is allowed to do that.
Now, the system described here would not even share your login-credentials. I don't think that banks could deny someone to use a proxy server. In the end every internet traffic is routed via some other servers. So how should they have some TOS to prevent that?
In the end you don't even have to share your session key with someone. It might be enough to submit it to the Amazon AWS server which will then just provide the proof-of-payment. And the Amazon AWS server is not really a person, it is just a software which is running in between and no real person has access to your keys.

[murraypaul]

Now, the system described here would not even share your login-credentials. I don't think that banks could deny someone to use a proxy server. In the end every internet traffic is routed via some other servers. So how should they have some TOS to prevent that?

You aren't just 'using a proxy', you are deliberately another person access to your supposedly secure bank connection.
This is a bad idea.
If you bank finds out that you have done it, they may well cancel your account, and would certainly refuse to compensate you for any fraud that happened on your account.

[murraypaul]

I know that many people are sharing their bank account credentials with another company (i.e. http://de.wikipedia.org/wiki/Sofort%C3%BCberweisung). This is maybe against the TOS of the banks, but they do it anyway.

I know that many people drive drunk.
This may be against the law (and really f*cking stupid), but they do it anyway.

People do stupid things all the time, and most parents teach their children that just because other people are doing stupid things, that doesn't mean they should do them too.

[nomailing]

I know that many people are sharing their bank account credentials with another company (i.e. http://de.wikipedia.org/wiki/Sofort%C3%BCberweisung). This is maybe against the TOS of the banks, but they do it anyway.

I know that many people drive drunk.
This may be against the law (and really f*cking stupid), but they do it anyway.

People do stupid things all the time, and most parents teach their children that just because other people are doing stupid things, that doesn't mean they should do them too.

I just say, that it cannot be against the law. If you connect to your banking website, then your connection is routed via many different software components. And in the end the Amazon AWS instance will also just be another software which is routing your traffic to the bank. So how should they prohibit this?
I would not even share my login-credentials with any other person, because it is just a software.

Do you think it is against the law to enter your bank-account password into Internet Explorer, because this will effectively share your login information with Microsoft? Because there you even cannot be sure, because it is closed source. With the Amazon AWS instance it would be open source and therefore you can be sure that you don't share your password.

So why do you think, it is more stupid to trust some open-source software running on Amazon AWS in comparison to trusting some closed-source software like Internet-Explorer or any other router software which is between you and your bank?

[murraypaul]

I just say, that it cannot be against the law. If you connect to your banking website, then your connection is routed via many different software components. And in the end the Amazon AWS instance will also just be another software which is routing your traffic to the bank. So how should they prohibit this?
I would not even share my login-credentials with any other person, because it is just a software.

Do you think it is against the law to enter your bank-account password into Internet Explorer, because this will effectively share your login information with Microsoft? Because there you even cannot be sure, because it is closed source. With the Amazon AWS instance it would be open source and therefore you can be sure that you don't share your password.

I've never said that sharing your credentials is against the law.
I have said that:
a) It is against your bank's TOS, and
b) It is stupid

And there is a difference between using software and, unknown to you, there being an exploit which leaks your information, and you voluntarily sharing your information.

[waxwing]

Lastly (the important bit, that usually will not happen), if there's a dispute from the seller after the appropriate waiting time, the escrow asks the buyer to log in to oracle machine with previously agreed credentials and run internet banking using the firefox plugin which enables (a) the internet banking to be proxied through the oracle machine and (b)some ssl stuff, in particular a button to press to clear the ssl cache so that the buyer controls which html pages will get exposed.
Finally, the buyer will send the specific ssl session key that allows the escrow to read that specific html page showing proof of his wire transfer (in particular, of course, the bank account number sent to and the amount). This will enable the escrow to resolve the dispute.

And any sensible buyer would say: "Hell, no, I'm not going to do that."
This has to be against the TOS of any online banking service, and would leave the buyer open to fraud with no protection from their bank, if it is found out that they have shared their session like this.

My first response to the concept was also suspicion. However this is not what it seems at first sight.
First consideration: it is common practice for people to give copies of their bank statements to various agencies as proof of income (this is even required in some cases to get visas). This is not really different in terms of privacy, the difference is that what we're doing represents actual proof, something that cannot be forged.

Secondly, make sure you understand exactly what is being exposed. The proxy only holds encrypted records, exactly as, say, your ISP does when they forward your internet traffic to your bank. When a buyer CHOOSES to expose ONE html page, by sharing ONE specific ssl session key, they are not exposing anything else to any other party, trusted or otherwise.

Lastly, as to it being against TOS. I investigated this a bit. I found clauses in some internet banking service conditions that suggested this is not allowed, while in others there was no suggestion that sharing the data is not allowed. The former are unrealistic and frankly nonsense, since as I already pointed it out any person sharing their bank statement in any way would be violating such a TOS agreement.