3 ms·
1) Well, contracts have balances, true. The people calling the contracts pay for it to run, so the dead terminology is at best imprecise. If the contract pays o
by vessenes 10y ago
1) Well, contracts have balances, true. The people calling the contracts pay for it to run, so the dead terminology is at best imprecise. If the contract pays out 10 ether in .01 ether increments, and never takes any in, then it will be dead once depleted. On the other hand, people calling the contract pay for the cycles to run it, so one wouldn't typically go dead in that way.
2) I'm not an expert on the registrar situation by any means. But, I do not believe that updating a registrar pointer changes the balances at each contract (the old and new), so while it may be useful for some cases, those which involve balances may be more troublesome if you haven't thought ahead.
- ChemicalWarfare 10y agothe 2nd point was to address the fact that the contract can be updated/patched with little if any impact to it's end users. so the new version of the contract gets pushed out, the old one is not in use any longer and just kind of dies off :)
- vessenes 10y agoRight, but for a ponzi scheme contract, that's not a great outcome. Or, say, a crypto-currency, one of the sample apps in Ethereum documentation. Either way, you have a trust problem -- who shall be trusted to transfer out all the value the contract holds?
- ChemicalWarfare 10y agoI would imagine that would be something the contract identifies explicitly along the lines of Bitcoin multisig.
- vessenes 10y agoThat's one conversation I'm hoping to get launched soon. The sample 'make your own digital currency' code from Ethereum has no such provisions right now. To my mind, it's a little like K&R C showing you how to walk through a string in the 1980s -- adversarial data was not a big concern at the time.
- dv_dt 10y agoHow does one assure the the updated contract only fixes bugs and doesn't change the intent of the original contract?