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.
"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).
> 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-...
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.
> When there are conflicts between people we need to somehow resolve them, and a systematized way of doing that is called government.
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 made no claim that everything we can call government is a good idea. Just saying that the notion that you have bitcoin so now you don't need government is missing at least a few steps (if any similar claim holds at all). We might be able to implement some parts of government atop technology (we already do, really), but that doesn't mean there's no government.
"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.
> The median position of a bunch of half-informed individuals plied with advertising is not something I have a lot of confidence in.
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.
Misinformation and undereducation makes things worse, to be sure, but that's not really what I was speaking of. My point was that becoming fully informed about anything is a lot of work. Becoming fully informed about everything is impossible.
"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.
The lawn mower has a private key that is uses to sign messages with. There are several solutions to the problem of verifying whether or not it's a lawn mower.
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.
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.
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.
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…
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.