-
Notifications
You must be signed in to change notification settings - Fork 231
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Potential overflow in crowdsale participation with indivisible tokens #247
Comments
Nice, thanks for this dude :) Why don't we do the inflation of amounts once we're in uint256? We can avoid the modification of With a simple patch such as zathras-crypto@33f3114, perhaps we may address this issue, #248 and #249 together? Note - this is just I attempted to replicate your regtest with the patch:
|
That's pretty nice actually, and it even removes the artificial limit. Can you think of any downsides?
I'm very sure calculateFractional should be overhauled, because it basically re-runs all crowdsale participations to calculate totals.. as But there is good news: unless I overlook something, we may almost completely remove it, because we already sumed all values. int64_t missedTokens = (crowdsale.getUserCreated() * [bonus]) - crowdsale.getIssuerCreated();
|
CMPTransaction::logicHelper_CrowdsaleParticipation:
The cut-off is
92233720368
, which is the largest number wherenValue * 100000000 <= INT64_MAX
, and sending more than92233720368
indivisible tokens either causes an assertion violation or undefined behavior.To be more specific:
The assertion violation is caused by the conversion of
uint64_t
toint64_t
, which results in negative numbers in that range (rejected via ConvertTo256).The results for numbers higher than
184467440738
are undefined, meaning: it's up to the compiler implementation how it's dealt with. On my system it seems to be0
, but it can really be anything between0
andMAX
.The positive:
The negative:
It's notable, even without overflow, that
92233720368
is the maximum number of divisible tokens that are "counted" anyway..Potential fix:
edit: calculateFractional (for missed tokens) must be adjusted for the fix.
This is potentially consensus breaking.
The text was updated successfully, but these errors were encountered: