4

I use safemath in (more or less) any contract where the number input could be malicious. But I have a contract that only handles ether. You can transfer ether to the contract. The ether amount can not be malicious (as far as I know).

So, I am wondering, when do I really NEED to use safemath. Adding safemath also adds some complexity, thus more gas is required.

Improve this question
5
  • Certainly the amount of ether sent can be malicious (since an attacker controls it), but whether or not that can have an adverse effect on your contract can't be determined without looking at the contract.
    – user19510
    Commented Jan 7, 2018 at 14:26
  • Well, but the amount has to be positive as well as it is bound to the global limits. So I doubt that the amount can be malicious. Or is there a way to manipulate the ETH Amount?
    – kn1g
    Commented Jan 7, 2018 at 16:00
  • You might, for example, multiply the amount of ether by some value. Or perhaps accounts need to send you x ether before receiving some reward, and you subtract the amount sent from x (leading to integer underflow). As I said, it's impossible to know without seeing the code.
    – user19510
    Commented Jan 7, 2018 at 16:06
  • Well that is the only "complex" math uint256 varA = msg.value/1000*varB; varC += varA; varD += msg.value - varA; But I got your point. Code can be buggy. You never know...
    – kn1g
    Commented Jan 7, 2018 at 16:17
  • Depending on varB, varA could potentially overflow or varD could potentially underflow. Again, it's impossible to tell you whether or not you have potential overflows/underflows without seeing the code.
    – user19510
    Commented Jan 7, 2018 at 16:21

1 Answer 1

Reset to default
4

If the only maths you need to do is adding sums of Ether obtained from msg.value to other sums of Ether obtained from msg.value, it shouldn't be necessary to use SafeMath, since the msg.value is bounded by the number of Ether in existence, which is well below the range that can be represented by a uint256.

As you suggest using SafeMath means a trade-off: The downside is higher gas costs (mainly on deployment) and greater complexity. If the contract is very simple, you're only doing addition and it's very easy to verify that all the values in it are bounded and the total can't possibly overflow, I'd be inclined to leave it out.

However, if there's a little bit of complexity in the contract, there's a case for using it just to make it easy to verify that bounds-checking is being done, and if you have to use it in one place, it's arguably simpler to audit if you use it on all the maths in your contract.

Improve this answer
2
  • I do not only use add and sub. I also use mult and div but imho that should be safe as there is only the msg.value. No other input.
    – kn1g
    Commented Jan 7, 2018 at 16:15
  • OK, it's a judgement call that we'd have to see the rest of the contract to make, but if you're multiplying and dividing then presumably you also have a number that you didn't get from msg.value to multiply or divide by, so based just on that description I'd be inclined to use SafeMath.
    – Edmund Edgar
    Commented Jan 8, 2018 at 7:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.