pull down to refresh

  1. most contracts do not have an escrow component, that is, what you owe in the future is uncertain and even when it’s certain, the thing owed doens’t exist yet and may never exist. So there is now way to automate how to handle uncertain future conditions
I think it is possible to automate uncertain future events. I've tried to present one way to do this in my loan shark tool. When you use that tool, you create a contract to borrow money first and, if someone accepts and loans you money, you pay off your loan later. But you don't know, at creation time, what utxo you will use to pay it off. To handle this uncertainty, I make it so that you sign a transaction with sighash_anyone_can_pay. This allows you to add a new utxo to the transaction in the future without invalidating your counterparty's signature.
As a result, you can contractually agree to give your counterparty a utxo that does not yet exist, and face a penalty if you do not. So there actually is a way to (partially) automate some future uncertain conditions.
2. most contracts involve real world assets, not digital ones, so can’t be fully automated
Agreed. You can create a physical contract (or a digital one, for that matter) that says something like "I agree that this house shall become Jerry's if X bitcoins end up in address Y before date Z." If that happens, you've got public proof on the blockchain, and if it doesn't happen you can prove that to. So you can bring that data to court if necessary, and that is a form of partial automation, but it's not full automation. Someone still has to go to court if there's a breach of contract (e.g. the seller refuses to leave the house).
  1. most contracts are very complicated and require verbal language (words) to express the terms (and can’t be done with simple symbolic logic; if anything contractual verbiage gets more nuanced and complicated over time, not simpler) and arbitrators/judges/courts to decide when there is a dispute
It seems to me that most "complex" contracts emerge from taking a simpler version and adding more text to it. Those simpler versions were, however, perfectly valid on their own, and many of them can be at least partially automated via bitcoin. His point seems to be that "most" contracts have evolved beyond simple versions, but I don't think that's a positive development. Return to simple contracts, and then automate them as much as possible (well...as much as is desirable anyway).