[Ethereum] What’s the point of checking msg.sender≠0 ? Are there cases where msg.sender can be null

erc-20Securitysolidity

In the Tron contract (a large ICO listed on many exchanges) lies this modifier which is used for all token transfers :

modifier validAddress {
    assert(0x0 != msg.sender);
    _;
}

I understand how a contract can write directly into the ledger that a token transfer is made from 0x0000000000000000000000000000000000000000, but in that case, the msg is still tied to a an existing contract or private key.
What does this means ? How msg.sender can be equal to 0 ? (excepted the hypothetical case where a keccak256 hash collision is found)

Or could it be because of https://github.com/ethereum/EIPs/blob/master/EIPS/eip-86.md#specification ? If yes, how to withdraw other unprotected ERC20 from the 0x0 ethereum account on next fork ?

Best Answer

Firstly, they're using an assert(), not a revert().

From the docs:

The assert function should only be used to test for internal errors,

And:

Properly functioning code should never reach a failing assert statement; if this happens there is a bug in your contract which you should fix.

See: Difference between require and assert and the difference between revert and throw

Which describes using assert() to "...avoid conditions which should never, ever be possible."

You would need to ask the developers what internal errors they were expecting when they developed and tested the code.

How msg.sender can be equal to 0 ?

Having said all this, address 0x0 is a perfectly valid address. It's just as possible that you'll find the private key to this address as to any other address. If someone does find the associated private key, yes, they'll be very rich, given this address's use as a burn address. (There's a small caveat: not all addresses have associated private keys, given the way addresses are generated. There's no way to know whether address 0x0 is one of these addresses.)

This would mean that the potential owner of 0x0 wouldn't be able to use the Tron contract, which would be a shame... I imagine there are other contracts that have the same check.

It’s hard to believe that such serious project similar to EOS listed on more than 50 centralized large volume exchanges and a volume over 200000000$ per day would have left useless code.

For me that's very easy to believe. The code is essentially copied. When you copy someone's code, you're doing so because you believe it's more transparent than writing your own, while also taking less effort. You make various assumptions, one of which is that the original developers knew what they were doing. If you know the code is already working for someone else, you leave it alone. And yes, that's potentially one way to end up inheriting dead code.

Related Topic