Hacker News Reader

Comment by BatteryMountain | Hacker News Reader

It truly is laughable. Ever heard of "Return to Sender" in case of invalid events/transactions?

YES. Weren't these supposed to be SMART contracts? My email provider is smarter than that.

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.

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.

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

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.

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

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.

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.

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 john@example.com 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.

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.

> 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?

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.

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.

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

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?

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.

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.

"Smart contracts" was always a really bad name for this functionality.

What a joke.

Every self-denominated SMART thing that I know of is DUMBER than the conventional thing.

A better term would be dumb contracts.

Yeah. Even in the original bitcoind API you would run a validation call on the address and the spend before actually committing it. Afaik you couldn't accidentally send coins into a black hole even if you tried.

I think the address was valid, the problem is that there is no way of getting the coins out of it.

The same thing was done on the bitcoin chain, e.g. counterparty[0] was relying on a "proof of burn" which was basically "Send BTC to a black hole".

[0] https://counterparty.io/docs/faq-xcp/

If no one ever moved coins out of their burn addresses I'll eat my socks.

Uh, do you really like socks that much? I think this is something very easy to verify, just look at the burn address on the chain?

Just monitor this address then and let me know if anyone moves anything out of it :) https://etherscan.io/address/0x00000000000000000000000000000...

The thing is that is not an invalid transaction. The problem is in what happens _after_ the smart contract has received the money.

As far as Ethereum is concerned it's valid, but the contract API is riding on top of Ethereum's blockchain. It's middleware. It's responsible for enforcing the contract. How does it have a giant black hole in it?

It's the same as you and I agreeing on a contract where it says when you send me money, I will burn it. If you then use a bank transfer to me, it's not the bank's fault your money is gone, we agreed on that contract and it's not the bank's business to deal with that. Doesn't mean that there shouldn't be safeguards, there absolutely should be, but just laying out where the responsibilities start and stop and the whole deal with crypto currency is the absence of central control so if you choose to shoot yourself in the foot, you're free to do so. But freedom of action doesn't mean freedom of consequences and in the case of a blockchain, it's forever.

> it's not the bank's fault your money is gone, we agreed on that contract and it's not the bank's business to deal with that.

There's a reason some contracts (in the regular legal world) are illegal.

Reply on news.ycombinator.com