Smart Contracts and Bitcoin
“Smart contract” is a term coined by Nick Szabo around 1993. It refers to computer programs or systems used to secure, execute and enforce interactions between parties. The idea behind this is to transfer trust-critical pieces of a contract to software, to formalize the relation in code. Thus, if one can trust the program executing the contract, one does not need to trust the other party in that they will fulfill the terms.
The value and applications of this are still uncertain, but we can begin to see the great potential for transforming how we do business online. Automating complex human processes has been the cornerstone of technological progress in society. Law and contractual relations have yet to feel the vertiginous acceleration of software-driven innovation.
Enter bitcoin
Since its origin, bitcoin comes with a limited but powerful scripting language to express transfer of ownership of coins. When a transaction sends coins from A to B, there’s actually a script expressing the conditions in which B can take ownership of those coins. In the simple case, B needs to produce a cryptographic signature corresponding to a certain public key. In a general sense, a transaction output sets the rules (via a script) by which it can be spent, and a future transaction needs to produce the data input for that script to execute successfully.
Most bitcoin transactions follow a predefined type of script where the coins move from A to B. In the past months, though, we’ve seen a surge in new contracts being built using the scripting language.
Let’s see some examples of this, and the corresponding scripts.
Multisig
The first ever alternative behavior attached to bitcoins. It’s really simple to understand: instead of having a single entity own the coins, we set a group of entities (identified by their public keys) that will control the funds. Additionally, we can configure how many of those owners are needed to sign off any use of those bitcoins.
To understand the technical details, we first need to take a look at how a regular bitcoin transaction script looks (it’s called a Pay-to-PubkeyHash script):
This scripts needs two inputs: a signature, and a public key. It checks that hashing the public key results in the bitcoin address holding the funds, and that the digital signature is correct. For more details on how this gets executed see this wiki entry.
In contrast, a multisig script looks like this:
You just need to replace M, N, and the public keys for the desired values. N is the total amount of owners of the funds. M is how many signatures of those N are required to release the funds. To have this contract execute successfully, we need to provide M digital signatures corresponding to some of the N public keys in the script. That’s it! Shared control of funds expressed in 4 lines of code (more detail here). The applications of such simple script are many and very interesting!
Payment Channels
Payment channels are another simple yet powerful smart contract currently being used. It allows for a continuous flow of off-chain micropayments to be negotiated between two parties in a trustless manner. In this way, one party can provide a service (the provider) in exchange for bitcoins from the other (the consumer), in a truly pay-as-you-go mechanism. There are several similar schemes proposed that implement this high-level behavior, but this one I find most elegant:
The consumer is the one that sends funds into this contract, opening the payment channel. The code has two separate branches of execution.
One is only valid after a certain time has passed (expressed in the expiry time parameter), and requires only the consumer’s signature. This corresponds to the refund clause of the contract, and is what makes it safe for the consumer. If the provider fails to collaborate, or disappears, the consumer only needs to wait until the expiry time, and can claim the funds back. No risk.
The other branch is more often used, and is a multisig 2-of-2 contract (as explained in the previous section) between the consumer and the provider. The consumer signs transactions using this branch, updating the amount sent to the provider as the channel progresses in time. These transactions are incomplete, because they have only 1 of the 2 signatures needed, and most never reach the blockchain. By repeatedly updating this transaction and sending it to the provider, the consumer is gradually sending more funds to the provider. The provider in turn can sign any of those transactions, achieving the needed amount of signatures, which allows it to be sent to the blockchain. If that happens, the channel is closed, and the contract ends.
Payment channels have lots of potential and we’ve only begun to see the applications. Some first attempts to explore this are Streamium, BitMesh, and PayFile.
Conclusion
Smart contracts allow to automate interactions between parties using code. It should be possible to create a script typification that improves how we talk about, think of, and develop smart contracts. One can then think of composing and combining different contracts to achieve more complex high-level behaviors (e.g Payment Channels use a multisig contract internally). A simple scheme will be proposed in a future post.
As we saw, bitcoin offers a way to write code that controls money. Even though the scripting language is simple and limited, some pretty complex behaviors can be obtained. The initial examples shown above are very interesting on their own, but are just the beginning. It’s only a matter of time until we see big chunks of institutions turned into code and become obsoleted.
This is one of the biggest promises of bitcoin, and one that few people are talking about. This post is an attempt to expand the discussion to a wider audience.
Follow me on twitter to get updates on my work on Smart Contracts.
