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