Stop the ERC20 FUD. Just learn and #BUIDL

There’s an article going around that is creating a lot of #FUD in the #ERC20 #Ethereum community. Know that “batchTransfer” is not even part of the ERC20 standard. Here’s the article and my response on how to #BUIDL contracts that avoid such a bug.

https://medium.com/@dan.ryan.emmons/its-essentially-the-same-type-of-overflow-that-can-occur-in-any-type-of-arithmetic-since-3020a9893159

Now, I would agree — but I’ve been a developer for 18 years, and can tell you, that even the best of us with nearly two decades coding highly reliable, highly secure financial applications can make minor mistakes that have disasterous results. In past, developers could simply stop the server, revert the change in a database they control, and patch a bug fix. But we are in a new paradigm. The code that we deploy to a blockchain is immutable. It cannot be fixed (until we develop better ways to create upgradable / proxy contracts). We can use this moment as a way to learn and expand our knowledge.

The greater our knowledge increases, the greater our ignoarance unfolds.

The languages and tools we are using are moving so fast that it is nearly a full time job just to keep up with the 24/7/365 changes to the very tools we use in order to accomplish our tasks. It is a daunting job that can really wear you down if you let it. Check out this Week in Ethereum post about what has changed in only ONE WEEK alone!

Such a pace cannot help but create new ails as it dispels old. So it is not surprising that some would have us stay where we are a little longer. To rest, to wait.

But this is not a time to discuss reasons to be gloomy. Never before has humankind been so empowered than with the use of #blockchain / #crypto technology. This is the most exciting, empowering innovation in 30 years.

If this capsule history of our progess teaches us anything, it is that Man and his quest for knowledge is determined and cannot be deterred.

When we deploy our smart contracts, it is highly comparable to launching an unstoppable rocket into space, and hope that all the hours of coding, of testing with Mocha in the Truffle framework, all the hours dedicated to integration testing, all the hours toiling over audits — we hope that we have not left out one tiny error that can take down the entire operation.

But these technology advancements in #Blockchain and #SmartContract development were not built by those who waited, and rested and wished to look behind them. The exploration of this space will go ahead, if you’re ready to #BUIDL with us or not. Those who came before us made certain that we could ride the first waves of modern invention and the first wave of empowerment.

And this generation does not intend to founder in the backwash in the coming age of the Blockchain space. WE MEAN TO BE A PART OF IT. WE MEAN TO LEAD IT. If you’d like to join us, please come along and learn in the #HowToBUIDL series.

We choose to do these things…

not because they are easy, but because they are hard. Because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone. And therefore as we set sail, we ask God’s blessing on the most hazardous and dangerous, and greatest adventure on which man has ever embarked.

Sound familiar? It should. Prior generations led the way. It’s up to us in the #Blockchain space to keep moving innovation forward. Because the people who are crazy enough to think they can change the world, are the ones who do. Here’s

Original Article:

That function the author pointed to in the article isn’t even in the ERC20 — batchTransfer is just a function they added to their own contract. Here’s the standard: https://theethereum.wiki/w/index.php/ERC20_Token_Standard

Here’s the random function they wrote: https://medium.com/coinmonks/alert-new-batchoverflow-bug-in-multiple-erc20-smart-contracts-cve-2018-10299-511067db6536

And here’s the way to avoid writing things like that using SafeMath. Wonder why they titled this article ‘New … bug’. It’s essentially the same type of overflow that can occur in any type of arithemtic, since multiplication is just repetitive addition.

The problem can be avoided: using SafeMath for uint256;

using SafeMath for uint256;

Then instead of adding or multiplying directly with the + or * operators, you call add or mul, and the necessary required overflow checks are done for you.

uint256 result = someNumber.mul(someOtherNumber);

The implementation of SafeMath.mul:

/**  * @dev Multiplies two numbers, throws on overflow.  */  function mul(uint256 a, uint256 b) 
internal pure returns (uint256 c) {
if (a == 0) {      
return 0;
}
c = a * b;
assert(c / a == b);
return c;
}

https://github.com/OpenZeppelin/zeppelin-solidity/blob/master/contracts/math/SafeMath.sol

Read: Why Blockchain? We choose to go to the Moon.

Dan Emmons is owner of Emmonspired LLC, a Certified Bitcoin Professional, Certified Ethereum Developer, Full Stack Developer and Advisor on Cryptocurrency projects. He is also the creator of a Youtube Channel and iTunes Podcast called #ByteSizeBlockchain.