[capableweb]

First time I hear about IMAP/POP3 provider being able to "undo" emails after being sent. What provider are you using and how does that work behind the scenes? And no, gmails fake "we don't actually send it until you close the tab/wait 30 seconds so you can undo it" doesn't count.

[BatteryMountain]

Really? If a mail server (and the post office of most countries) don't have the specified address, it either gets sent back if there is a return address written (email non-delivery notice (aka return to sender, NOT undo) or it goes into a catch all bin (same as a lost & found)(or root account for most mail servers)(or dump it in the bin).

[capableweb]

Yes yes, as mentioned in another sibling comment, your wallet won't allow you to send anything to an invalid address. In this case, the address was not invalid, so why expect it to get rejected?

[BatteryMountain]

So imagine the bank give all objects in their company an address. The desk has an address, the fridge has an address and so on. Bank accounts have an address too. All these addresses look the same and use the same system to interact with them. The problem is that Johnny wanted to deposit $50 dollar into his account, but he accidentally used the wrong address, and now the fridge in the the bank's kitchen on the 5th floor now owns $50. To his dismay, there is nobody to send his funds back since no human owns the fridge and nobody is even able to break the fridge open to get it out. Don't blame the fridge they say, don't blame the bank they say, don't blame the currency or the address system or the person who made the rules so that fridge addresses and bank account addresses work the same. No, lets blame Johnny, the dumb ignorant fool who doesn't understand the glory of the banks special addressing system. It is working as intended. He should've known better, he should've read the docs etc. Fuck Johnny and his $50.

[p49k]

You’re using a different definition of the word invalid.

Obviously the person you replied to meant invalid in the sense of “not intended to receive funds”

It would have been a competent design decision for a system to require some type of initial registration of intent to receive funds for an address in order for a transaction to post.

[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.

[oblio]

> And no, gmails fake "we don't actually send it until you close the tab/wait 30 seconds so you can undo it" doesn't count.

Why doesn't it count and why does it matter how Gmail works behind the scenes?

[capableweb]

Because that feature of gmail is not a part of email, it's a part of gmail the product. And it is not "undoing" sending a sent email, it's cancelling an email that was never sent in the first place.

[ipaddr]

Because email doesn't work that way. Gmail doesn't send the email for a minute. It would be like your boss asking you to send this email and you wait a minute for him to change his mind before you presses send.