
Cryptocontracts Will Turn Contract Law Into a Programming Language - mcscom
http://thoughtinfection.com/2014/02/22/we-are-becoming-programmable-society/
======
kens
I don't want to be negative-HN-commenter, but this seems crazy to me. First,
expressing a contract in a programming language is a much harder problem than
expressing a contract in English. How would you even express babysitting or
lawnmower-borrowing as a program?

Second, lawyers go to great efforts to cover all the cases and even so there
are usually things uncovered. Programmatic contracts aren't going to be any
better at covering all the cases.

Third, if something unexpected happens (either accidentally or maliciously),
you'd be totally out of luck with a programmatic contract. You can think of
the court system as exception handling for real-world contracts, and that's a
dangerous thing to give up.

Fourth, programmatic contracts are likely to be more expensive than regular
contracts. How much would it cost to program a babysitting contract versus
telling the babysitter you'll pay $X per hour verbally? And I can't imagine
how much it would cost to write code for something complex like a lease.

I can see using Bitcoin-style programmatic contracts for things like escrow
payments, but contracts with any sort of real-world interface seem unfeasible.

Source: I'm married to a contract attorney. I've also looked at Bitcoin script
in detail, and what kind of contracts it can express.

~~~
oleganza
Very good arguments, thanks. I'll try to refute all of them.

