Return to Answer

Contracts can't be deployed to an arbitrary user specified address.

New contracts are created by the CREATE opcode in the EVM which implements the rules and doesn't have a parameter for the address of the new contract.

Probably the main reason for this behavior is to avoid conflicts between addresses. Someone should not be able to overwrite a contract that's already deployed at an address: quite a few user experience and security issues about this. (In reality, there's an extremely small probability, just like hash collisions, that two accounts would end up creating a contract at the same address.)

There's other reasons. For example, if people could deploy contracts to specific "unused" addresses, everyone may go for easy to read addresses, attackers could go for addresses that look similar to such addresses. And users allocating contracts to addresses may be able to unbalance the underlying data structures in Ethereum both accidentally or maliciously (similar to this "storage attack" which is mitigated).

Contracts can't be deployed to an arbitrary user specified address.

New contracts are created by the CREATE opcode in the EVM which implements the rules and doesn't have a parameter for the address of the new contract.

Probably the main reason for this behavior is to avoid conflicts between addresses. Someone should not be able to overwrite a contract that's already deployed at an address: quite a few user experience and security issues about this. (In reality, there's an extremely small probability, just like hash collisions, that two accounts would end up creating a contract at the same address.)

There's other reasons. For example, if people could deploy contracts to specific "unused" addresses, everyone may go for easy to read addresses, attackers could go for addresses that look similar to such addresses. And users allocating contracts to addresses may be able to unbalance the underlying data structures in Ethereum both accidentally or maliciously (similar to this "storage attack" which is mitigated).

Contracts can't be deployed to an arbitrary user specified address.

New contracts are created by the CREATE opcode in the EVM which implements the rules and doesn't have a parameter for the address of the new contract.

Probably the main reason for this behavior is to avoid conflicts between addresses. Someone should not be able to overwrite a contract that's already deployed at an address: quite a few user experience and security issues about this. In reality, there's an extremely small probability, just like hash collisions, that two accounts would end up creating a contract at the same address.

Contracts can't be deployed to an arbitrary user specified address.

New contracts are created by the CREATE opcode in the EVM which implements the rules and doesn't have a parameter for the address of the new contract.

Probably the main reason for this behavior is to avoid conflicts between addresses. Someone should not be able to overwrite a contract that's already deployed at an address: quite a few user experience and security issues about this. (In reality, there's an extremely small probability, just like hash collisions, that two accounts would end up creating a contract at the same address.)

There's other reasons. For example, if people could deploy contracts to specific "unused" addresses, everyone may go for easy to read addresses, attackers could go for addresses that look similar to such addresses. And users allocating contracts to addresses may be able to unbalance the underlying data structures in Ethereum both accidentally or maliciously (similar to this "storage attack" which is mitigated).

Contracts can't be deployed to an arbitrary user specified address.

New contracts are created by the CREATE opcode in the EVM which implements the rules and doesn't have a parameter for the address of the new contract.

Some reasons why this is the behavior:

Contracts can't be deployed to an arbitrary user specified address.

New contracts are created by the CREATE opcode in the EVM which implements the rules and doesn't have a parameter for the address of the new contract.

Probably the main reason for this behavior is to avoid conflicts between addresses. Someone should not be able to overwrite a contract that's already deployed at an address: quite a few user experience and security issues about this. In reality, there's an extremely small probability, just like hash collisions, that two accounts would end up creating a contract at the same address.