Cryptocontracts Will Turn Contract Law Into a Programming Language

http://thoughtinfection.com/2014/02/22/we-are-becoming-programmable-society/

by mcscom • 12 years ago

122 82 12 years ago

thoughtinfection.com

thenerdfiles4• 12 years ago

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

thenerdfiles4• 12 years ago

Oh come on periods do not necessarily imply scope.

spiritplumber• 12 years ago

That would be fantastic.

gnoway• 12 years ago

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

thenerdfiles4• 12 years ago

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

patrickmay• 12 years ago

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.

moomin• 12 years ago

I don't remember that ending well...

marcosdumay• 12 years ago

Warning, this is a spoiler. If you want to read the book, don't read it.

I simply can't get how the characters kept being human, even after not locked into a body anymore, and turning themselves into several different forms just for fun. In those circumstances, it could end in no other way... but it is a very bizarre set of circumstances.

Also, the lack of ambition of post-singularity beings annoys me to no end.

tlrobinson3• 12 years ago

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...

wyager2• 12 years ago

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.

ThomPete• 12 years ago

http://virtual-notary.org/

http://hackingdistributed.com/2013/06/20/virtual-notary-intr...

rayiner4• 12 years ago

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?

futuresense2• 12 years ago

by keeping money in escrow until said conditions are met.

rayiner4• 12 years ago

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

PeterisP• 12 years ago

"Keeping money in escrow" is a big no-no. There is a huge difference between paying $X at the completion of the contract versus putting $X in escrow right now to be released later; the whole point of 'paying at date Y' is that you should be able to pay with money you don't have yet but will earn on Y-1.

Cash flow is cruicial for most businesses, freezing funds in escrow for weeks or months is expensive and often impossible for many smaller businesses who have limited lines of credit.

How would you feel if you'd be asked to put in escrow all your bill payments that would be due sometime in the next month ?

futuresense2• 12 years ago

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.

andrewfong2• 12 years ago

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).

BenderV• 12 years ago

"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.

dctoedt• 12 years ago

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. 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• 12 years ago

"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• 12 years ago

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

rayiner4• 12 years ago

Also: when program hits a missing case in a switch statement, throwing an exception and rebooting the program is an option. That's not true for the equivalent situation with contracting parties.

JetSpiegel2• 12 years ago

On the other hand, programming people is a much more high level language.

So high level, even managers can make complex programs in it.

bradleyjg2• 12 years ago

Re: Common Draft

That strikes me as a very good idea. I've seen so many contracts with strange terms seemingly included because the drafting lawyer half remembered seeing such a term once, and now thinks it's necessary even though he doesn't know why.

Let's think of every synonym we possibly can for this verb including one in bad Latin and one in old Law French -- that'll show we're really serious!

lifeisstillgood• 12 years ago

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• 12 years ago

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...

mcantelon• 12 years ago

Odd that this article doesn't mention Ethereum.

tlrobinson3• 12 years ago

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

tromp• 12 years ago

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

alwillis2• 12 years ago

There's more information on Ripple contracts here: 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.

vbuterin• 12 years ago

For those interested, I (Ethereum founder) will be writing a "DAOs/self-enforcing-whatevers are not scary" series on Bitcoin Magazine and the Ethereum blog over the next little while talking about these kinds of issues in detail.

kens• 12 years ago

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.

tlrobinson3• 12 years ago

"You can think of the court system as exception handling for real-world contracts, and that's a dangerous thing to give up."

I was going to agree with you, but then I realized you can actually devise a contract with the equivalent of a "mediation" clause built-in. In fact, this is exactly what a multisig escrow Bitcoin contract is. If the buyer and seller agree that the transaction was successful they can finalize the contract, otherwise they have to go to the mediator who sides with one of the parties.

However, you still have to be very careful constructing the contract, as well as securing your private keys (from theft and loss).

thenerdfiles4• 12 years ago

The question of how is answered: — declarative syntax driven by JSON structural schemas[0] and encrypted JSON transactions stored in the blockchain.

The domain of case evidence is a matter of training a bitcoin network with a modular feed-forward neural network decision engine that discovers novel situational categories. Unit Tests consist of the declarative language and its implementation in any given environment through evaluations of syntax.

After you deploy it once, it theoretically becomes increasingly less costly to iterate deployments. Code first, design later.

—

[0] http://json-schema.org/

tel• 12 years ago

I think this is interesting debate, so without detracting from the importance of these questions here are some answers of mine:

