Cryptocontracts Will Turn Contract Law Into a Programming Language

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.

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.

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.