3 ms·

That's a great question: how is new code deployed on a smart contract? If this is even possible, what prevents the holders of The DAO's account keys from deplo

by gcr 10y ago

That's a great question: how is new code deployed on a smart contract? If this is even possible, what prevents the holders of The DAO's account keys from deploying a new "Send all outstanding balance to this wizard" version of the code? If it's not possible to change the running version of a smart contract, how does the community plan to deal with these sorts of problems?

cjbprime 10y ago
By voting to change the code.
- niftich 10y ago
  Is voting an in-band activity (i.e. inside the Ethereum VM), or something out-of-band and external?
  - cjbprime 10y ago
    In-contract, in-band.
  - EdHominem 10y ago
    It could be either, depending on the way the contract was written. Out-of-band would be something like m-of-n control of a secret 'update' key where any properly signed update-to-script-X message is accepted. You'd vote by providing your segment of the key, or not. In-band would be something like the DAO but where there was a special "update self" proposal with some set of quorum and rules all enforced in-script. Both have their place. In-band is more transparent, and can have a lot of complexity modeling the intended domain. (Classes of shares with more voting power, auditors with vetoes, etc.) Out-of-band is more likely to work in cases where the script has major bugs.
EdHominem 10y ago
> how is new code deployed on a smart contract? Unless there's a provision to allow for that, it isn't possible. If there is such a provision it would likely be for the old contract to forward funds to a new contract and simply "step aside". Everyone would use the new contract but refer to it with the same name. It seems easy to screw up. To end up breaking the new contract too, or have funds still pile up at the old one that it was no-longer capable of forwarding, etc. Even if there is a provision it may not actually be useful. > If this is even possible, what prevents the holders [...] Well, nothing. (Do you have their home addresses?) That's why there often isn't a provision for it, it's a catch-all such as "or any terms that may be added at a later date." You wouldn't sign that contract, would you?

by gcr 10y ago

cjbprime 10y ago

By voting to change the code.

niftich 10y ago
Is voting an in-band activity (i.e. inside the Ethereum VM), or something out-of-band and external?
- cjbprime 10y ago
  In-contract, in-band.
- EdHominem 10y ago
  It could be either, depending on the way the contract was written. Out-of-band would be something like m-of-n control of a secret 'update' key where any properly signed update-to-script-X message is accepted. You'd vote by providing your segment of the key, or not. In-band would be something like the DAO but where there was a special "update self" proposal with some set of quorum and rules all enforced in-script. Both have their place. In-band is more transparent, and can have a lot of complexity modeling the intended domain. (Classes of shares with more voting power, auditors with vetoes, etc.) Out-of-band is more likely to work in cases where the script has major bugs.

EdHominem 10y ago

> how is new code deployed on a smart contract? Unless there's a provision to allow for that, it isn't possible. If there is such a provision it would likely be for the old contract to forward funds to a new contract and simply "step aside". Everyone would use the new contract but refer to it with the same name. It seems easy to screw up. To end up breaking the new contract too, or have funds still pile up at the old one that it was no-longer capable of forwarding, etc. Even if there is a provision it may not actually be useful. > If this is even possible, what prevents the holders [...] Well, nothing. (Do you have their home addresses?) That's why there often isn't a provision for it, it's a catch-all such as "or any terms that may be added at a later date." You wouldn't sign that contract, would you?