1\. Contract in a programming language does not leave room for
misinterpretation. If there are N conditions to unlock money, they are all
well-defined (unless there's a bug in the entire system, of course). Since
there's no room for interpretation, lawyers do not need to "cover many cases"
(like they do today so their opponents don't find a loophole). Compare Bitcoin
itself (a bunch of C and C++ code) with the current financial system and all
the laws and regulations. Bitcoin's code may be shitty, but it's much more
strict, consistent and well-defined than all these thousands of pages of law.
Law is never consistent even with itself, not only with law of other countries
or particular decisions of courts.

2\. Lawnmower-borrowing can be transformed into insurance contract with a
deposit "locked in the sky". E.g. like this:
[http://blog.oleganza.com/post/58240549599/contracts-
without-...](http://blog.oleganza.com/post/58240549599/contracts-without-
trust-or-third-parties) Newer slides: [http://oleganza.com/bitcoin-
epita-2014.pdf](http://oleganza.com/bitcoin-epita-2014.pdf)

In other words, you transform an informal problem "this guys agrees to do some
ill-defined work" into a formal problem "we both lock up insurance deposit
which makes both of us interested in resolving all uncertainties to mutual
satisfaction". It does not need to work for everyone, but it's potentially a
much better insurance against misinterpretation of contracts than the need to
go to an awfully expensive court+lawyers. Some people will find it useful for
them, others will stick to some other means.

3\. You can encode exception-handling as an optional third party arbiter right
in the contract. Only bigger risk takers will start using cryptocontracts and
assume all the risks due to bugs or surprising social issues. As time goes by,
bugs will be weeded out, worst solutions thrown away and replaced by better
solutions. Your mom will use this stuff after million iterations with a low
risk of something go wrong. Also, cryptocontracts don't encode life or death.
They only encode movement of limited amount of funds. If you don't put all
your life's savings in one contract, you don't risk losing all your life
savings.

4\. Very disagree about cost. Programmatic contracts will be used voluntarily
and only because they are cheaper than going to a lawyer or risking going to a
court. Or paying a fee to some 3rd party. Also, in many cases the cost of
using orthodox legal system is infinite - for some contracts, or in some
countries, or in some businesses (extreme example - black market), legal
system is simply unavailable. There are many-many people who cannot afford
lawyers or non-corrupt judges to solve their problems. Cryptocontracts are
low-cost solution for them.

~~~
nitrogen
I wanted to respond to this deleted comment:

    
    
        gamblor956 17 minutes ago | link
    
        The problem is, and always will be, constructing the
        contract in such a way that it is comprehensive and
        comprehensible. We have yet to master that in languages
        that have existed for thousands of years; it is highly
        unlikely we'll master that within the limited framework
        of a a programming language which by its nature can't
        address unanticipated situations.
    

The fact that something hasn't happened doesn't mean that it will never
happen, nor does the age of a language imply its usefulness for any particular
purpose (and no language spoken on Earth has remained unchanged for hundreds,
let alone thousands of years).

The formal notations introduced by mathematicians allowed for an explosion of
knowledge and discovery that wasn't possible using plain language, while
_improving_ simplicity. Consider which is more understandable: _a² + b² = c²_
, or _the sum of the squares of the two sides is equal to the sum of the
squares of the hypotenuse_.

Similarly, I expect that some day, given the right innovation in language,
technology, or procedure, we could produce an equivalent leap forward in the
way we think of laws, contracts, politics, and governments.

~~~
nitrogen
Too late to edit, so I'll add this correction: replace "sum of the squares of
the hypotenuse" with "square of the hypotenuse".

------
dctoedt
Contracts are _sort of_ like computer programs, read and executed by people --
by the parties; by constituencies within a corporate party; and sometimes by
judges and juries -- instead of by CPUs.

Except that, unlike people: [EDITED FOR STYLE]

* CPUs don't come up with imaginative reasons why they supposedly needn't follow a clear, unambiguous program instruction.

* CPUs don't experience buyer's remorse and decide they like another program better.

* CPUs never have to be _persuaded_ to comply.

EDIT: Still, there's much room for improvement in the way contracts are
drafted; someday there may well be standardized, machine-parsable ways of
expressing common contract concepts, so that readers aren't forced to struggle
through the wordsmithing whims of J. Random Lawyer.

(Shameless plug: In that regard, see the _Common Draft_ project that I've been
working on, at [http://www.CommonDraft.org](http://www.CommonDraft.org). It's
an organized compendium of contract _term sheets_ and clause language, heavily
annotated _[and also very much an unfinished work-in-progress]_.) The long-
term goals are (1) eventually to automate 80% of routine contract review work
by programmatically comparing the preferred term sheets of Party A and Party B
to generate a discussion list of the parties' points of disagreement; and (2)
to provide an educational resource that will help people collaborate to do
good things together.

~~~
throwaway092834
"Except that we don't see CPUs being astonishingly creative in coming up with
reasons why they shouldn't have to follow a clear, unambiguous program
instruction."

That's the compiler's job ;-)

~~~
adestefan
We still don't know what Intel's microcode actually does...

------
pjc50
I'll put down my textbook on Scottish conveyancing law here to make an
observation that this idea suffers from the same delusion that 4GLs had: they
were going to be the "end of programming!" All you have to do is specify what
you want and the computer will deliver it!

It turns out that working out what you _mean_ is the hard problem, both in
programming and in law. You can't forsee all contingencies, just a subset;
maybe you run some test cases to clear things up. That's what case law is - a
stream of bugfixes and clarifications dealing with corner cases.

The recent bitcoin fiasco involved the question of what "transaction id"
_meant_ , and that it was not as unique as some people thought. Likewise if
you look at commercial law cases, you'll find a lot of trying to interpolate
what was meant in a particular case where something wasn't specified and
assumed differently by the parties. Or something unexpected goes wrong and
responsibility for fixing it has to be assigned.

(If you want to programmatically improve the legal system, you could for
example give the US a functioning land registration system like everywhere
else, abolishing the need for title insurance.)

~~~
rayiner
> It turns out that working out what you mean is the hard problem, both in
> programming and in law.

This is the heart of the issue, and is why we have both programmers and
lawyers. They are domain experts in working out what people really mean.
Specifying contracts in code doesn't eliminate the need for this process, and
if anything makes it more laborious, because English it turns out is a pretty
good language for what people mean.

------
rayiner
> Essentially what we are talking about is a real democratization of
> contractual agreements. Whereas today contracts are restricted to deals with
> enough value to justify a lawyers time (mortgages, business deals, land
> transfer etc…), in the future there is no limit to what could be codified
> into simple contracts. You could imagine forming a self-enforcing contract
> around something as simple as sharing a lawnmower with your neighbor, hiring
> a babysitter, or forming a gourmet coffee club at work.

Contracts are already totally democratized. A simple verbal agreement
pertaining to lawn tools is already an enforceable contract, as is a simple
English statement of terms. I don't see how making it into a programming
language doesn't make it _less_ democratic. I don't know if you had noticed,
but programmers are more expensive than lawyers now.

Of course simple contracts aren't "self enforcing" but I fail to see how
crypto anything helps here. How does that make your neighbor return your
lawnmower?

~~~
futuresense
by keeping money in escrow until said conditions are met.

~~~
rayiner
How does the computer know conditions have been met, and what prevents using
those same mechanisms with ordinary contracts?

~~~
mark212
exactly this. If the conditions were clear and unambiguous as to whether a
contract's term was satisfied or not, there would be no need for lawsuits to
enforce a breach.

It's precisely because of the enormous ambiguity in human affairs, even when
both parties are acting entirely in good faith, that hundreds of years of
contract law exists, and courts and lawyers and lawsuits and police to enforce
them.

The OP's example -- publish three blog posts -- is so trivial that it's hardly
even worth discussing as a contract. "Paint my house" is a typical example in
first year contracts and it's fodder for all kinds of problems and issues and
exceptions: was the house painted? On time? Proper color as specified in the
contract ["that's not blue!" "of course it is, says so right here on the can"
"No it's not" etc]?

Bitcoin and other crypto currencies are interesting as a cheap escrow
mechanism, but it still requires a neutral third party to verify that the
conditions are satisfied and release the funds.

~~~
DennisP
Actually the advantage of bitcoin escrow is that the third party only has to
get involved if the first two parties have a dispute. Otherwise they can
release the funds all by themselves.

------
patrickmay
Charles Stross anticipated this in Accelerando:

"Amber scans the READ ME quickly. Corporate instruments are strong magic,
according to Daddy, and this one is exotic by any standards -- a limited
company established in Yemen, contorted by the intersection between shari'a
and the global legislatosaurus. Understanding it isn't easy, even with a
personal net full of subsapient agents that have full access to whole
libraries of international trade law -- the bottleneck is comprehension. Amber
finds the documents highly puzzling. It's not the fact that half of them are
written in Arabic that bothers her -- that's what her grammar engine is for --
or even that they're full of S-expressions and semidigestible chunks of
LISP...."

Points off for capitalizing Lisp, but otherwise prescient.

~~~
tlrobinson
Interestingly, he is a vocal critic of Bitcoin (as a currency, at least):
[http://www.antipope.org/charlie/blog-static/2013/12/why-i-
wa...](http://www.antipope.org/charlie/blog-static/2013/12/why-i-want-bitcoin-
to-die-in-a.html)

~~~
wyager
His criticism is unsurprising; he's a modern luddite. He thinks the tech he
grew up with (and maybe a bit more advanced) is A-OK, but anything else is
eeevil.

------
jarrett
How does the automatic enforcement work? Specifically, how would the software
algorithmically determine whether one party has performed satisfactorily?

Determining whether one party has paid the other is relatively straightforward
--compared to other contractual obligations, at least. Whether it relies on a
centralized model like a bank, or something decentralized like BitCoin, it's
easy to quantify and measure the exchange of money.

What's harder is measuring the other side of the contract. How does the
software know that the plumber has satisfactorily installed the customer's new
shower? Or that the web developer has built a satisfactory website for the
client? Or that the mortgager has encumbered his home in violation of the
mortgage?

~~~
dcre
The babysitting one is harder than the plumbing, but bear with me.

For the plumber's contract, imagine sensors embedded in the pipes or the
bathtub that could collect data _suggesting_ that agreed-upon circumstances in
fact obtain.

Now, if the agreed-upon pattern is something simple like a certain level of
water flow, it's easy to see how a criminal plumber would be able to game that
system and get out of town with the money (though they probably wouldn't be
able to make nearly as much money as a good plumber would).

On the other hand, you can imagine a system of sensor-enabled plumbing parts
made to fit with each other — shower walls, pipes, showerheads, faucets, etc.
— then there could be a signature pattern in all the sensors that is much
harder to fake than it is to just achieve honestly. The achievement of that
pattern could then trigger the satisfaction of the contract.

Babysitting is a lot weirder, but you can imagine the contract working with
some combination of factors like:

\- the babysitter is in fact in the house, and maybe his/her movements fit
some expected pattern

\- the sounds made by the kid match the types of sounds they normally make (or
have made with other babysitters)

\- the kid is in bed by a certain time

\- the kid (depending on how old he/she is) might actually rate the quality of
the babysitter

\- etc., etc.

This is one creepy world I just envisioned.

~~~
jarrett
For the foreseeable future, the cost-benefit balance weighs strongly against
such a system. I believe that to be true for the following reasons:

1\. What you're proposing would add a tremendous layer of additional
complexity. There are design, manufacturing, and maintenance costs associated
with that functionality.

2\. Comparatively few business deals end in a dispute. So in the vast majority
of cases, the sensors would be a waste.

3\. Even if a dispute occurs, there's no guarantee the sensors will resolve
it. Either party could easily claim the sensors malfunctioned, or that the
programming of the sensors doesn't appreciate the nuances of the case. In
which case, you'd have to rely on traditional, human means of dispute
resolution.

~~~
dcre
I totally agree, I was just trying to picture it.

------
tlrobinson
If you're interested in this stuff, Ethereum
([http://www.ethereum.org/](http://www.ethereum.org/)) is one of the projects
you should currently be watching closely.

~~~
tromp
Ripple, the IOU-oriented crypto currency, also has a scripting language for
encoding contracts:
[https://ripple.com/wiki/Contracts](https://ripple.com/wiki/Contracts)

~~~
alwillis
There's more information on Ripple contracts here:
[https://ripple.com/wiki/User:Justmoon/Contracts:_Overview](https://ripple.com/wiki/User:Justmoon/Contracts:_Overview)

BTW, while the Ripple network supports the ability to establish trust lines
(also known as IOUs) between users, the cryptocurrency (XRP) is separate from
that.

In fact, XRP is the only currency on the Ripple network that does't have
counter-party risk and doesn't require a trust relationship to transact in.

------
danielsiders
We've been exploring the idea of machine-readable content licensing in Tent
([https://tent.io](https://tent.io)). The idea being that you could subscribe
to content feeds based on your willingness to accept certain terms of service.

For example, as a distributed system, there's no guarantee that your
subscribers will delete posts you sent them when asked, so one content license
might be that you agree in advance to delete any content published under this
license within a specified number of hours.

We've also looking at the idea of community arbiters: if two users want to
enter into a contract, they could choose an arbiter to help resolve any
disagreements from the intersection of their social graphs.

~~~
Flenser
> one content license might be that you agree in advance to delete any content
> published under this license within a specified number of hours.

How would you know if someone is breaking that contract? And if it's not
enforceable why support it?

~~~
danielsiders
Depending on the situation it might be very obvious (they republish it after
the deletion request) or you might not know without examining their system
directly.

There are a number of options depending on the context. If Tent ends up like
email (90% of users spread across a handful of service providers), then one
term of the license could be consent to regular audits by mutually trusted
individuals or organizations (e.g. the EFF).

------
adamfeldman
The 2007 book Rainbows End by Vernor Vinge addresses this topic from a science
fiction perspective. A major plot element is the ability of individuals to
enter into "affliances": digital, automatically-escrowed contracts between
individuals providing small services in networks created on-demand to produce
larger-scale goods and services. en.wikipedia.org/wiki/Rainbows_End

------
alwillis
The author, self admittedly being a little late to cryptocurrencies, kind of
buried the lead here: cryptocurrencies and cryptocontracts aren't twin
technologies; the ability to create and enforce contracts is built into the
Bitcoin protocol.

A lot of that functionality is currently dormant, (remember, the reference
Bitcoin-Qt client is still hasn't reached version 1.0) it's likely to get
enabled once other issues within Bitcoin are resolved.

Also, there's been a lot of thought put into these concepts already:

Mike Hearn's talk at the Bitcoin 2012 London conference
([https://www.youtube.com/watch?feature=player_embedded&v=mD4L...](https://www.youtube.com/watch?feature=player_embedded&v=mD4L7xDNCmA))
on Contracts, Smart property, etc.

Bitcoin wiki entries on Contracts
([https://en.bitcoin.it/wiki/Contracts](https://en.bitcoin.it/wiki/Contracts)),
Smart property
([https://en.bitcoin.it/wiki/Smart_Property](https://en.bitcoin.it/wiki/Smart_Property))
and Agents
([https://en.bitcoin.it/wiki/Agents](https://en.bitcoin.it/wiki/Agents))

Nick Szabo's seminal paper Formalizing and Securing Relationships on Public
Networks
([http://szabo.best.vwh.net/formalize.html](http://szabo.best.vwh.net/formalize.html))

Ripple Labs
([https://ripple.com/wiki/User:Justmoon/Contracts:_Overview](https://ripple.com/wiki/User:Justmoon/Contracts:_Overview))
is working on contracts too.

------
lifeisstillgood
I really do not understand the mechanism - maybe I missed it. But A and B
enter a contract - A will pay B 1000 usd for every equity research article
published (think blog post someone would pay for). How is that self enforcing?
how does anyone but a human decide that was a article worth paying for and it
scraped off ten random pages?

~~~
gwern
Add voting: say the donations are from 10 people, and 6-of-10 unlocks the
payment. If people feel ripped off by a scraped page...

------
heydenberk
A few years ago, the SEC was mulling specifying regulations for high-frequency
trading in Python[0][1]. I've wondered about the potential for specifying law
in programming languages since then. Formally verified laws would be a
wonderful thing.

[0] [http://www.itworld.com/government/105650/languages-wall-
stre...](http://www.itworld.com/government/105650/languages-wall-street) [1]
[http://www.itworld.com/government/105031/will-wall-street-
re...](http://www.itworld.com/government/105031/will-wall-street-require-
python)

~~~
Havoc
>high-frequency trading in Python

Wait...they're willing to spend millions to build a new undersea cable that
shaves a millisecond off the latency...but they use an interpreted language?
How does that work?

~~~
heydenberk
I'm sorry for the grammatical ambiguity. The regulations themselves were to be
written in Python. Nonetheless, I do think interpreted languages are used in
HFT, but presumably not the kind of HFT that attempts to exploit
inefficiencies between in, say, the prices of frozen concentrated orange juice
futures on the Chicago Mercantile Exchange vs the price of agricultural
companies on the New York Stock Exchange.

------
futuresense
This seems like just the sort of thing big banking would've caught whiff to
and become engaged in. Though I imagine it would remain under wraps...not the
sort of thing well suited to be interfacing the general public. At least until
perhaps some startups had gotten the ball rolling on this ball of wax. But for
big multinational (secret) interactions? How better to enforce contracts? The
advantages on that scale of avoiding legal entreaties and a digitized security
system would be enticing.

~~~
andrewfong
I think there's been some work being done here with derivatives trading
contracts. Derivatives can be fairly complex to begin with and are sometimes
easier to understand as code (e.g. when things are defined recursively).

------
scottdw2
There's an interesting split here: between contract validation, contract
enforcement.

Both have typically been handled by courts.

Contract validation is typically very "human centric". It centers on questions
such as "what is a bargain?" or "is this result acceptable to the conscience
(I.e. is morally acceptable)".

Contract enforcement, however, is much more formulaic. Given a valid contract,
and a series of events (leading to a breach), quantify what relief would look
like.

I don't think validity can be automated. It's analogous to Dijkstra's
obsession with "formal verification".

However, most contracts are valid. They typically involve genuine negotiations
on reasonable terms.

Assuming validation, enforcement is easily automated.

I don't think bit coin is relevant though. For automated contract enforcement
any payment API will work. Wether it's bit coin, or paypal in Estonian Kroon,
the important part is automation.

~~~
wyager
>I don't think bit coin is relevant though. For automated contract enforcement
any payment API will work. Wether it's bit coin, or paypal in Estonian Kroon,
the important part is automation.

Maybe you're not seeing the really important part of this; these contracts are
_cryptographically guaranteed_. Any contract managed by Paypal is subject to
human error, hacking, government interference, etc. It's not just automation;
it's deterministic, mathematical, perfect automation.

~~~
scottdw2
Something like that may work for digital goods.

You deliver some digital assets, the key to which can only be derived if a
particular crypto currency transaction is performed.

But if you are delivering physical goods, there's going to be some human
aspect to it.

Some human, somewhere, is going to deliver the good to some other human.

I'm not discounting the idea of automated contract enforcement. I think
contract enforcement is really inefficient. Finding a way to automate it seems
like it could be useful. That's the niche paypal originally filled (providing
escrow services for ebay transactions). If you could find a way to automate
such things, so that everywhere you currently see a "standard service"
contract nowadays you had someone clicking on a button (and maybe entering a
credit card number), it seems like it could be disruptive. Kind of like a
Google App engine for executing contract logic.

I'm just not sure that bit coin is central to the whole thing.

The whole "free from government interference" thing is a bit of a fallacy. If
the government wants to seize your bit coins, they will find a way. It may be
difficult for them to manipulate the price of bit coin, and to implement
wholesale theft (stealing everyone's bit coins), but seizure of a specific
individual's bit coins is definitely possible. They'll find a way.

Maybe some form of contracts, like options trading, might work. Equity funding
of startups might work too. Basically anything that's purely digital.

But I don't think that any contract involving physical goods can be rendered
mathematically perfect.

------
babs474
I've always wondered if some programming tools couldn't help out in the legal
world.

It seems to me version control and diffing tools could be very applicable. I
wonder if the concept of branching could help for very complex contract
negotiations.

Also library dependency management. Contracts often include well established
clauses that can change incrementally over time. Maybe even transitive
dependencies?

From what I've seen the legal industry kind of sucks a technology and they
tend to brute force things with hordes of junior lawyers and microsoft word.

------
tomgrek
Firstly, IAAL. Secondly, I'm working on a crypto-currency that's designed for
the automatic enforcement of contracts. Thirdly, I was (am) an engineer, and
always saw writing contracts as akin to coding.

I see no way to automatically enforce contracts without a third party
intermediary, which sort of goes against the spirit of the coin. Be that party
a crowd-sourced wisdom, an impartial oracle, or whatever. Is there another
way?

------
gnoway
It already is. Just more, idk, COBOL than Python.

------
BenderV
"While I imagine that larger contracts would likely be built with some sort of
failsafe mechanism for arbitration, there is no need for such a thing to
exist."

I don't understand why. If I were to use a large cryptocontracts, I would make
sure that an impartial third party could 'debug'/judge a bad situation.

------
eigenvalue
I wrote an essay on this subject a couple months ago that discusses several of
these ideas:
[https://docs.google.com/document/d/1EkLwTlb0sCEp023pzZfd1bv9...](https://docs.google.com/document/d/1EkLwTlb0sCEp023pzZfd1bv9OnLOqqogqV-0wN-
K_PM/edit?usp=sharing)

------
ThomPete
[http://virtual-notary.org/](http://virtual-notary.org/)

[http://hackingdistributed.com/2013/06/20/virtual-notary-
intr...](http://hackingdistributed.com/2013/06/20/virtual-notary-intro/)

------
frodopwns
Ethereum.org is working to make things like this possible.

------
dinkumthinkum
So is this what what 72 hour bender of no sleep and reading about Bitcoin and
scifi get you? This is getting into ratings of a madman sort of territory.

------
spiritplumber
That would be fantastic.

------
mcantelon
Odd that this article doesn't mention Ethereum.

------
thenerdfiles
Can you write a program that would require for you to write the program
forever?

------
thenerdfiles
It'd be great if it were declarative, thanks.

~~~
thenerdfiles
Oh come on periods do not necessarily imply scope.

