5 ms·

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 expre

by kens 13y 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.

tlrobinson 13y 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).
thenerdfiles 13y 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/ http://json-schema.org/
tel 13y 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 13y 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-trust-or-third-parties http://blog.oleganza.com/post/58240549599/contracts-without-... Newer slides: http://oleganza.com/bitcoin-epita-2014.pdf 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.
thisiswrong 13y 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-programmable-money/ http://cryptonomics.org/2014/02/01/ethereum-turing-complete-...
- jessedhillon 13y 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.
- dllthomas 13y 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.
  - thisiswrong 13y ago
    > 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.
narrator 13y 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.
- dllthomas 13y 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).
bradleyjg 13y 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 13y 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 13y 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 13y 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 13y ago
ten years from now on there will only be two kinds of laws: programming verifiable law, and others.

by kens 13y ago

tlrobinson 13y 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).

thenerdfiles 13y 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/ http://json-schema.org/

tel 13y 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 13y 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-trust-or-third-parties http://blog.oleganza.com/post/58240549599/contracts-without-... Newer slides: http://oleganza.com/bitcoin-epita-2014.pdf 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.

thisiswrong 13y 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-programmable-money/ http://cryptonomics.org/2014/02/01/ethereum-turing-complete-...

jessedhillon 13y 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.
dllthomas 13y 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.
- thisiswrong 13y ago
  > 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.

narrator 13y 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.

dllthomas 13y 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).

bradleyjg 13y 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 13y 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 13y 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 13y 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 13y ago

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