3
$\begingroup$

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

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

The code is written by serious professionals : not the kind of Ponzi scheme coder leaving useless code that cost money to everyone while processing transactions. As the contract is no longer maintained, developers are no longer replying on such questions (mailto:service@tron.network).
The point is msg.sender is set by the network : contract cannot act on that value.

Most of time unofficial answers I’m getting is it’s indeed possible to send transactions as 0x0 : that is Keccak256(ECDSASIGN(transaction_data_to_sign,e, c, v)[1:])[12:] where Secp256k1 is used would returns NULL.

So… First, are there known keccak256 values that would return NULL once truncated or does NULL involve bruteforcing like all other values ?

$\endgroup$
  • $\begingroup$ What do you mean by NULL? Do you mean that the first 160 bits are 0? In pure Keccak that's indeed finding a collision, so I think whatever this sender is, 0x0 is some kind of special value. That would also mean this is not a cryptography question. $\endgroup$ – Ruben De Smet Jun 9 '18 at 16:59
  • 2
    $\begingroup$ @RubenDeSmet Finding an input that hashes to a specific output is not a collision but a preimage. $\endgroup$ – yyyyyyy Jun 9 '18 at 17:14
  • $\begingroup$ Off topic: Although it may not be the legal definition of a Ponzi scheme, anything with a market value that is 99-100% based on speculative trading is functionally similar. Are you buying something only because you hope it will be worth more later? Between buying and selling something did you add value to what you profited from? (Simply manipulating demand to raise prices does not count.) If everyone else leaves the marketplace and you're the last person holding onto a product will you be happy with it? Cryptocurrency in general is worrisome when you ask yourself these questions. $\endgroup$ – Future Security Jun 9 '18 at 18:42
  • $\begingroup$ @RubenDeSmet yes, that’s what I am meaning. $\endgroup$ – user2284570 Jun 9 '18 at 19:28
  • $\begingroup$ @FutureSecurity no, I’m talking about tokens which additional to their market value can be converted to sound money at a minimal rate (provided the peoples who come doesn’t drop). And with EOS, you doesn’t only have a token, but shares in voting rights. $\endgroup$ – user2284570 Jun 9 '18 at 19:31
1
$\begingroup$

No. SHA-2, Keccak, and serious alternatives to those two are all assumed to be model-able as a random oracle. Given an valid input it will return back a bit string chosen from a uniform random distribution.

The probability of any one such string starting with an all zero 160 bit prefix is $2^{-160}$. That's too small to find by chance. The amount of work to search for such a string should therefore be about equivalent to $2^{160}$ hash evaluations. That would consume a lot of time and a lot of power. So much so that it's impossible for any of us Earthlings to acheive.

If there is a way to search for inputs whose outputs have a certain property which is faster than by brute force, then that means the algorithm is broken. An attack that lets you easily find inputs that result in output bits set to a certain value is called a (partial) preimage attack.

Edit: I answered only the cryptography part of the question. Not the cryptocurrency. That's off topic for this site. Also off topic is the contract code. There could be some subtle (or obvious) problem in the code that causes problems or enables scams. Maybe there is some type conversion rule that mixes up zero values, null pointers, none-value. Maybe errors propagate as null pointers or zero return values. Do not interpret my not covering non-cryptography material as endorsement of a product.

$\endgroup$
  • $\begingroup$ That’s what I’m thinking, the check of msg.sender is about something else. Concerning the check, it’s partially understandable with the burn function etherscan.io/address/…. But this still involve at least maskguarding as 0x0 for msg.sender. $\endgroup$ – user2284570 Jun 9 '18 at 19:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.