4 ms·

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.