If someone found a private key to 0x0, would they be able to access all the tokens (over one billion dollars worth) stored there?

Question

The 0x0 address in Ethereum has a lot of token stored in it that have been burnt in the past. However, it appears they burning is the same as sending to 0x0. In that case, could all of those burnt tokens be recovered if someone had access to the private key for 0x0?

Answer 1

Hypothetically speaking, yes. If someone managed to guess a private key to 0x0, then they would have full control over all ether/tokens belonging to that address. It is so unlikely that it's considered impossible because you would have to randomly generate private keys until you found one that generates the 0x0 address. Also, there might not even be a private key that generates the 0x0 address because of the non-1-to-1 nature of hashes.

Answer 2

Yes they would have access to all the tokens and ETH. The only way to carry out such attack would be creating keypairs until you reach that address'es keypair. But you must understand that achieving success with such attack is extremely unlikely.

Answer 3

~EDIT: Came up with a better explanation of my point...

It's the "null" address

The 0x0 address can be thought of, in many cases, as the equivalent of the null device in a UNIX system whereas the 0x0 address is like the null address of the Ethereum network.

• You can send data to /dev/null and it will be discarded just as the ETH will be "burned."
• It provides contracts with a destination address so that it can execute but makes the coins sent irretrievable just as data written to /dev/null is discarded but reports a successful write operation
• You can see the existence of /dev/null when running stat /dev/null just as you can see the existence of the 0x0 address on the blockchain as if it was a real address but you can neither read from it nor open it like a regular adress
• Just as there is a trace of what commands were used and may give an indication as to what was sent piped to /dev/null/ as found in one's .bash_history it doesn't mean it's actually there, similarly the blockchain has the history of contracts that send crypto to the 0x0 address but it is no more accessible than the data that was sent to /dev/null

Perhaps in an attempt to continue this analogy, to hypothetically consider if you found the key would perhaps be more similar to considering if hypothetically /dev/null was not a file but directory (since you could mv or cp files to it as if it was a directory), then could you see or copy the files out of there if someone could hypothetically cd into it?

That's more or less what I was trying to say with the whole divide by zero analogy...

END EDIT~

It's impossible though

It only appears that way because of what some blockchain explorers websites show you as the address having a balance but they're more or less only virtual representations of a non-existing account's balances.

The answers offered here seem to be misleading as the hypothetical situation being described can only exist hypothetically on top of other implied or assumed hypothetical scenarios in that there is no private key to exist for the address 0x0000000000000000000000000000000000000000 since private keys only exist for externally owned addresses as part of being the reference for an account with a public and private key pair.

Some argue it's not impossible, stating that it's a false assumption, but I've yet to find any evidence to support the feasibility of a keccak256 hash ending in forty zeros when derived from 64-byte uncompressed key. But I could be wrong....

It's hypothetical on top of hypothetical

Even if we lived in a hypothetical world where it would be possible and a private key could exist for the 0x0000000000000000000000000000000000000000 address, also known as the null address or "zero address", then to answer the question, it's more of a hypothetical "no" than a hypothetical "yes" because there's no way to validate the private key for any sort of transaction being broadcast to the network since the null address doesn't technically have a public key (or an associated eth_accounts) and the input can't be processed by the protocol that performs the transaction processing.

Further Consideration

Not to mention, the address is a blocked account and even though there's not a decentralized mechanism to prevent transactions from any single particular address, since it's a public ledger it's not as if they would be able to "recover" the funds per se (similar to blacklisted) by exchanging it to something of real-world value. so again, at that point, you'd have to introduce more hypothetical contingencies (i.e. the address is an actual address tied to an account, that the address could be derived from an integer which results in all zeros, etc.) that wouldn't exist within the realm of known realities (at by today's known laws of physics, mathematics, and programming).

More Detailed Overexplanation

