Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cryptocontracts Will Turn Contract Law Into a Programming Language

thoughtinfection.com

Post reply on HN
Print view View original

71–80 of 91 posts

Re: Cryptocontracts Will Turn Contract Law Into a Programming Language

#71

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

Re: Cryptocontracts Will Turn Contract Law Into a Programming Language

#72

Post by nitrogen »

nitrogen wrote: post #55
oleganza wrote: post #41

Earlier quoted context omitted.

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

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 unantici…

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

Re: Cryptocontracts Will Turn Contract Law Into a Programming Language

#73

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

Re: Cryptocontracts Will Turn Contract Law Into a Programming Language

#74

Post by wyager »

scottdw2 wrote: post #73

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 (…

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

Re: Cryptocontracts Will Turn Contract Law Into a Programming Language

#75

Post by dinkumthinkum »

dcre wrote: post #68
jarrett wrote: post #31

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 ex…

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…

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

Re: Cryptocontracts Will Turn Contract Law Into a Programming Language

#76

Post by woah »

vertex-four wrote: post #69
dcre wrote: post #68

Earlier quoted context omitted.

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…

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

Acme plumbing gets sued in the real courts and possibly faces criminal charges. Meanwhile, plumbing transactions continue to be carried out.

Re: Cryptocontracts Will Turn Contract Law Into a Programming Language

#77

Post by chacham15 »

kens wrote: post #29

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 be…

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.

Re: Cryptocontracts Will Turn Contract Law Into a Programming Language

#78

Post by est »

kens wrote: post #29

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 be…

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

Re: Cryptocontracts Will Turn Contract Law Into a Programming Language

#79

Post by vbuterin »

tlrobinson wrote: post #26

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

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.

Re: Cryptocontracts Will Turn Contract Law Into a Programming Language

#80

Post by PeterisP »

futuresense wrote: post #13
rayiner wrote: post #10

> 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 wit…

by keeping money in escrow until said conditions are met.

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

Post reply on HN