There is a hidden feature in Ethereum you probably haven’t heard of.

As a short recap, there are two kinds of addresses in Ethereum:

external accounts — accounts you can create yourself and make transactions with

contracts — smart contracts deployed on the blockchain

Once a contract is deployed, it can receive and send the cryptofuel Ether.

Wait a second, does it need to be deployed to receive?

When you create an external account does it need to be registered somewhere? Do you need to make a transaction first in order to receive transactions? Does it need to exist according to the blockchain first?

No, no and no. You only need to possess the private key and as long as a value is recorded against your address in the blockchain state, you can initiate transactions. Let’s call these addresses undiscovered.

Why would it be any different with contracts? It isn’t.

But how? I do not have a private key for a contract!

There are no private keys for contracts, but generating a contract address is deterministic. It is a hash based on the creator address (your external account for example) and the nonce of that address. The nonce is the transaction counter of an address. It increases by one for every transaction.

As an example the address 0x54f84fea31bedf6c60e42a3fca529a74147dd443 has a nonce of 0. If it were to create a contract, the resulting address would be 0x7dc9b1b4503bf29773038fbccb53b52d2affbf56.

Interesting stuff, but I assumed contract creation starts from an empty state?

It does with one exception: keeping the account balance. (For a proper description see Chapter 7 of the Yellow Paper.)

There you go. There is a way knowing what your contract address will be and there is nothing stopping transactions from being made to an undiscovered address.

As mentioned here, the Ethereum Foundation’s wallet was deployed the same way. The genesis configuration contained the balances for all the initial addresses — mostly those who have funded the development by buying in the pre-sale. Once the blockchain was bootstrapped, the contract could be deployed.

This is very clever. Does it come without any risks attached?

It has a slight risk if you read the Yellow Paper thoroughly. Any time a contract is deployed, the resulting address’ state is reset to blank (with the exception of keeping the balance intact). Even if your contract exists, it can be overwritten and as far as I know there is no rollback defined.

But how can someone generate the same address? It won’t happen with the same source account, but it is possible a different account and nonce combination could result in the same address — with very low probability though.

To do this with a malicious intent, one would need to iterate a lot of address and nonce combinations, where the nonce realistically wouldn’t be a large number. The goal is to create a hash collision in the lower 160 bits of SHA3. It is a brute force task.

What do you think — is this a useful feature or a miniscule security risk?

My personal opinion: I wouldn’t suggest using this method.