EDIT: 3 September 2014
THe software now is near feature-complete, but in order to test its compatibility with the large number of banks out there, we need testers! Please, if you want to help freeing Bitcoin from the harassment of the banks, come and talk to us.

E-mail: tlsnotarygroup-at-gmail.com

Freenode IRC: #tlsnotary-chat

Code: https://github.com/tlsnotary/tlsnotary


EDIT: 29 July 2014
The goal of tlsnotary is to allow the buyer of BTC to prove to a 3rd party arbitrator that a money transfer to the seller has been made.
While logged into their bank account, the buyer requests a TLS-secured (HTTPS) statement page and presents it as proof to the arbitrator.
We use a scheme which leverages the TLS crypto in order to prevent the buyer from forging the proof. The novelty of this scheme is that it doesn't MITM the auditee's connection.

We have released software which implements the goal of this project. Now we are looking for people to test the software.
The final idea on which the ultimate release is based started with this post:
https://bitcointalk.org/index.php?topic=173220.msg4998488#msg4998488
Then it was enhanced by oakpacific in this post:
https://bitcointalk.org/index.php?topic=173220.msg6160307#msg6160307
The announcement of a software release was made here:
https://bitcointalk.org/index.php?topic=173220.msg7143321#msg7143321

P.S. For real-time support, find us on #tlsnotary-chat on irc.freenode.net

----------------------------------------------------------------
THE INFORMATION BELOW IS OUTDATED. I LEFT IT HERE ONLY FOR HISTORICAL PURPOSES. WE HAVE TRIED VARIOUS SCHEMES UNTIL WE ARRIVED AT THE ONE WHICH DOES WORK.
----------------------------------------------------------------


EDIT2: 14 June 2013
There are many ways of going about implementing SSL logging, but I particularly like the one proposed in post#61
https://bitcointalk.org/index.php?topic=173220.msg2304618#msg2304618
Feel free to jump to #61 as the rest of the discussion basically springs from there.


EDIT:
Ever since starting this thread I realised that proxying SSL through escrow means that the bank can ban escrow's IP. While rather unlikely, I have come up with a more resilient method (post #10 in this thread) where all traffic goes through the user's IP while the escrow controls the SSL key.

https://bitcointalk.org/index.php?topic=173220.msg2266868#msg2266868


Goal: a payer needs to prove that he made a money transfer into the account of the seller (of BTC). This proof is only needed to be presented to an escrow agent in case a dispute arises. This proof aka SSL dump should not disclose payer's online bank login credentials.

Here is the workflow:

1. The user starts up his Firefox with an open-source plugin provided by the escrow agent
2. The user initiates an SSL connection to his online banking site
3. The user enters his username/password and logges in
4. After that all further traffic between user<<-->>bank gets redirected by the plugin through the escrow agent's proxy
5. The proxy collects all encrypted communication dumps.
6. The Firefox plugin knows the symmetric key which was used for SSL communication and which is needed to decrypt the dumps.
7. In case a dispute arises, the payer can provide the symetric key to the escrow agents.

8. The escrow agent decrypts the SSL dumps and verifies that the user has indeed initiated the funds transfer.

Cool?
Can I please get some criticism/peer reviews on this model.
Because I'm burning now to start coding right away!

Could work with the P2PCrypt system scince SSL (and assuming HTTPs) probably won't work out of the box.

I'm getting the p2pcrypt.com website back up should be up soon (transferring servers)

Many p2p exchange ideas are popping up on this forum. I did research on them yesterday. You'll find my conclusion in most of those topics.

Hi Dansmith,

Some brainstorming here:

Thanks for taking up my "hijacking-attempt" positively. Sorry for not reading your project details better before.

Is your project related to bitcoins? I can imagine it is if it is used to buy bitcoins. That could indeed also be exchange-related.

So what I'm now trying to figure out is if your project would be suitable as a plugin for bitcoinx. The issue with p2p exchanges is that you CAN safely exchange bitcoins, but not other entities such as dollars (as you need a third party: a bank, or be georgraphically close to the counterparty). a bank is ok but it is open to fraud, as the bank is not part of your protocol.

- You provide a solution to this by having an escrow.
- The way bitcoinx works is that it uses "colored" satoshi as a proxy for dollars.

Both solutions have an advantage and a disadvantage.

Your solution:
adv: You get the real dollars on your bank account and are not dependant on some entity that will in the end provide dollars for your colored satoshi.
disadv: It's not entirely decentralized. If all banks collapse, p2p bitcoin exchange would not work anymore.

Bitcoinx:
adv: it's more p2p.
disadv: In the end it comes down to that you need trust that you can change your colored satoshi for dollars.(or other fiat)

... and the synthesis is ........:
Bitcoinx should use your service. In case someone wants to sell his bitcoins for dollars, but does not have a bank account, your escrow service would buy colored satoshi at an issuer that at least the receiving party trusts and send them to the receiver. as far as I know the colored satoshi vs. dollar rate of a single service should be constant (the negation of which also might be possible but gives me headaches when I'm trying to think about it. defaults etc. let's not think about this right now.)

It might be possible to couple (as in un-decouple) your escrow service and the colored satoshi issuer.

Maybe I'm running to fast, but I do see the value of your project as a potential addon for bitcoinx.

How do we prove trust in these SSL dumps? how do we know both the server and the client aren’t lying?

Actually the initial model (in my 1st post) stands. What I just proposed is an alternative model.
So, to answer your question:

Because all traffic user<--->bank goes through escrow's proxy, we can rest assured that these dumps are legit.

If the user fakes a request to the bank, say he immitates entering a sum of money and pressing send. In this case, the bank will respond "request denied" or "invalid request" and the proxy will log it. This way the user can't cheat.

But the bank can cheat indeed, no doubt about that. That's why the escrow will only accept transfers through reputable banks.
On a side note: imagine The Bank of America colluding with a bitcoin p2p exchange trader to scam users out of their bitcoins? Hey, why not If they do, it only requires the bank to cheat once to be blacklisted.

Normal behaviour:

1) Buyer and seller agree a contract
2) Seller puts Bitcoin into escrow
3) Buyer pays seller and proves to the escrow people that this occurred with the SSL logs
4) Seller releases Bitcoin to buyer

Bad behaviour which would prevent real-time trading:

1) Buyer and seller agree a contract
2) Seller puts Bitcoin into escrow
3) Buyer sees that the price of Bitcoin has crashed and decides not to go through with the deal.
4) Seller is pissed off and loses trust in the marketplace.


That was my point, the level of commitment with your proposal is biased. The seller commits, the buyer does not - as there is no escrow for his fiat.

The whole point of colored coins is that it makes both parties commit to the deal. Neither can back out. Which means the system can be trusted and deals can be performed in near real-time (still need to wait for confirmations)

Sorry, maybe I'm omitting crucial details from my description which make my point harder to digest.

The firefox plugin is linked to the p2p exchange's account of the buyer. As soon as the buyer presses "Buy", it's all automatic from then on and he can't bail out.

The seller knows in advance that the Buyer has the plugin and the Seller refuses to accept orders from any Buyer who is not using the plugin.

You are not being sarcastic, right? Sorry, if I misunderstood.

Yes you are right, after the user is finished, he submits his SSL keys to escrow, so that escrow could ascertain that a transaction has been made.
The escrow can set up a server which automatically decrypts SSL logs, parses them and signals to the seller of BTC that all is well. Thus enabling real-time trade.

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