Why 2017 may be the year the industry figures out smart contracts… via Bitcoin

It has been already twenty years since prominent computer science researcher Nick Szabo published the first reference document that would serve to define what we commonly refer to nowadays as “smart contracts”. Over time, the idea has evolved far beyond what was described in “Formalizing and Securing Relationships on Public Networks”.

The introduction of the blockchain has blurred the lines of what is possible or even sensible to achieve using this new technology. Early forms of “turing-complete” platforms such as Ethereum have left many incumbents dreaming up ways to reproduce modern legal arrangements “on the blockchain” rather than devise new relationship models that leverage the strengths of distributed, public, networks.

Observers have began to notice that the performance of smart contracts involving human-read “wet code” is ultimately liable to the interpretation of legal institutions. Exposure to existing regulations introduces many of the typical costs involved with traditional legal compliance. In other words: if you need to hire a team of lawyers to draw up your smart contracts, you are probably doing it wrong.

What Bitcoin offers is a blockchain that has proven particularly apt at executing what Szabo refers to as “fiduciary code”.

Fiduciary code will often execute some of the functions traditionally thought of as the role of commercial law or security, but with software that securely and reliably spans the global regardless of traditional jurisdiction — Nick Szabo, 2014

Because the performance of its contracts relies exclusively on “dry code”, enforced on-chain, interference by third party is minimized. While the expressiveness of Bitcoin’s scripting language is justifiably limited, it is no less powerful in its implications.

I discuss below three applications that help demonstrate the potential of Bitcoin as a platform for smart financial services.


The idea behind Bitcoin wallet GreenAddress has seen several revisions since its first iteration and the scope of the 2-of-2 signature model has expanded beyond the “Instant confirmation” feature it was initially created for. Today, by providing GreenAddress with a second signature to spend your funds, you also benefit from a server-side second factor authentication factor that can enable various protections such as daily, weekly, monthly spending limits.

In effect, this is a simple but important demonstration of the new models of trust that are possible using Bitcoin. In the legacy system, such checks and balances on customer funds would only be possible if the service was handed custody of them. Under the new paradigm of the blockchain, these services can be replaced with cryptographic trust that provides equivalent security without counterparty risks.

In this particular case, GreenAddress is prevented from spending your money unilaterally unless your own signature/key gets compromised. If GreenAddress goes offline or disappears, you can recover your funds by using our pre-signed transaction that includes a time lock you have previously set-up.

What this means is that the user does not need to rely on a legal structure anymore to enforce the honesty of a counterparty, the terms of the contract are embedded in the asset itself. A failure from the service to abide by his obligations results in, at worse, inconvenience rather than a potentially disastrous loss of funds.

Property becomes secured not by reactive methods relying on legal deterrence but by pro-active enforcement using code executed by a trustless adjudicator, the Bitcoin blockchain. It’s easy to imagine how this model can be applied to other services that typically require customers to trust custodians.

For a comprehensive review of why the combination of 2-of-2 multi-signature and timelocks provided by Green Address offers the least exposure to risks of any similar service, see Coin Center’s post on custody here.


Bitcoin Transaction scripting, a form of what some call an implementation of “Smart Contracts” [19], enables systems without trusted custodial clearinghouses or escrow services. — Poon, Dryja, 2016

What the Lightning Network offers is inspired by the relationships made possible using the Bitcoin’s scripting capabilities discussed above. Ex-Bitcoin developer Mike Hearn wrote extensively about these contracting capabilities back in 2011. With his help, Blockstream co-founder Matt Corallo built the first implementation of payment channels in 2013.

The idea, also independently discovered by Blockstream’s Christian Decker, is to apply Hashed Timelock Contract (HTLC) to multi-party contracts. This extension to previously unilateral relationships enables distributed graphs of counterparties & payment channels to move obligations around and create “conditional payments”. These contracts can now hop from peer to peer until the intended recipient claims it using a cryptographic preimage produced by his counterparty.

A Fast and Scalable Payment Network with Bitcoin Duplex Micropayment Channels — Decker, Wattenhofer. 2015

The Lightning network is, in my opinion, the most ambitious smart contract project the ecosystem has produced so far. Poon & Dryja’s work has inspired a number of different teams from everywhere around the globe to contribute to its emergence. Blockstream’s own Rusty Russell & Christian Decker have been hard at work with other implementations to put together the final pieces of what should become the Lightning protocol’s first official specification.

Rusty recently published a short compendium of things to know as we wait to get our hands on the real thing. Along with lightning-c, many different implementations are expected to be released during the year and I look forward to helping bootstrap this fantastic technology.

Federated Sidechains

Liquid Federated Consensus

Federated sidechains are protocol adaptors that narrow the scope of trust between participants down from Bitcoin’s Byzantine-resistant dynamic-membership multi-party model to a deterministic set of mutually distrusting functionaries.

When Szabo imagined smart contracts in 1997 he listed along with their description three important dimensions to consider:

  1. Observability
  2. Verifiability
  3. Privity
The first objective of smart contract design is observability, the ability of the principals to observe each others’ performance of the contract, or to prove their performance to other principals. — Szabo, 1997

To achieve these objectives, federated sidechains borrow from Bitcoin’s consensus mechanism but trade pseudonymous miners for a group of signatories running auditable code.

For reactive measures to work, high verifiability is critical. — Szabo, 1997

Verification is performed by every participant. Rules set by the protocol provide a very strict mechanism to peg in and out of the main chain so that no more coins than have gone in can be taken out. Future iterations could even integrate “Proof-of-Reserve” for external audibility of funds.

Our third objective of smart contract design is privity, the principle that knowledge and control over the contents and performance of a contract should be distributed among parties only as much as is necessary for the performance of that contract. — Szabo, 1997

Privity is one of the aspects where sidechains shine most. Because users of the federation have voluntarily agreed to additional security assumptions, they receive access to extensions of the scripting language that are not yet available on-chain. One of these is Confidential Transactions developed by Blockstream co-founders Gregory Maxwell & Adam Back.

Using homomorphic values, the technology offers the verifiability of open, public, ledgers along with the privacy usually expected with financial activity. Transaction values become blinded yet the verifiable integrity of the ledger is preserved. By sharing their blinding key, users can also disclose the value of their transaction to third-party auditors at their discretion.

Sidechains are interesting because they offer a new frontier for development that can accelerate the introduction of new features not yet suited for main chain integration. Federations propose an alternative trust model that enables users to interface with the technology without having to rely on the strict requirements of Bitcoin’s consensus.

Elements Alpha is progressing rapidly as the de facto platform to extend the Bitcoin blockchain’s capabilities. Look for updates and feature announcements in the following months as well as the beta release of Blockstream’s Liquid sidechain.

Ultimately we can replicate existing custodians relationships and solve the security problems. (…) Blockchains provide the prospect of preserving privacy and a priori enforcing societal rules about transactions. — Adam Back, 2016

The development of Bitcoin’s scripting language has gained tremendous ground in the last year. Unfortunately there remains a thorn in the side of developers working on them until something is done to fix signature malleability. Changing the hash of a transaction id introduces the possibility for links of transactions used in schemes like Lightning or other multi-clause smart-contracts to be broken.

I would expect to see the segregated witness malleability fix, once active, solve this problem and position Bitcoin for further smart-contract uses such as secure vaults using covenants, and, ultimately, trustless exchanges where users funds are not at custody risk.

Smart contracts are an exciting way to increase Bitcoin’s value proposition, and 2017 is setting up to be the year Bitcoin introduces them to the world.