4 ms·

Yikes. And this is why we don't use "clever" solutions. For some context, gas (or operations expense) usage was never designed for re-entrency protection. Afte

Yikes. And this is why we don't use "clever" solutions. For some context, gas (or operations expense) usage was never designed for re-entrency protection. After the DAO attack, in order to prevent re-entrency attacks the Solidity interpreter limited the gas of external calls. It's clever way to solve the problem. However now when we're trying to change around the gas for certain operations, it's jeopardizing previous contracts that relied on this "clever" solution. To be honest, this is really bad, cause I'm not sure how Ethereum can ever safely adjust gas. Edit: I'm not sure how Ethereum can ever safely adjust gas... until they go back and "monkey patch" all the smart contracts that used the external gas call limit. Since we only can see the compiled code, there's no real way to know if a deployer explicitly wanted that external gas call limit, or was just using it for re-entrency protection.

api 8y ago
The whole Ethereum VM is too complex. For a role like smart contracts you'd want something dirt simple with few operations and provability.
- aakilfernandes 8y ago
  IMHO the VM here isn't really the problem. Its the compiler. The way I look at it this is really a compiler bug, that only gets "activated" with this upgrade.
  - amluto 8y ago
    The whole design is bad. Calls out to untrusted code should never have been allowed. You should be able to send messages out to untrusted code and to send ether. Perhaps the recipient of a message could be allowed to raise an exception, thus causing the transaction to abort, but otherwise the untrusted code should never have been allowed to reenter anything.
    - aakilfernandes 8y ago
      There's a simple way to prevent re-entrency. ---------- bool isEntered = false; function doSomething() { if (isEntered) { throw; } isEntered = true; ...; isEntered = false; } ---------- I don't really understand why they went with this gas-limit solution. I feel like there must be something I'm missing cause its too obvious.
      - zaarn 8y ago
        Because the kind of developer the average ICO scam hires isn't quality enough to code this kind of security.
      - DennisP 8y ago
        A similar method is to put the external call at the very end of your function, after any state updates, and make sure that function isn't called from another function. These are well-known techniques in the community and commonly used, which is probably one reason the researchers didn't find any vulnerabilities in deployed contracts. The gas limit on send was more of a belt-and-suspenders thing, not intended as the sole protection; that may have been a bad idea in retrospect, but at the time people were pretty focused on adding every protection possible against another DAO situation.
tsukikage 8y ago
http://www.hyrumslaw.com/ http://www.hyrumslaw.com/ "With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody." Gas costs have observable side effects, therefore someone will depend on them.

api 8y ago

The whole Ethereum VM is too complex. For a role like smart contracts you'd want something dirt simple with few operations and provability.

aakilfernandes 8y ago
IMHO the VM here isn't really the problem. Its the compiler. The way I look at it this is really a compiler bug, that only gets "activated" with this upgrade.
- amluto 8y ago
  The whole design is bad. Calls out to untrusted code should never have been allowed. You should be able to send messages out to untrusted code and to send ether. Perhaps the recipient of a message could be allowed to raise an exception, thus causing the transaction to abort, but otherwise the untrusted code should never have been allowed to reenter anything.
  - aakilfernandes 8y ago
    There's a simple way to prevent re-entrency. ---------- bool isEntered = false; function doSomething() { if (isEntered) { throw; } isEntered = true; ...; isEntered = false; } ---------- I don't really understand why they went with this gas-limit solution. I feel like there must be something I'm missing cause its too obvious.
    - zaarn 8y ago
      Because the kind of developer the average ICO scam hires isn't quality enough to code this kind of security.
    - DennisP 8y ago
      A similar method is to put the external call at the very end of your function, after any state updates, and make sure that function isn't called from another function. These are well-known techniques in the community and commonly used, which is probably one reason the researchers didn't find any vulnerabilities in deployed contracts. The gas limit on send was more of a belt-and-suspenders thing, not intended as the sole protection; that may have been a bad idea in retrospect, but at the time people were pretty focused on adding every protection possible against another DAO situation.

tsukikage 8y ago

http://www.hyrumslaw.com/ http://www.hyrumslaw.com/ "With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody." Gas costs have observable side effects, therefore someone will depend on them.