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

Question

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 ?

Answer 1

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.

Answer 2

It's just a validation that is recommended to do, ethereum and its tool for accessing smart contracts are constantly under development, and that opens the possibility of sending certain data empty or null, and something as serious as an ICO has to cover its back by over validating input data.

As a backend software developer you have to start from the premise that every frontend, mobile or any client can a will send corrupted or malicious data, and is your responsibility to keep your data save, correct and coherent.

Answer 3

It simply try to trap internal errors causing invalid parameters loading on the stack. The “null pointer” reference is a frequent consequence of stack or dereference problems. Nothing guarantees you that your internal error will result in a null pointer call, but it is quite frequent because uninitialized memory is often zeroed.

That can even be “at least let’s try to avoid that some unpredictable internal error burns coins, please, and if you catch any null pointer around here, quit and revert”

In other words if on one side it is not given that any internal error bring you to a null pointer temptative of use, on the other side it is given that if you have a null pointer here, something is wrong.

Someone is concerning about the fact that the msg.sender address is obtained directly from a EVM call code, namely 0x33, and that being so it cannot be returned wrong.

In order to explain it better: Let’s say I call the 0x33 EVM callcode “CALLER” in order to obtain msg.sender address. Where do I push it in order to compare it with zero? If you answer you will find a first possible area of local corruption, that can be corrupted both writing wrong data in it and in the pointers used to manage it locally: the stack.

if your system is corrupted you can be writing, for instance, the 0x33 return data in some no safe area, where no memory do exist or where it is not writable by your process and you will read it back as 0x0 or other crazy things if you are not able to revert for this. And if the system is corrupted the revert propagation is not guaranteed.

Btw: go on etherscan and look at 0x000...000 address. Is it a valid address to you? Did you think it has been filled with so much ether for a precise willing or for users/code errors?

Furthermore (from a comment): The stack is addressed by the stackpointer, that is a local memory address maintained in a “register”. When you push or pop the “cpu” reference that and increment it in order to point to next slot, decrement if pop.If you have a corrupted stackpointer you will push the value somewhere not known, and when you will pop you will read that somewhere memory location. If you encounter standard ram, nothing happens in that instant... If you think to write (push) where no memory exists or where you are not allowed to read or write, you will read back (pop) 0x0. Ever. This is a canonical example.