Quote from: marcelus on April 23, 2016, 09:12:06 AM

It's state that matters. You can't have true interoperability without it.

That also seems confused to me. Bitcoin and Bitcoin smart contracts have state-- if they didn't they wouldn't work at all. But rather than having sprawling state that requires random access to the system and hiding the true cost of providing this state, Bitcoin transactions flow state information from inputs to output.

The result is a model which is more like monads in purely functional languages: A transaction collects some state (txin selection), creates new state (new txouts), and the scriptsig/witness proves that the state transition was permitted.

Similarly to the move to thinking in terms of verification instead of computation, this insight often permits transformations that improve scalablity. E.g. instead of storing the state explicitly in outputs, in some applications you can store a hash tree over the state; then subsequent actions can simply show access and update proofs. This kind of compaction can't be used in all cases, but where it can it's very efficient. I spoke some of these advantages on the subject of code above (e.g. MAST), but they apply no less for state.

An example of elided state, a simple one without state updates, is https://blockstream.com/2015/08/24/treesignatures/ which shows the construction of fairly efficient, pretty private, accountable multisig that avoids putting all of the applicable public keys into the blockchain.

The advantages of this kind of construction will be more clear to more people as future script enhancements restore functionality in Bitcoin script that was disabled; which will bring back the ability to enforce constraints on state carried from inputs to outputs.