1. I don't think this is a linguistic restriction as much as a denotation of the scope of a contract formal language. Real world actions like this could perhaps be recorded by a neutral third party (accepted via cryptographic signature with the necessary identity components baked into the script of the contract itself). I think more broadly that the scope of this formal language would be less around verification and enforcement and more around producing automated analysis of the content of a contract.

2. Continuing from point (1), this is exactly what I see the point of a contract formal language is—by becoming exhaustive about what kinds of things can be described in a contract we can check exhaustively (automatically) whether or not a contract is well-formed. You might be able to ask questions like "given I've defined these 18 eventualities, are all of them eventually observed and handled properly?". These kinds of questions are related to typing, termination[1], and totality checks, all of which are done in programming languages.

([1] Note, termination can be checked for a subset of all programs without violating the Halting Problem—you just won't have a Turing Complete contract language, which doesn't seem particularly problematic.)

3. This is definitely an interesting point—I'd imagine that large, complex, fully-automated, and self-executing cryptocontracts are much, much further off than cryptocontracts used in combination with a court. If a court is an exception system then a nice contract formal language just makes it easier to go further without depending as much upon exceptions---but they're still there for when the shit really hits the fan.

4. I think this is certainly true—for the last 40 years of building programming languages it's clear we're pretty inundated with shitty ones. But that said, for as painful as reusability is sometimes, we do get a lot of reusability. It might be unbelievably challenging to write the first lease cryptocontract, but if it was done well then the components which built it could be recycled, re-parameterized, and re-combined into other similar contracts with ease. The constraints of a contract formal language could ensure that these recombinations are sensible and other program analyses can ensure that it's, say, enforceable and complete.

I think it definitely transitions the challenges from interpretation and maintenance of contracts toward front-loaded concerns like contract composition and extensibility, but once that's done we have much firmer grasp on contract reusability. That's clearly a valuable thing given how often contracts are just mid-libbed between parties already—a contract formal language could make it easier, saner to reuse old contracts.

---

So, I'd definitely come off saying that a contract "programming language" is probably not going to look as much like a programming language that most programmers today are familiar with and more like a formal language such as mathematics or Coq where power is sacrificed for analyzability. As always with programs, the real-world interface is one of the most painful, but that's often what cryptographic technology provides---ways of translating messy real world actions into limited, binary, unforgeable digital effects (the 1-0 effect of having a cryptographic key versus the messy effect of being at fault).

From what I've seen of the Bitcoin protocol it's going to be useful for things like escrow, but is a far, far, far cry away from a meaningful place to specify more interesting contracts.

oleganza• 12 years ago

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-... Newer slides: 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.

andrewfong2• 12 years ago

You can build arbitration into contracts right now, and they're largely enforceable. Bitcoin just reduces the enforcement cost. The challenge for arbitration, programmatic or otherwise, is deciding who the arbitrator will be. One of the problems is that arbitrators have their own perverse incentive to decide things in the favor of "repeat players" rather than on a truly objective basis.

nitrogen2• 12 years ago

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.

thisiswrong3• 12 years ago

How would you even express babysitting or lawnmower-borrowing as a program?

What if all you needed to do was sent x btc to 13cyfKGfbyyuyiJVLj8S1QZ34x281X1neh which would trigger a lawnmower algorithm [1] to scan all available wifi connected lawnmowers, and send an idle one to mow your lawn - while compensating the anonymous owner for 'lending' you his machine.

The implications of distributed blockchains are so huge that it's very hard to predict how people are going to innovate on the edges. One thing is sure though - bitcoin (the invention) effectively renders centralized institutions obsolete. Banking, notaries, government, voting, legislation, data-storage...

[1] " Each Ethereum contract has its own internal scripting code, and the scripting code is activated every time a transaction is sent to it. The scripting language has access to the transaction’s value, sender and optional data fields [...] " http://cryptonomics.org/2014/02/01/ethereum-turing-complete-...

jessedhillon• 12 years ago

That idea is an automation which neither depends on Bitcoins nor entails any of the protections of a contract. How does the contract guarantee that a lawnmower was dispatched and successfully arrived, and did its job? What recourse does the client have if they don't feel that the job was well done, and how can the contract guarantee that protection? Those are contract questions.

dllthomas4• 12 years ago

You go quite a bit too far. How does one verify that the lawn mower actually is a lawn mower and not something pretending to be a lawn mower? How do I prevent someone stealing the lawn mower while it's in transit (or doing its job)? Bitcoin may offer new solutions, but it doesn't directly do anything in meat space. When there are conflicts between people we need to somehow resolve them, and a systematized way of doing that is called government.

narrator• 12 years ago

Contracts between relative equals in power in business negotiations go back and forth a lot and are creative effort. Adding a programming language on top of that is not going to help the already expensive process of drawing up a custom contract.

