0

I am reading the Ethereum white paper and needed clarity on the snippet below:

Transfer the transaction value from the sender's account to the receiving account. If the receiving account does not yet exist, create it. If the receiving account is a contract, run the contract's code either to completion or until the execution runs out of gas.

  • Does this mean that if you send a message / transaction to an address that doesnt exist, it the call would succeed?
  • How does the key management work?
  • Is there any use case that would intentionally do this?
  • What is the rationale behind this design decision, because I would have thought throwing an error would have been the way to go.
1

Sending a transaction to a random address is equiavalent to 'burning' or 'destroying' the tokens.

This is actually something that is already commonly done with the all '0' address, and 0x000000000000000000000000000000000000dEaD.

Take a read here: Transaction recipient - Mastering Ethereum

Ethereum does no further validation of this field. Any 20-byte value is considered valid. If the 20-byte value corresponds to an address without a corresponding private key, or without a corresponding contract, the transaction is still valid. Ethereum has no way of knowing whether an address was correctly derived from a public key (and therefore from a private key).

WARNING: Ethereum cannot and does not validate recipient addresses in a
transaction. You can send to an address that has no corresponding
private key or contract, thereby "burning" the ether, rendering it
forever unspendable. Validation should be done at the user interface
level.

Sending a transaction to an invalid address will burn the ether sent, rendering it forever inaccessible (unspendable), since no signature can be generated to spend it. It is assumed that validation of the address happens at the user interface level (see [eip-55] or [icap]). In fact, there are a number of valid reasons for burning ether, including as a game-theory disincentive to cheating in payment channels and other smart contracts.

  • 1
    Note that there's a difference between "random" addresses (presumably defined as ones for which you don't know the private key) and just funding a "new" account. Burning tokens is a use case for the former, but not the (much more common) latter. – user19510 Jul 9 '18 at 20:03
1

Does this mean that if you send a message / transaction to an address that doesnt exist, it the call would succeed?

Yes.

How does the key management work?

I'm not sure I understand the question. For Ethereum accounts, a private key is randomly generated, a public key is derived from that, and then an address is derived from that. If you have the private key corresponding to an address, you can send transactions from it.

Is there any use case that would intentionally do this?

Sure. If you generate a new account (new private key), you then need to fund the account somehow. You do that by sending ether to it. The account doesn't "exist" yet in any persisted form in the blockchain, because it doesn't have a balance yet. So it's "created" when you first send ether to it.

What is the rationale behind this design decision, because I would have thought throwing an error would have been the way to go.

Throwing an error would make it impossible to start using a new account.

  • Thanks for this!! the answer although its a good answer, the other reply explains it better – Samuel Dare Jul 9 '18 at 19:58
0

What this is describing is what the Ethereum virtual machine should do when a transaction is executed.

By default, every address has 0 ether. This means the state of all Ethereum addresses can conveniently be represented as 0... unless it's been involved in a transaction (in which case, it's a little more involved). That's what the "create it" refers to. So, yes, that means there cannot be an error in that case (that is, the call would succeed, unless you run out of gas).

Not sure what you mean by "key management". It is unlikely that anyone has keys for a random address (thus, nothing to manage). Any ether in that account is inaccessible until someone generates a corresponding private key. But if someone already has a set of private keys and shares an account address, the account, as far as Ethereum is concerned, does not actually exist in the practical sense (i.e., is not created) until you send any ether there.

Sending ether to a random address can be used as a proof-of-burn (like burning some physical currency to make it unusable). This can be done for reasons like being a penalty for doing a bad action (as part of a smart contract), though there are better ways of performing proof-of-burn. One could also use proof-of-burn is to pay for something without having an explicit payee. For example, I could require that anyone sending me an e-mail burn some ether. That way, I can show I don't really gain anything by having people e-mail (all remaining ether's value rises slightly due to decreased supply and an increased demand for ether to pay for burning) and a spammer's costs have gone up when trying to send millions of messages.

One reason why the behaviour of accepting all addresses is important is because otherwise, someone could spam the network and say "create this account" and "create that account" at no cost (at least in terms of ether). And since it costs Ethereum node resources to track which accounts exist, this could be an attack on the network. Instead, one has to actually send ether requiring a) some ether to send and b) a transaction fee (or, alternately, mining power to perform the transaction oneself).

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.