4 ms·

Are you saying the running code is not open, or even available? How does that work in a decentralized system?

niftich 10y ago
No, I'm saying the running code is older. The repo has been updated since, so there are updates/fixes/pull requests in the repo that haven't been deployed to the running code yet. The most recent bugs that appear to have been fixed are still present in the running instance of the DAO. (Prompted by your post, I have since edited my previous post to clarify the intended wording.)
- xorcist 10y ago
  How do you deploy new code in a decentralized system? Could such a possibility not be used to change smart contracts post-facto?
  - 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?

No, I'm saying the running code is older. The repo has been updated since, so there are updates/fixes/pull requests in the repo that haven't been deployed to the running code yet. The most recent bugs that appear to have been fixed are still present in the running instance of the DAO. (Prompted by your post, I have since edited my previous post to clarify the intended wording.)

xorcist 10y ago
How do you deploy new code in a decentralized system? Could such a possibility not be used to change smart contracts post-facto?
- 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?