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.

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

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

Certain governments seem to making, not resolving conflicts between people. And they purposefully make these said conflicts in order to generate profit for tiny segments of the population. Iraq, Afghanistan, Libya, Syria, Ukraine, Venezuela, [...Iran?].

I get your initial point, but the past century has shown that democracy needs to be direct and NOT delegated. Algorithms and distributed blockchains could very well facilitate the dawn of a more decentralized and democratic world.

"I get your initial point, but the past century has shown that democracy needs to be direct and NOT delegated."

I'm not at all sure that direct democracy makes things better. Just look at the history of referenda in CA.

More generally, there is the tremendous problem that as an individual, I don't have the time to fully research every issue. The median position of a bunch of half-informed individuals plied with advertising is not something I have a lot of confidence in.

All of that said, I'm not convinced direct democracy is actually worse either - it does address the agency problems with representative democracy, which can be significant. Possibly some variant of liquid democracy could prove to be the best system.

And here lies the problem. In the US the 1% actively disinforms the 99% through media manipulation and bad education. Thus you can't have direct democracy when people can't think for themselves. The whole system is rotten.

In most European countries citizens are educated from a young age how to think rationally and how to interpret information. You still have subtle media manipulation like sky-news but nothing as blatant as fox-news&hollywood. Switzerland has a very good history of referenda - because the population isn't intentionally misinformed and under-educated.

"You still have subtle media manipulation like sky-news but nothing as blatant as fox-news&hollywood."

That's just silly. There's plenty of drivel in the UK. The Daily Mail easily gives Fox a run for its money, and The Sun is owned by the same guy who owns Fox News. My understanding is that the situation in other countries is roughly similar - some good journalism and a lot of crap - but I am less familiar. Switzerland's history of referenda is indeed comparatively good; I think there's a lot of factors that have contributed to its success.

Finally, even if you think the above factors are the only reason direct democracy works (or would work) beautifully in Europe and horribly in the US, what would you propose to fix them? I contend that "direct democracy" is not much of a remedy.

One solution is to use a reputation system, you see others have borrowed that lawn mower and have given it a good rating, or the owner has a good rating.

Another solution is by certificate authority that guarantees that it at one point was a lawn mower. Of course someone might try to rebuild the lawnmower into a fake one by removing the engine and feeding it fake gps coordinates etc. Maybe this problem can be solved also, but it will be much more difficult, that's why I think reputation will be the main way at first, just like in ebay or alibaba.

Obviously you can not prevent someone from stealing the lawn mower, just like you can not prevent a drunk driver from crashing into Amazon's data centers. In this case however, the lawn mower will not report that it has completed its task and the renter will not pay, so the owner of the lawn mower takes all the cost.

In general such a cryptocontract would work like this: First money is put in escrow, then the lawn mower goes to its destination, mowes the lawn and then returns to its owner. The code for the lawn mower could be verified and maybe signed by a third party so it can be more trusted. When the lawn mower has returned to its owner, the money will be released from escrow.

If there is any kind of dispute, yeah sure, you might need dispute mediators. For example the lawn mower didn't do the job well enough, because of a software bug. Even cases like this could eventually be in the contracts though, so the contract might have a clause that says the owner is not responsible for poor lawn mowing caused by software bugs, and you have to decide if you are okay with that or not.

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…

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.

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

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.

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.

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

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/

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.

That's the compiler's job ;-)

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!

So high level, even managers can make complex programs in 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.)

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.

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?

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.

The problem is that creating(or choosing) a "neutral third party" is much harder than converting everyone to Bitcoin users.

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 ?

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

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.

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?

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.

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.

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.

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.

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

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

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.

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

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?

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.

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.

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.

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.

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?

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.

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