>>The article has full details on how to create a contract changeable by one party, then hand waving about "writing a contract that uses tokens and voting mecha

>>The article has full details on how to create a contract changeable by one party, then hand waving about "writing a contract that uses tokens and voting mechanism to allow the community to decide whether to update or not." No details on how that's supposed to work. Who's "the community", anyway? The possibilities are endless. You could have pre-chosen adjucators that can upgrade a contract on majority vote. You could use a decentralized prediction market like Augur to trigger a contract upgrade if it deems that certain events occurred, etc. Upgradability is just one component of many that will be needed to create a durable/secure smart contracting system. It's not a silver bullet. >>The Etherium promoters want this because they botched the design. Do you misspell Ethereum deliberately? I only ask because I've seen you comment multiple times about Ethereum with this misspelling, which comes across as very petty. >>The DAO debacle, and this latest demand for a "state change" because someone botched a big contract, indicate that. The latest state change request is overwhelmingly rejected by the community and will not happen. The request is only possible at all because of the temporary state of Ethereum having several hard forks planned that a state change can be snuck into. Once this phase of its life cycle is over, even requests for a state change will not happen. >>Smart contracts should have been in some declarative form like decision logic tables The point of using byte coded programs and a Turing Complete execution environment is to make features like the smart contract programming language totally configurable, rather tied to a single base implementation.