In b-money I had envisioned that a common type of contract would be one where all the participants, including a third-party arbitrator, deposit funds into an escrow account at the start, which can only be released at the end of the contract with the unanimous agreement of all the contracting parties. So the arbitrator would make judgments on performance and damages, and be incentivized to be fair in order to protect their reputation and not lose their own deposit, and the other parties would be incentivized to accept the arbitrator’s judgments since that’s the only way (short of direct account adjustment by everyone, aka forking) to get their escrow funds out.
Not exactly the kind of “the code is the contract” smart contracts that some people are so excited about, and I have to say I don’t quite understand the excitement. Without an AI that can live on the blockchain and replace human judgments, smart contracts are restricted to applications where such judgement are not required, and there doesn’t seem to be many of these. Even when contracting for the production and delivery of digital goods, we still need human-like judgments when disputes arise regarding whether the goods delivered are the ones contracted for (except in rare cases where we can mathematically define what we want, like the prime factors of some integer).
You don’t need Ethereum-style smart contracts that can do general computation to implement escrow accounts. Multi-signature addresses, which Bitcoin already supports, are enough.
Yes. But I guess that there is a large class of interesting property protocols that can’t be implemented with bitcoins. Like the variants of ‘two-phase commit’ that are part of many step by step property transactions (‘concurrent’ in financial jargon). I wonder whether there is a non-turing complete set of primitives that suffices for more current legal transactions. Probably a lot can be learned by asking a notary with programming experience...
But I guess that there is a large class of interesting property protocols that can’t be implemented with bitcoins.
Good point, on second thought this may apply to the type of transaction I described in the opening comment, since it requires some way to transfer funds from all of the contracting parties into the escrow account at the same time, otherwise one of the parties could hold back from making the escrow deposit, and then blackmail the other parties that did make deposits (since they require his cooperation to get the money back from escrow but he has nothing to lose). I’m not sure if this simultaneous transfer of funds is possible to implement in the current version of Bitcoin.
If even such a simple case as escrow accounts can cause these kinds of bugs in ones intuition—and this probably gets much worse for people less versed in correctness proofs—then it seems sensible that people don’t do big The DAO style constructions upfront but start using a limited number of small protocols for small transactions.
In b-money I had envisioned that a common type of contract would be one where all the participants, including a third-party arbitrator, deposit funds into an escrow account at the start, which can only be released at the end of the contract with the unanimous agreement of all the contracting parties. So the arbitrator would make judgments on performance and damages, and be incentivized to be fair in order to protect their reputation and not lose their own deposit, and the other parties would be incentivized to accept the arbitrator’s judgments since that’s the only way (short of direct account adjustment by everyone, aka forking) to get their escrow funds out.
Not exactly the kind of “the code is the contract” smart contracts that some people are so excited about, and I have to say I don’t quite understand the excitement. Without an AI that can live on the blockchain and replace human judgments, smart contracts are restricted to applications where such judgement are not required, and there doesn’t seem to be many of these. Even when contracting for the production and delivery of digital goods, we still need human-like judgments when disputes arise regarding whether the goods delivered are the ones contracted for (except in rare cases where we can mathematically define what we want, like the prime factors of some integer).
With smart contracts you can implement such escrow accounts. Which is a step into the right direction I think.
You don’t need Ethereum-style smart contracts that can do general computation to implement escrow accounts. Multi-signature addresses, which Bitcoin already supports, are enough.
Yes. But I guess that there is a large class of interesting property protocols that can’t be implemented with bitcoins. Like the variants of ‘two-phase commit’ that are part of many step by step property transactions (‘concurrent’ in financial jargon). I wonder whether there is a non-turing complete set of primitives that suffices for more current legal transactions. Probably a lot can be learned by asking a notary with programming experience...
Good point, on second thought this may apply to the type of transaction I described in the opening comment, since it requires some way to transfer funds from all of the contracting parties into the escrow account at the same time, otherwise one of the parties could hold back from making the escrow deposit, and then blackmail the other parties that did make deposits (since they require his cooperation to get the money back from escrow but he has nothing to lose). I’m not sure if this simultaneous transfer of funds is possible to implement in the current version of Bitcoin.
If even such a simple case as escrow accounts can cause these kinds of bugs in ones intuition—and this probably gets much worse for people less versed in correctness proofs—then it seems sensible that people don’t do big The DAO style constructions upfront but start using a limited number of small protocols for small transactions.