BTW, anyone ever try and implement P3P, which is an enormous spec meant to implement a contract in software? Everybody just threw up their hands on that one and did whatever it took to get cookie in Internet Explorer to work. I think Facebook's p3p header was "Facebook does not have a p3p policy" or something like that.

dllthomas4• 12 years ago

Maybe. Or with good tooling, maybe it will be easier than assuming you understand what the other party means by a particular wording (and what a court might take it to mean).

bradleyjg2• 12 years ago

I can see this being useful for certain financial contracts that are: a) not completely standardized b) based on a linear combination of standardized terms, and c) with all conditional terms based on objective external references (i.e. price of a dec 2016 corn contract on the Chicago Board of Trade). The advantages would be that a contract compiler could enforce certain meta-rules, and the contract itself could be entered into an automatic settlement system rather than instructions based on the contract. I'd expect even in that case the canonical form would still be the English language output rather than the source code.

But for any arbitrary contract, I agree, I don't see it at all. At least not anytime soon.

chacham15• 12 years ago

I feel like this is the equivalent argument of "the internet will never support streaming video" from so many years ago. That is not to say that I agree or disagree with the result, but rather that you are trying to fit a new technology into way too broad a category. In twenty or some odd years, we might have the capability for computers to understand "if you mow my lawn I'll pay you $20." But lets leave that aside for now. The question really is: are there problems for which this technology can work? What immediately comes to mind is automated billing. Bills can easily be automatically paid with something like bitcoin. Now, if we extend that to performance based billing, we have something similar to what the OP was talking about: the contract can verify the performance and conduct the payments accordingly. Other areas where this might apply: loans, paying your share of the rent, or auction sites. In short, it has potential. That is not to say that it will replace written contracts any time soon, but rather that I think that it has the potential to do so sometime in the future.

verbify• 12 years ago

Did someone actually say that? I know people said all sorts of things that are now considered daft about the future capabilities of the internet, I wasn't aware streaming video was one of them and a Google search yielded no results.

rhythmvs• 12 years ago

Seconded. People are talking about a complete port of all the many messy pedestrian contracts of all day life, while missing out on the more practical opportunities programmable wealth has on offer in the networked digital ecosystem.

Bounty hunts.

Say, I am an activist, a revolutionary, or simply someone who wants the competition to go out of business. I want this website down, set up a cryptocontract that implements my bounty. People can join in and assign some more wealth to the contract’s escrow. The bounty will be transferred to whomever publishes his identifying key on the domain I want to see go down. Maybe I’ll include a clause that specifies an expiry date. Or I set a clause that such and such content should be published on the target domain. And so forth. Crowdfunded hacking attacks can become very soon very cheaply accessible, and consequently disrupt some very real-life existing social contracts…

est• 12 years ago

ten years from now on there will only be two kinds of laws: programming verifiable law, and others.

heydenberk2• 12 years ago

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... [1] http://www.itworld.com/government/105031/will-wall-street-re...

Havoc• 12 years ago

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?

heydenberk2• 12 years ago

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.

jarrett2• 12 years ago

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?

dcre2• 12 years ago

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.

vertex-four• 12 years ago

Who runs these sensors? What happens when the person who runs the sensors breaks their end of the bargain?

dinkumthinkum2• 12 years ago

So that's just ridiculous. I'm calling the plumber to fix my pipes. Who do I call to fix my contract enforcement sensors for my pipes? I mean ugh ....

jarrett2• 12 years ago

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.

eigenvalue• 12 years ago

I wrote an essay on this subject a couple months ago that discusses several of these ideas: https://docs.google.com/document/d/1EkLwTlb0sCEp023pzZfd1bv9...

adamfeldman• 12 years ago

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

dinkumthinkum2• 12 years ago

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.

babs474• 12 years ago

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.

frodopwns• 12 years ago

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

pjc50• 12 years ago

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.)

rayiner4• 12 years ago

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.

danielsiders2• 12 years ago

We've been exploring the idea of machine-readable content licensing in Tent (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• 12 years ago

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?

danielsiders2• 12 years ago

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).

alwillis2• 12 years ago

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...) on Contracts, Smart property, etc.

Bitcoin wiki entries on Contracts (https://en.bitcoin.it/wiki/Contracts), Smart property (https://en.bitcoin.it/wiki/Smart_Property) and 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)

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

scottdw22• 12 years ago

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.

wyager2• 12 years ago

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.

scottdw22• 12 years ago

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.

tomgrek• 12 years ago

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?

Cryptocontracts Will Turn Contract Law Into a Programming Language

Related Stories