Cryptocontracts Will Turn Contract Law Into a Programming Language(thoughtinfection.com)
thoughtinfection.com
Cryptocontracts Will Turn Contract Law Into a Programming Language
http://thoughtinfection.com/2014/02/22/we-are-becoming-programmable-society/
90 comments
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.
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.
"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).
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-...
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.
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.
"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.
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.
"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.
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…
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.
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.
But for any arbitrary contract, I agree, I don't see it at all. At least not anytime soon.
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-... 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.
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.
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.
I wanted to respond to this deleted comment:
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.
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.
Too late to edit, so I'll add this correction: replace "sum of the squares of the hypotenuse" with "square of the hypotenuse".
[deleted]
ten years from now on there will only be two kinds of laws: programming verifiable law, and others.
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/
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/
Contracts are sort of like computer programs, read and executed by people -- by the parties; by constituencies within a corporate party; and sometimes by judges and juries -- instead of by CPUs.
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.
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.
"Except that we don't see CPUs being astonishingly creative in coming up with reasons why they shouldn't have to follow a clear, unambiguous program instruction."
That's the compiler's job ;-)
That's the compiler's job ;-)
We still don't know what Intel's microcode actually does...
Re: Common Draft
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!
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!
Also: when program hits a missing case in a switch statement, throwing an exception and rebooting the program is an option. That's not true for the equivalent situation with contracting parties.
On the other hand, programming people is a much more high level language.
So high level, even managers can make complex programs in it.
So high level, even managers can make complex programs in it.
I'll put down my textbook on Scottish conveyancing law here to make an observation that this idea suffers from the same delusion that 4GLs had: they were going to be the "end of programming!" All you have to do is specify what you want and the computer will deliver 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.)
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.)
> It turns out that working out what you mean is the hard problem, both in programming and in law.
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.
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.
> 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 with your neighbor, hiring a babysitter, or forming a gourmet coffee club at work.
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?
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?
by keeping money in escrow until said conditions are met.
How does the computer know conditions have been met, and what prevents using those same mechanisms with ordinary contracts?
exactly this. If the conditions were clear and unambiguous as to whether a contract's term was satisfied or not, there would be no need for lawsuits to enforce a breach.
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.
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.
This x2.
The problem is that creating(or choosing) a "neutral third party" is much harder than converting everyone to Bitcoin users.
The problem is that creating(or choosing) a "neutral third party" is much harder than converting everyone to Bitcoin users.
Actually the advantage of bitcoin escrow is that the third party only has to get involved if the first two parties have a dispute. Otherwise they can release the funds all by themselves.
"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 ?
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 ?
[deleted]
Charles Stross anticipated this in Accelerando:
"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.
"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.
Interestingly, he is a vocal critic of Bitcoin (as a currency, at least): http://www.antipope.org/charlie/blog-static/2013/12/why-i-wa...
I don't remember that ending well...
Warning, this is a spoiler. If you want to read the book, don't read it.
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.
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.
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 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?
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?
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 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.
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.
For the foreseeable future, the cost-benefit balance weighs strongly against such a system. I believe that to be true for the following reasons:
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.
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.
I totally agree, I was just trying to picture it.
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 ....
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.
If you're interested in this stuff, Ethereum (http://www.ethereum.org/) is one of the projects you should currently be watching closely.
Ripple, the IOU-oriented crypto currency,
also has a scripting language for encoding contracts:
https://ripple.com/wiki/Contracts
There's more information on Ripple contracts here: https://ripple.com/wiki/User:Justmoon/Contracts:_Overview
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.
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 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.
We've been exploring the idea of machine-readable content licensing in Tent (https://tent.io). The idea being that you could subscribe to content feeds based on your willingness to accept certain terms of service.
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.
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.
> one content license might be that you agree in advance to delete any content published under this license within a specified number of hours.
How would you know if someone is breaking that contract? And if it's not enforceable why support it?
How would you know if someone is breaking that contract? And if it's not enforceable why support it?
Depending on the situation it might be very obvious (they republish it after the deletion request) or you might not know without examining their system directly.
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).
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).
The 2007 book Rainbows End by Vernor Vinge addresses this topic from a science fiction perspective. A major plot element is the ability of individuals to enter into "affliances": digital, automatically-escrowed contracts between individuals providing small services in networks created on-demand to produce larger-scale goods and services. en.wikipedia.org/wiki/Rainbows_End
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.
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.
I really do not understand the mechanism - maybe I missed it. But A and B enter a contract - A will pay B 1000 usd for every equity research article published (think blog post someone would pay for). How is that self enforcing? how does anyone but a human decide that was a article worth paying for and it scraped off ten random pages?
Add voting: say the donations are from 10 people, and 6-of-10 unlocks the payment. If people feel ripped off by a scraped page...
A few years ago, the SEC was mulling specifying regulations for high-frequency trading in Python[0][1]. I've wondered about the potential for specifying law in programming languages since then. Formally verified laws would be a wonderful thing.
[0] http://www.itworld.com/government/105650/languages-wall-stre... [1] http://www.itworld.com/government/105031/will-wall-street-re...
[0] http://www.itworld.com/government/105650/languages-wall-stre... [1] http://www.itworld.com/government/105031/will-wall-street-re...
>high-frequency trading in Python
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?
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?
I'm sorry for the grammatical ambiguity. The regulations themselves were to be written in Python. Nonetheless, I do think interpreted languages are used in HFT, but presumably not the kind of HFT that attempts to exploit inefficiencies between in, say, the prices of frozen concentrated orange juice futures on the Chicago Mercantile Exchange vs the price of agricultural companies on the New York Stock Exchange.
This seems like just the sort of thing big banking would've caught whiff to and become engaged in. Though I imagine it would remain under wraps...not the sort of thing well suited to be interfacing the general public. At least until perhaps some startups had gotten the ball rolling on this ball of wax. But for big multinational (secret) interactions? How better to enforce contracts? The advantages on that scale of avoiding legal entreaties and a digitized security system would be enticing.
I think there's been some work being done here with derivatives trading contracts. Derivatives can be fairly complex to begin with and are sometimes easier to understand as code (e.g. when things are defined recursively).
[deleted](2)
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.
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.
>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.
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.
Something like that may work for digital goods.
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.
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.
I've always wondered if some programming tools couldn't help out in the legal world.
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.
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.
Firstly, IAAL. Secondly, I'm working on a crypto-currency that's designed for the automatic enforcement of contracts. Thirdly, I was (am) an engineer, and always saw writing contracts as akin to coding.
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 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?
It already is. Just more, idk, COBOL than Python.
"While I imagine that larger contracts would likely be built with some sort of failsafe mechanism for arbitration, there is no need for such a thing to exist."
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.
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.
I wrote an essay on this subject a couple months ago that discusses several of these ideas: https://docs.google.com/document/d/1EkLwTlb0sCEp023pzZfd1bv9...
Ethereum.org is working to make things like this possible.
So is this what what 72 hour bender of no sleep and reading about Bitcoin and scifi get you? This is getting into ratings of a madman sort of territory.
That would be fantastic.
Odd that this article doesn't mention Ethereum.
Can you write a program that would require for you to write the program forever?
It'd be great if it were declarative, thanks.
Oh come on periods do not necessarily imply scope.
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.