district0x Contract Audit about district0x-network-token

[madvas]

Thanks Adam for a very nice audit! I have some questions:

Moderate: In general this contract uses unix timestamps (now) to control behavior. This value is somewhat manipulatable by miners (within bounds) and usually a better approach is to use block number as a proxy for date / time instead.

Could you provide some resources, why timestamp is less secure than block number? I was searching about this, asking around, didn't find much. There's been many major sales, which used timestamps and everything seems to go well.

Minor: In the function compensateContributors you calculate ratio to be the amount of tokens per ether contributed. You then take the amount contribute, turn this into an ether amount (divide by 10^18) and multiply by ratio. You could consider having ratio instead being the amount of tokens per wei contributed, which would avoid these divisions by 10^18 and make the code clearer.

Could you please explain this some more, not quite sure what you mean. Or maybe you could provide some code example?

[adamdossa]

Hey Matus, With regards to the Unix timestamp, my understanding is that it is somewhat reliable, but ultimately can be manipulated within very small bounds by miners. This may not be a problem in your case, but my general approach with smart contracts that will hold value (e.g. ICOs) is that any sources of uncertainty should be removed, even if there is no immediately obvious problem. Some stack exchange threads discussing this: https://ethereum.stackexchange.com/questions/5924/how-do-ethereum-mining-nodes-maintain-a-time-consistent-with-the-network https://ethereum.stackexchange.com/questions/413/can-a-contract-safely-rely-on-block-timestamp I'll put together some code to explain the 2nd issue shortly. Couple of other quick questions: 1) are you interested in me refactoring your use of VestedToken / Erc20 / MiniMeToken as per suggestions in the review? Happy to take this on as a piece of work. 2) i'd love to know if youre also paying 100+ ETH for a review from Griff as it would help me calibrate my rates for future work. If you are paying this amount, what are you expecting for this price? Thanks very much - I love ethlance - I think I am one of your more active users! Thanks, Adam

…

________________________________ From: Matus Lestan <[email protected]> Sent: Thursday, June 29, 2017 5:52:23 AM To: district0x/district0x-network-token Cc: Adam Dossa; Mention Subject: Re: [district0x/district0x-network-token] district0x Contract Audit (#4) Thanks Adam for a very nice audit! I have some questions: Moderate: In general this contract uses unix timestamps (now) to control behavior. This value is somewhat manipulatable by miners (within bounds) and usually a better approach is to use block number as a proxy for date / time instead. Could you provide some resources, why timestamp is less secure than block number? I was searching about this, asking around, didn't find much. There's been many major sales, which used timestamps and everything seems to go well. Minor: In the function compensateContributors you calculate ratio to be the amount of tokens per ether contributed. You then take the amount contribute, turn this into an ether amount (divide by 10^18) and multiply by ratio. You could consider having ratio instead being the amount of tokens per wei contributed, which would avoid these divisions by 10^18 and make the code clearer. Could you please explain this some more, not quite sure what you mean. Or maybe you could provide some code example? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#4 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ACgwuYFjFToW_MXroxL3sFUkzwHR8U47ks5sIx93gaJpZM4OIQsw>.

[madvas]

Thanks!

1. Although those changes may make code a bit cleaner, at this point, since there are some other audits in progress, I'd avoid doing major changes just for cosmetic purposes. So probably we won't implement.
2. Yes, we're paying that much, but it's an audit from Jordi Baylina, rather than Griff. Prices of audits today literally range from $800-$80,000, that's why we decided to do this via Ethlance to bring more pricing transparency into this market.

[adamdossa]

Fair enough! Will the 10% bonus you mentioned on your medium article apply to these reviews ;-) ? With regards to the ratio point, my suggestion was to remove the: *.mul(1000000000000000000) and .div(1000000000000000000)* so the code would become the below. This would reduce some unnecessary computational steps and decrease chances of any overflow issues : * uint ratio = contribPeriodsStakes[periodIndex]* * .div(contribPeriods[periodIndex].totalContributed);* * while (i < contributorsCount && compensatedCount < limit) {* * address contributorAddress = contributorsKeys[i];* * if (!contribPeriod.contributors[contributorAddress].isCompensated) {* * var amountContributed = contribPeriod.contributors[contributorAddress].amount;* * contribPeriod.contributors[contributorAddress].isCompensated = true;* * contribPeriod.contributors[contributorAddress].amountCompensated =* * amountContributed.mul(ratio);* * district0xNetworkToken.transfer(contributorAddress,* * contribPeriod.contributors[contributorAddress].amountCompensated);* * compensatedCount++;* * }* * i++;* * }* Thanks, Adam

…

On 29 June 2017 at 08:43, Matus Lestan ***@***.***> wrote: Thanks! 1. Although those changes may make code a bit cleaner, at this point, since there are some other audits in progress, I'd avoid doing major changes just for cosmetic purposes. So probably we won't implement. 2. Yes, we're paying that much, but it's an audit from Jordi Baylina, rather than Griff. Prices of audits today literally range from $800-$80,000, that's why we decided to do this via Ethlance to bring more pricing transparency into this market. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACgwuWuBfLUF_9q-cxN9g_jNl1mmvrhlks5sI0eqgaJpZM4OIQsw> .

[madvas]

Yes, 10% bonus applies to your review ;)
ok thanks, will test the code

[adamdossa]

Great thanks - will look forward to reading the other security reviews when they come out!

…

________________________________ From: Matus Lestan <[email protected]> Sent: Thursday, June 29, 2017 9:31:25 AM To: district0x/district0x-network-token Cc: Adam Dossa; Mention Subject: Re: [district0x/district0x-network-token] district0x Contract Audit (#4) Yes, 10% applies to your review ;) ok thanks, will test the code — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#4 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ACgwuQZcrtHivFTCaDuZ4-IoIUJ-GqZIks5sI1LNgaJpZM4OIQsw>.

[madvas]

Ah, so you just removed .mul(1000000000000000000) and .div(1000000000000000000), but that wouldn't work, because you'll lose precision too much. In solidity there are no float numbers, that's why is there this multiplying and dividing.
When I run tests with it, there're errors like:

expected: (bn/eq? expected-dnt (<! (contract-call-ch DNTToken :balance-of contributor)))
  actual: (not (bn/eq? #object[BigNumber 8.5714285714285714285714285e+25] #object[BigNumber 8.5714285e+25]))

You can see expected number of DNT tokens is 8.5714285714285714285714285e+25, but actual number is 8.5714285e+25 - lost 18 decimal points precision

[adamdossa]

Ah OK - that makes sense - thanks for the feedback - do you want me to edit the Issue to reflect this?

…

On 29 June 2017 at 09:53, Matus Lestan ***@***.***> wrote: Ah, so you just removed .mul(1000000000000000000) and .div(1000000000000000000), but that wouldn't work, because you'll lost precision too much. In solidity there are no float numbers, that's why is there this multiplying and dividing. When I run tests with it, there're errors like: expected: (bn/eq? expected-dnt (<! (contract-call-ch DNTToken :balance-of contributor))) actual: (not (bn/eq? #object[BigNumber 8.5714285714285714285714285e+25] #object[BigNumber 8.5714285e+25])) You can see expected number is DNT tokens is 8.5714285714285714285714285e+ 25, but actual number is 8.5714285e+25 - lost 18 decimal points precision — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACgwuSJgF53JDUVVGdRQQWwHsH-q96riks5sI1fggaJpZM4OIQsw> .

[madvas]

yep, sure if you will

[adamdossa]

I have removed this Minor issue as per discussion.