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

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.

Oh nice, so the trust comes from your "favourite" escrow. gotcha! So now you just need an app/browser that will send the SSL keys to the escrow after the client is done, atleast im guessing anyways there are so many alt proposals on here its too much to read'em all

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.

Let me reinforce what I said earlier in another thread - yes colored coins are the way to go and they have their niche.

It seems to me you are not taking into account that:


It takes literally seconds from the moment the Buyer clicked "I agree to buy" to the moment when his browser plugin logged into his bank account and sent the money and forwarded SSL logs and escrow released BTC.

Unless, the market crashes in the time window of 5 seconds from clicking "Buy", there is no danger.

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)

Here's a cross post from another thread, we can continue discussion here:


NB: Please understand that my involvement in this thread is not because I'm sceptical about colored coins. By no means. The more ways to enable p2p, the better. I just saw this comment and wanted to respond.

This is how SSL dumps enable real-time trading (with a caveat). Both the buyer the and seller agree to transact a real-time trade. The buyer automatically logs into his website (or his OFX API terminal) and performs the money transfer. The escrows server analyzes SSL dumps in real time and signals to the seller that money's been sent. The seller releases BTC.
The only caveat is that the buyer can revoke the transfer by contacting his bank. But the revocation is not hassle-free (I'd hope) and the buyer's real name and bank credentials are known to the escrow. So why would he revoke the payment.

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.

Thank you for initiating public scrutiny:

SSL uses symmetric encryption, meaning both the server and the user knows the masterkey.
In order to protect dumps from being tampered by the user, we need to not disclose the masterkey to him.

This is achieved in this fashion:
1. The user starts his Firefox plugin indicating he is ready to login onto the banking website
2. The plugin tells the escrows server that it needs the masterkey
3. The escrow server generates the master key. Encrypts it with the bank's public key. And sends it to the plugin, which forwards it to the bank.
4. All the following traffic from/to the bank, the plugin first redirects to/from the escrow's server, who decrypts/encrypts the traffic and gives it back to the plugin.

This way the user does his banking while not knowing the master key.
The only downside is that the escrow can examine the dumps and see user's login/pasword.
I'm working on some smart crypto now to mitigate that.

P.S.
Yes, this is different from what I proposed in the first post, I should probably fix it.
Because in the first post I suggested that the plugin keep the symmetric key.
(I since learned that it is not safe)

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

I couldn't have boiled it down better than you did.

A robust p2p exchange should have multiple ways of payment:
- colored coins
- my SSL dumps method
- safety deposits with an escrow
- pure p2p without escrow using BIP38, where either both parties lose or both parties win
- you name it.

It is up to the parties to negotiate their payment method of choice.
A p2p exchange should have a pluggable architecture with API to connect various payment options.

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.

@alberthendriks

Great to see you joining forces! By all means go ahead and create a cool open-source turn-key p2p platform that can be deployed with one click.

I need to make one thing clear though.

What I'm proposing here is just a method of enabling more robust p2p exchanges with minimal escrow involvement.
This model/plugin that uses SSL dumps will be open-source and can be used on any p2p exchange.

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.

I'm not sure I understand what you mean by that. Please explain.

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)

interesting idea!

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://bitcointalksearch.org/topic/m.4998488
Then it was enhanced by oakpacific in this post:
https://bitcointalksearch.org/topic/m.6160307
The announcement of a software release was made here:
https://bitcointalksearch.org/topic/m.7143321

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://bitcointalksearch.org/topic/m.2304618
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://bitcointalksearch.org/topic/m.2266868


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!