You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Update In the end, we just add a check to Multiply to see if it will overflow. If it will overflow, return an error instead. (Using normal int64 math or big to check it).
Then we can guarantee no overflows can happen
Is your feature request related to a problem? Please describe.
We can use big, or we can just limit the ranges to make sure we never overflow int64. I think the second case is quite easy, as total token supply should generally fit in int32 and int64 was for super-safety already.
But let's discuss if this is needed and how urgent
The text was updated successfully, but these errors were encountered:
Limit each account to store 2^32 in Whole (MaxInt32).
Limit any multiplier to 2^31 (fee dist)
We can never have an overflow.
I think this is allows lots of math using the normal ints and restricting an account to 4 billion tokens shouldn't be a big problem (seriously, even if you had more, please put them behind multiple private keys)
Update In the end, we just add a check to
Multiply
to see if it will overflow. If it will overflow, return an error instead. (Using normal int64 math or big to check it).Then we can guarantee no overflows can happen
Is your feature request related to a problem? Please describe.
This came up in a PR review comment #322 (comment)
Describe the solution you'd like
Never overflow when calculating with Coins
Describe alternatives you've considered
We can use big, or we can just limit the ranges to make sure we never overflow int64. I think the second case is quite easy, as total token supply should generally fit in
int32
andint64
was for super-safety already.But let's discuss if this is needed and how urgent
The text was updated successfully, but these errors were encountered: