3 ms·

Scanning Live Ethereum Contracts for the “Unchecked-Send” Bug

43 points by jackgavigan 10y ago

CoolGuySteve 10y ago
Maybe a metalanguage or lint is required that forces unchecked exceptions as errors and adds more strictness. i.e.: checks things that are not relevant to the contract terms but are relevant to its correctness.
- nemild 10y ago
  I think it's likely that over time many changes will happen (first a blog post like this noting the issue, then a linter, then libraries that are safer, and then potentially language changes to reduce the risk of the most egregious mistakes). Programming smart contracts will also require a different mindset than general programming, since modifying code on the blockchain is much harder than your own app.
a1k0n 10y ago
Having to manually inspect the call stack depth as a best practice seems like a design flaw... why doesn't send() itself throw an exception? And does an exception roll back the entire contract or would it leave it half executed?
- socrates1024 10y ago
  It would be a good idea for Solidity to properly support exceptions, this would probably simplify things a lot. Right now solidity has exceptions, but no way to 'catch' them. Ordinary function calls automatically propagate exceptions when there's a problem. But, unintuitively, `send` behaves differently. It would be trivial to modify `send` in Solidity so that it automatically throws an exception, like in Listing 3. But that's also often an anti-pattern, since it would allow the 'loser' to prevent the 'winner' from ever getting the money back. Sometimes it's important to keep on executing even if the `send` fails. So once Solidity supports `catch`, that would help.
- Natanael_L 10y ago
  Transactions can only either fail or succeed, nothing in between. They're atomic. The effects of the transactions aren't applied until the scripts have been validated in full. Uncaught exceptions and unhandled errors means the transaction validation failed, and it is invalid. If the transaction script on the other hand is set to deal with them and try something else instead, it might still succeed (there can be multiple alternate conditions that may independently grant right to transfer the coins).

43 points by jackgavigan 10y ago

Maybe a metalanguage or lint is required that forces unchecked exceptions as errors and adds more strictness. i.e.: checks things that are not relevant to the contract terms but are relevant to its correctness.

nemild 10y ago
I think it's likely that over time many changes will happen (first a blog post like this noting the issue, then a linter, then libraries that are safer, and then potentially language changes to reduce the risk of the most egregious mistakes). Programming smart contracts will also require a different mindset than general programming, since modifying code on the blockchain is much harder than your own app.

a1k0n 10y ago

Having to manually inspect the call stack depth as a best practice seems like a design flaw... why doesn't send() itself throw an exception? And does an exception roll back the entire contract or would it leave it half executed?

socrates1024 10y ago
It would be a good idea for Solidity to properly support exceptions, this would probably simplify things a lot. Right now solidity has exceptions, but no way to 'catch' them. Ordinary function calls automatically propagate exceptions when there's a problem. But, unintuitively, `send` behaves differently. It would be trivial to modify `send` in Solidity so that it automatically throws an exception, like in Listing 3. But that's also often an anti-pattern, since it would allow the 'loser' to prevent the 'winner' from ever getting the money back. Sometimes it's important to keep on executing even if the `send` fails. So once Solidity supports `catch`, that would help.
Natanael_L 10y ago
Transactions can only either fail or succeed, nothing in between. They're atomic. The effects of the transactions aren't applied until the scripts have been validated in full. Uncaught exceptions and unhandled errors means the transaction validation failed, and it is invalid. If the transaction script on the other hand is set to deal with them and try something else instead, it might still succeed (there can be multiple alternate conditions that may independently grant right to transfer the coins).