Beginnings

The birth of what we now call “TLSNotary” was a rather slow and complex process. The first post on the topic of “ssl logging” is here, but it has been edited extensively, and originally had the title “P2PX. Using SSL dumps as proof of money transfer“. Reading the first few pages shows how the idea developed: use the cryptographic soundness of SSL to somehow “record” the page visited in a way that couldn’t be faked. Early ideas were fairly primitive; TLSNotary as an idea was a quantum leap – withhold the master secret key of the session from the client, so that it’s genuinely impossible for them to fake the data. This idea in its rudimentary form had security issues, but a key mathematical insight in early 2014 allowed us to remove that security issue entirely and create a viable way for one person to prove irrefutably to another that they had received a certain response over SSL without compromising their security.

The motivation for solving this technical challenge was very clear: if you want to exchange a bitcoin payment for a bank transfer, the bank transfer needs to *somehow* be independently verifiable, so that an arbitrator could resolve any dispute that arises. The arbitrator could in theory be just code, but that requires an oracle. That idea was developed further in what we called “Paysty” – using Amazon AWS instances pre-prepared so as not to be modifiable, and running the audit from that instance.

Since even in the Paysty model, you still need a human arbitrator to interpret the evidence (if the evidence is supposed to come from just *any* bank or payment service), and since the idea of creating trustless code on an AWS instance was both clever and possible but not very practical, the TLSNotary idea instead took centre stage.

Later in 2014 further technical challenges were overcome, in particular removing the necessity to make modifications to the Firefox browser (which, though it could be done safely using deterministic builds, created a lot of extra complexity), adding performance improvements, adding TLS 1.1 support and so on.

Today TLSNotary is a functional piece of software. But what can it be used for? Let’s examine 3 use cases, starting with the most obvious one that was the original intention:

  1. Alice buys bitcoins from Bob, while Charlie holds the third of a 2 of 3 multisig key. If there’s a dispute, Charlie can ask either Alice or Bob to run TLSNotary and prove that they received a certain transaction page or statement page from their bank.
  2. Alice wants to prove her identity, or perhaps her bank balance. For example: she is a member of a peer to peer lending group, and wishes to borrow. To aid her chances she enlists an auditor Charlie which performs checks on her identity and other details. This is difficult, because Alice lives in a different jurisdiction from Charlie. Alice uses TLSNotary to connect to a government website (or a bank or a utility) that proves her ID number or address or … Then Bob lends to Alice based on, amongst many other factors, the information vetted by Charlie. Of course, it might be possible to do away with Charlie entirely in this use case.
  3. A holder of funds (e.g. a Bitcoin exchange) wants to be able to prove to its users that it is not only Bitcoin-solvent but fiat-solvent. A radical way to decentralize auditing would be to give the ability for any user (or more likely some subset) the ability to view balances held at the bank directly, instead of expecting them to trust a single appointed auditor. Admittedly, this is unlikely in naive form, given the traditional expectations of privacy in business, and the inability to use Merkle tree tricks.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>