[oefrha]

I’m sure you’ve heard of it, but in case you haven’t, it’s called bouncing when there’s no valid inbox on the other end. Before you object, yes, you can set up a catch-all incinerator, but that’s not the default as is the case here, you have to explicitly set it up.

[capableweb]

"Bouncing" can happen in cryptocurrency world as well, it's called "sending to an invalid address". It just happens to be that the address-space is so big you don't really know what address has a real physical person behind it or not, or yet even.

Try sending cryptocurrency to an invalid address and you'll see that the wallet will reject sending it, just like email bouncing.

[oefrha]

Most people setting up mailservers don’t consider a catch-all forwarding to /dev/null a valid inbox. And no sane mailserver software forwards to /dev/null by default if you don’t explicitly tell it what to do when it receives email it isn’t supposed to receive.

A “valid” address locking up funds sent to it without recourse is /dev/null.

[capableweb]

Hm, in order to clear up some (seemingly) confusion about how things work, let me offer you this explanation:

The user in the submission did not send funds to a invalid address. The address is valid, as otherwise funds wouldn't be able to be sent to it (the wallet would not allow you, nor the protocol, nor the miner/validators). The address happens to belong to a contract, that can also hold funds, similarly to accounts.

Now, every address/account/contract has a private-key behind it, that allows the owner of the private-key to transfer out of the address/account/contract, but it's impossible to know if the owner actually still has the private-key.

Similarly to how you can't know if [e-mail] actually has access to his email account (maybe he forgot his password?), you can't know if an address actually has the possibility of moving the funds out of the address, as the private-key can have been thrown/forgotten/lost.

[oefrha]

I’ve made myself abundantly clear that WETH or whatever smart contract shouldn’t blackhole money by default when there’s no handler code, just like mailserver software shouldn’t blackhole emails by default. This is not a case of John making a mistake of forgetting their password, it’s ridiculous fallback behavior with unconsidered edge cases (or maybe considered but intentionally unhandled due to stupidly expensive compute). The design is atrocious and apparently it’s the default for all smart contracts.

The stakes are a little bit higher when you’re sending money instead of emails.

[noduerme]

This is the right way. Default behavior for any box should be to bounce. I forward all my wrong mail to a black hole but that's because I'm not a fucking smart contract

[capableweb]

Again, if you try to send funds to an invalid address on Ethereum, you won't be able to. First the wallet will stop you if the address is invalid, secondly no miner/validator would pick it up from the mempool if the address is invalid and thirdly, no other party would agree that the address is valid and hence the transfer wouldn't go through.

Simply said: you cannot send funds to invalid addresses on Ethereum.

[NateEag]

But you can send funds to an address the funds cannot be retrieved from.

A protocol could conceivably require the recipient to verify they're holding the private key for the address before the transaction can take place.

Yet here we are.