To elaborate, it is impossible to imagine a scenario where a person could have access to the private key of the address 0x0000000000000000000000000000000000000000 because to have a private key, an address would need to be owned by an Ethereum account and the null address itself is more or less the representation of a non-existing address and isn't representative of real address or the last 20 bytes of a keccak256 hash of a 64-byte uncompressed public key. The null address, or zero address, in other words, only displays a total balance of "virtual ether" on blockchain explorer-type websites because the ETH isn't destroyed per se (removed from total supply) when being sent to the null address and shows a continued existence as a means of convention more than anything. A question about using 0x0 for burning has this answer which speaks to it well in explaining that:

The account balance and the total supply are respectively decremented with _balances[account] = accountBalance - amount; and _totalSupply -= amount;.

Although the event Transfer assimilates the burn operation to a transfer to the zero address, this is not the case, and this event is purely conventional.

Since the Ethereum network is essentially a ledger, it has to "track" sort of speak, all the transactions (or in relation to the quoted above, transaction "events") taking place including being sent to a non-existing address (AKA the null address) and since null address is not a self-destructing contract, it is just the referenced address for documenting the transaction of contracts involving those ETH which were sent to it or otherwise meant to be sent to an address that doesn't or can't exist. It may help to know that a generally speaking, burning or destroying ETH is accomplished by having a contract that transfers the funds to a contract that will self-destruct and otherwise makes those ETH irrecoverable as the contract seizes to exist and makes the ETH simply vanish to also affect and reduce the reported number of ETH in the total supply. This means to say that although the ETH isn't destroyed in the sense that it no longer exists and is still accounted for by being included in the count of coins for Total Supply, it is neither accessible or recoverable because the address itself can't be accessed in that way. It's more like a common variable representative "address" developers use for sending ETH to that programmatically can't be accessed by someone to control the assets it contains.

(Not to be confused with less reputable start-ups sometimes claiming to "burn" ETH as part of a "sacrifice" but are using the term incorrectly in failing to reference destruction of ETH and are actually having what they claim to be "sacrificed" or "burned" to mean donations going to an account to be used to develop their project.)

Shorter Explanation by Way of Analogy

In an oversimplified sense, the private keys to the address 0x0000000000000000000000000000000000000000 AKA the null address,would be the equivalent to finding the solution for a mathematical equation involving a number being divided by zero. or

find the value of 'y' for any given value of 'a'
a / 0 = y, a ≠ 0 ('a' cannot be equal to zero)

or another way said, "If 'a' is not equal to zero, what are the possible values of 'y' when 'a' is divided by zero?"

To attempted the example above, if 'a' was equal to 6, you would have 6 / 0 = y, which requires a value to be found for the unknown quantity in y x 0 = 6

Analogy-wise, the ETH address would be the given value for 'a' (what we know) and the private key would be 'y' (a private key that could hypothetically be found). Even when you can use any number for a (assuming it's not zero but arguably even zero can't be divided by zero) would still be undefined when trying to find 'y' because no number multiplied by zero can equal that number.

In case the point was missed

• In cryptography, you have a keypair: the public and private key.
• You can derive a public key from the private key, but not the private key from a public key.
• The wallet address “acts” like the public key, but it’s not actually the public key.
• The public key is derived from the private key and is 128 hex characters
• The Private key is derived from the seed or user input, since the null address isn't an address created in this way, there isn't anything to suggest that there is a private key to begin with,

In hypothetically pretending that it was, it still stands that the address would've had to have been made using a 2-key pair. Regardless of the fact that hexadecimal is comprised of numbers 0 through 9 and A through F with private keys being 256-bit keys, when applying the hash function that would've hypothetically created the zero address, would've required the hashing to arrive at an end result that ultimately ended in a result containing at least 40 zeros but conceptually speaking, otherwise necessarily understood as a zero value. Since the hashing algorithm wouldn't be flawed to have some equation to end in zero and thus defeat the purpose of the encryption achieved by hashing, it would not be logically sound to presume that if a key hypothetically existed, it could exist within the other remaining confines of the real world and would demand that an additional hypothetical qualifier existed hence my point all along in saying it's more of a hypothetical no than a hypothetical yes.