Disclaimer: This was written hours before the recent attack on TheDAO. The opinions in this article do not necessarily represent those held by other OpenBazaar developers.
Written by Dr Washington Sanchez
OpenBazaar receives a lot of feature requests and suggestions, which we welcome. One frequently asked question is whether we will migrate to a smart contract platform like Ethereum.
There are a number of compelling reasons to move to Ethereum:
- Ethereum has a more professional and friendly development community compared to Bitcoin Core
- Ethereum has a larger transaction capacity, and their developers have a sensible attitude to scaling
- Ethereum is a smart contract platform that can initiate the transfer of funds based on external triggers
Similarly, there are also reasons to move away from Bitcoin. The events of the ongoing block-size debate have signaled to us and other Bitcoin-related projects that the network may become prohibitively expensive in the near future.
Bitcoin Core appears to be committed to constraining the block size to drive up on-chain transaction fees and establish a ‘fee market’. Sadly, this will set Bitcoin on a course of pricing-out transactions, and ultimately people, from the blockchain (especially in the developing world).
Even though we’re excited by the scaling capacity of the lightning network, the price of admission is fundamentally determined by on-chain transaction fees. Focusing on the lightning network at the expense of on-chain scaling is like upgrading to a 12-lane highway while ignoring the 1-lane onramp.
Concerns such as these have prompted many of our colleagues to embrace Ethereum. But why haven’t we?
- Bitcoin. We believe that Bitcoin will become the dominant currency for global trade in the world. Short of a unfixable bug, or mass abandonment, we’re stubbornly devoted to Bitcoin.
- Security. Bitcoin has existed for 7 years and survived multiple assassination attempts. The security of the network and incentives are firmly established and well-tested. Moving to a new blockchain with weaker security and brand new attack vectors is unwise and premature for OpenBazaar.
- Network effects. The Bitcoin ecosystem is more mature and has maintained a defensible network effect.
These reasons are mostly focused on the currency and network aspects of Bitcoin. But what about smart contracts?
OpenBazaar uses Ian Grigg’s Ricardian contracts. In a Ricardian contract, the trading parties are represented as cryptographic identities using public key cryptography. Digital signatures are considered as a proof of agreement. The cryptographic identities of the parties, along with the semantic terms and conditions of the contract, are digitally signed and verified by both parties. Valid signatures associated with the public keys quoted in the contract validate the contract.
However, the contract itself is not self-enforcing. Nothing about the contract forces either party to abide by the terms and conditions they have agreed to. In many ways, Ricardian contracts are the cryptographic implementation of the title-transfer theory of contract, developed by Williamson Evers and Murray Rothbard.
Title Transfer Theory of Contract
The theory states that all property has a title, or an assignment of ownership. Title can be transferred freely to another individual or exchanged for other property. In the exchange, the transfer of title is conditional upon the physical delivery of the good or service.
For example, Alice and Bob write a contract to exchange 10 chickens for 1 Bitcoin. Alice can give Bob 1 Bitcoin immediately, fulfilling her end of the contract, and retains the title to Bob’s 10 chickens. If Bob delivers the chickens, the contract is considered fulfilled with both the title and underlying property transferred to their new respective owners. If Bob fails to deliver the chickens, he has defrauded Alice of her property. The chickens rightfully belongs to Alice by virtue of the title that she holds after handing over 1 Bitcoin.
Although the title-transfer theory of contract is an excellent framework we can use to resolve disputes and understand who justly deserves property, it is unenforceable. Ricardian contracts is simply a digital format to immutably record these title-transfer agreements using cryptographic identities.
Enter Nick Szabo with his proposal for “smart contracts”. Smart contracts simultaneously transfer both the title and good/service between transacting individuals. As a result, these contracts are said to be self-enforcing, in that valid contracts execute without human involvement. A simple example is a vending machine, which is programmatically designed to give you a candy bar after adding enough coins in the machine. A dumb contract, in comparison, would be equivalent to a customer handing over cash to a worker in a convenience store. The customer can try and steal the candy bar, or the worker can take the money and not hand-over the candy bar. Either case is a failure by one party to delivery property in exchange for title.
Smart contracts irrevocably link the exchange of one party’s title and property with another. This is done so well that both title and property are essentially indistinguishable. Indeed, perhaps it is a matter of technological progress that title and property are considered separate entities.
However, smart contracts can only be made for goods or services that are digitally controlled. For example, I can create a smart contract to lease a car that conditionally gives my driver’s smartphone the capacity to start the engine, provided I am making regular payments on the lease. This won’t work for my ’71 Ford Pinto.
Where a smart contract cannot be made directly for the item to be exchanged, the typical strategy employed is to find a proxy that mostly represents control of the underlying item. For example, I may have a refundable deposit that is tapped if a payment is missed.
The more the smart contract is disconnected from controlling the item being exchanged, the weaker the integrity of contract.
Smart Contracts in OpenBazaar
Aside from some types of digital goods, the exchange of physical goods and most services cannot be safely represented in a smart contract. Alice may want to sell an ordinary chair to Bob, but Alice can’t cryptographically prevent Bob from physically sitting in the chair until payment is made, nor can Bob teleport the chair to his house upon payment.
The analogue world is resistant to the true potential of smart contracts.
As a result, people have turned to regulating other aspects of trade with smart contracts, such as shipping or dispute resolution.
Transactions in OpenBazaar require both the Buyer and Vendor’s digital signature to release funds from a Bitcoin address. In the case of multisignature escrow, a third party called a ‘Moderator’ is used if there is some dispute in the execution of the contracts that the Buyer and Vendor cannot resolve. The Moderator has the tie-breaking vote to release funds to either party.
These transactions are manually initiated, as in they require the user to be online and push a button. Without a doubt this is inefficient compared to smart contracts, which can trigger the release of funds based on data retrieved from an API call. The participants in the smart contract do not need a Moderator.
In the case of ecommerce, for example, one may be tempted to write a smart contract to release funds from an address based on the shipping agent’s delivery of an item to the address requested by the Buyer. The tracking API would simple report that the item (represented by a unique tracking number) has arrived at its destination. The smart contract would read this input and release the funds to the Vendor. If the item was lost or returned to the Vendor, the smart contract could automatically refund the Buyer. If the API never reports delivery of the item to the destination address, the Buyer can be refunded after 30 days for example. No Moderator is necessary to facilitate the release of funds in these situations.
However, a closer look reveals a number of obvious problems. The Vendor could ship a box of rocks to the Buyer. The API would still report that the item was successfully delivered to the requested address, triggering the release of funds. Even if the Buyer wants to initiate a dispute, the funds are unrecoverable. Does the shipping agent need to stay and witness the unboxing of the item to verify the content’s integrity? If so, then we have essentially returned to a dumb contract, requiring a human to manually trigger the release of funds.
Alternatively, depending on the value of the item, the Buyer could purchase another smart contract to DDoS the API source for enough time to trigger a refund transaction to the Buyer… essentially tricking the smart contract into thinking that the item was never delivered.
This is by no means an authoritative or general-purpose critique of smart contracts, or even smart contracts for ecommerce. Rather, it is to say that smart contracts are fantastic at facilitating automated and human-independent interactions. Once human interaction is required and factored into consideration, smart contracts become significantly more difficult to design with enough checks and balances to incentivize good behavior. TheDAO is a cautionary tale to projects that want to capture complex human interaction in a smart contract.
To be clear once more, we’re not anti-smart contracts or even projects like TheDAO. Many of us in OpenBazaar have been in the Bitcoin community since the beginning. We’ve seen the rise and fall of companies, projects and the next ‘killer app’. We’ve seen people repeatedly lose money chasing the shiny new thing. One of our highest values is protecting the integrity of user’s funds. If that means using dumber contracts that are less efficient because they requiring manual processing, so be it.
What About Scaling?
We prefer to see on-chain scaling to the point where the volume of transactions (at ultra-low fees) is sufficient to cover the marginal costs of mining, in the absence of the block reward. This will also create a low admission price to the lightning network, making a high volume transaction network affordable and accessible to anyone in the world.
Despite the technical challenges associated with increasing the block size, the swift development of segregated witness demonstrate that innovative and complex changes can be implemented when there is sufficient will within the Bitcoin development community.
Special thanks to Brian Hoffman, Sam Patterson and Michael Folkson for their comments and corrections.