Ha, that was a stressful yet funny read. The self flagellation bit hits too close to home though. I run a somewhat successful iOS/MacOS app and pushed a release that completely broke about 350k+ installations. Not entirely my fault but doesn't matter as it's my product.
The cold sweats and shame I felt, man... Plus it's on the App Store so there's the review process to deal with which extends the timeline for a fix. Thankfully, they picked it up for review 30 minutes after submission and approved it in a few minutes.
My first employer as a developer, due to their incompetence, not intelligence, ‘let’ me break our customers’ shit from a young age. As I’ve progressed through my career, and through my transition to leadership, I’ve realised that it was a very valuable experience. I may have stressed about it in the past, but those memories are too distant for me to even reach now. I certainly don’t stress about it now.
I’ll, maybe controversially, sometimes allow my (early-career) team members to break prod, if I can see it happening ahead of time, but am confident that we’ll be able to recover quickly. It’s common knowledge that being given room to fail is important. But many leaders draw the line at failures that actually hit customers. If one finds oneself in the very common and very fortunate position to be building software that isn’t in charge of landing planes or anything similarly important, they should definitely let their team experience prod failures, even if it’s at the expense of so-and-so from Spokane Washington not being able to use their product for a few minutes.
Within my first 6 months at a FAANG, I accidentally took down our service for half the world for 30-60 minutes.
That was honestly one of the best things that could’ve happened to me and I still use the story for new hires to this day. It’s a very humbling reminder that nobody is perfect and we all make mistakes. And I’m still here, so it’s never the end of the world.
If I were a betting man, I'd probably say either a pocket typing sort of situation (for the latter two) or a kid or animal gallivanting on/around the keyboard for the first.
Etymologically, Deepavali is a Sanskrit word meaning row of lamps (Deepa means lamp). Diwali is a colloquial form used in Northern states of India, as the word in their language for a lamp is Diva/Diwa.
Ultimately, there’s no difference as every Indian state has its own language so it’s all nitpicking. Because I’m a bum, I like to point out that South Indian (where I’m from) and East Indian states use the etymologically correct name, Deepavali.
It could also tell us customers a bit about what kind of impact to expect from this. Content -wise if it's buyers. Or reliability wise if it's tech people.
There were claims that the last round significantly impacted folks working on some critical intersectional across race / ethnicity / gender identity type programming.
There were some articles about the layoffs last time and the major backlash that resulted. Protocol covered this, noting "Protocol identified at least 40 people from marginalized backgrounds who lost their jobs in the latest round of cuts."
Interestingly, as I read this Meta announcement a settlement on similar discrimination claims:
"Discrimination in housing, employment and credit is a deep-rooted problem with a long history in the US, and we are committed to broadening opportunities for marginalized communities in these spaces and others," Roy Austin Jr., Meta's vice president of civil rights, wrote in a blog post.
It was people working for marketing related to gender- and race-based programming that Netflix also mostly dropped in the past year when it decided to shift from targeting niche audiences to going for the pure-blockbuster play (i.e., from Babysitters Club to Squid Game).
I took a look at netflix's top 20 or so shows on their feed. Pretty eye opening in terms of what is getting watched, even down out of the top 10 or so.
This is the truth OP is burying their head in the sand to avoid.
Everyone is indispensable until they aren't.
Every business is profitable until they aren't.
And these days, with the insane expenses and revolving credit businesses all rely on, damn near any business can end up insolvent in the blink of an eye.
In case you’re wondering what happened, from the thread:
He sent ETH to the WETH contract, received WETH as expected.
Then he wanted to do the reverse and sent WETH, but will not receive anything, because you're supposed to swap your WETH to ETH in exchanges like Uniswap, or call the "withdraw" function in the contract.
For contracts that want to only work with ERC-20 tokens, you use WETH, which comes from a contract that takes 1 eth and gives you 1 WETH.
A known problem with ERC-20 tokens is that transferring them to a contract that isn't made to access them is equivalent to burning them. You should almost never transfer ERC-20 to a smart contract. You instead use approve to give the smart contract permission to withdraw, then call the function you want to receive and tell it to make the withdraw (the contract will internally call transferFrom).
Wait. I'm not letting anyone off the hook for not knowing the above if they put $5 into something, let alone $500k. But even as a coder and someone who was deeply involved in crypto at one point (2011) I find it hard to make heads or tails of wtf this means. All I hear are a lot of acronyms and bizarre edge cases upon edge cases. It sounds like those arguments you'd hear between kids in junior high over magic cards or pogs or something. If this is the level of magical knowledge required to deal with these tokens, it sure seems like a sucker's market.
I think this is a symptom of the general problem of calling everything "cryptocurrency", which anchors people on the mental model of Bitcoin. You were involved in "cryptocurrency" 2011 when everything was Bitcoin or essentially just a fork of Bitcoin and all of the stuff in the comment you replied to was a few years away from existing.
I think it would be like writing "applications" in the early 90s in Visual Basic and then reading something about web applications and saying "I was involved in applications and none of this makes sense to me". That's because it's a different domain, with some similarities but many differences.
Edit: Changed "crypto" to "cryptocurrency" to differentiate from a different general problem with how the shorthand already had a different meaning.
Right you are. I just edited to differentiate from this other general problem with the nomenclature in the space.
I actually think this one leads to less confusion though, because the people who are familiar with "crypto" vis cryptography universally have enough expertise to differentiate it from "crypto" vis cryptocurrency. Whereas I would estimate that at least 99% of people who have heard of both Bitcoin and Ethereum have no idea that there are important differences in their capabilities and technology.
All the smart but non-technical people I know or read commentary from talk about cryptocurrency as a single thing, where that thing is just different flavors of Bitcoin.
The next time I get cornered by a coinhead - a worryingly common occurrence in real life lately - I'm going to say "Oh, I love crypto! My bank uses it so I can access my account from anywhere. It's great!"
It goes to show that cryptomoney has not yet a settled common set of words to describe what's happening, unlike applications which have "gui, compilers, loop, trees, objects, etc.".
It's still to much specialized to follow what's going on from a higher viewpoint.
I don't think so. The terminology is quite standardised, but just like "gui, compilers, loop, trees, objects, etc." you're not going to know them unless you're familiar with the subject.
Is it really? From what I can tell these are all Etherium-specific terms. This is not standardized. It might be consistent but that’s not at all the same as actually being standardized.
This seems like saying that Chef terminology is standard. It might be internally consistent with its talk of recipes and ingredients and whatnot for imaging machines. But this terminology is not standard because it’s meaningless to someone who had experience with a different imaging platform.
Yes, it really is pretty standard and straight forward. The ONLY problem is that its popularity has skyrocketed so there are A LOT of people talking about it who have no technical understanding. Parent comment above is a perfect example, complaining because in 10 years the tech has evolved.
I think you're both right to a degree. I agree the jargon is pretty well defined at this point, but it certainly is not as widely understood as the earlier computing and internet jargon. I think the mainstream is in the phase of basically having no idea whatsoever. I am sympathetic to them. I think they feel chuffed with themselves for finally figuring out what Bitcoin is, and now we're telling them they're still over half a decade behind the curve?!
In simple words, he should have called a smart contract's function which would withdraw his tokens and send real ETH to his address. Instead, he sent tokens to smart contract's address and they will stay there forever, not associated with any account.
This complexity should be abstracted away by wallet's UI. Users don't have to call APIs directly.
Also, this whole situation could be prevented by trying to send a smaller amount first.
I've written middleware APIs for accepting currency in carts and casinos that interfaced with / polled bitcoind and other daemons. Why on earth would this person be calling APIs directly, and why would the daemon not just reject the transaction if it's an unexpected kind of token? Or if he added funds to the contract why not be able to remove them to the same address? I never dealt with smart contracts but even allowing this to happen without an error seems like a crazy, terrible design.
from the reddit comments, similar question, apparently every instruction adds gas fees to running the contract, so if you're going to use the contract a lot, you leave out any kind of validation.
>> Wow why didn't the contract creators think this through and block requests to the contract
> Because adding that check would increase the cost of every user transaction. All AMM swaps would be done with WETH so it’s the right call to not have it in there
There are, of course, other industries with financial incentives against safety features. We usually regulate them.
We can point and laugh at this one person, but according to the reddit thread they're the 265th person to make this mistake, and more than half of the money in the inaccessible account is not theirs.
And that's just for this particular token. You can go to just about any token contract and see how numerous people have sent their tokens to the contract address itself.
I hadn't even thought about this. With BTC early on, the only party to really benefit from lost coins would be "Satoshi", but his coins weren't worth anything until the currency took off anyway, so it was more important and long-term profitable to build a system that didn't lead to user anger than one that would lose coins to deflate what was already a deflationary currency. It really does show how slimy the whole cryptocurrency world has become.
I really can't think of an expression other then "lol" to sum up my response here for just how incredibly stupid this is, as a "platform of the future".
A design which actively discourages robust programming and error handling in financial software. Wow.
Ok… but then if you’re going to throw out these cases you should also address how markets can fix these issues, such as great customer service: “when I fucked up they helped me out, they’ll get more of my business”, or maybe insurance, or just better products that don’t have these issues.
Idk why people conflate libertarianism with this hyper-individualist stuff. It really isn’t the case.
Why should this person get anything back? Code is law. And if code is law all bugs are also law.
The half million was a fair and just transfer. Whoever is the recipient is fully deserving both morally and ethically of their new-found wealth.
If I was on the receiving end of this transaction, I’d thank the sender for the money and move on with my life. Of course I’d never be in the position to receive the funds because I’m not stupid enough to play this game—odds are very good I would be the one who sent half a million dollars by mistake!
I mean, I think I’m joking but not really. If you want to practice “code is law” and really mean it, this is the kinds of stuff that will happen.
The one who has the private keys to that account could give them the ETH back, yeah. But if no one has the private keys, they can not get it back, that would defeat the entire point of cryptocurrencies in the first place.
There are two types of accounts in Ethereum, externally owned accounts (EOA) and contracts. EOA are controlled by private keys where contracts are not. Since the user sent ETH to a contract, he cannot get his ETH back if the contract does not have a method to transfer ETH back. Whereas if he sent ETH to an EOA then the user of that account can send him back ETH.
But of course they can - if they are the right persons, that is. (See DAO hack. Of course, that did defeat the whole purpose of smart contracts but nobody was willing to notice.)
> See DAO hack. Of course, that did defeat the whole purpose of smart contracts but nobody was willing to notice
Of course a lot of people noticed. The problem is that cryptocurrencies are currently primarily functioning as investment object rather than an actual secure financial ledger, which is why the interest of investors will trump purity.
Low-cost insurance is an interesting idea that might actually work to smooth over some of the hard edges of "code is law".
It ought to be possible to craft an insurance policy that would pay out the $500k (or equivalent WETH/ETH) in cases like the one in this article, where the transparency of the ledger clearly shows that the tokens are unrecoverable.
As insurance companies are notorious for declining to pay out, the clear evidence trail would be helpful to allow the insuree to take the claim to a regular court for a human decision on its validity.
Not really. Having the option of a lawsuit is just a backup; the possibility is what makes sure the insurer chooses to pay without one.
An insurer that knows when it doesn't have a case and will be forced to pay (plus costs) when there's clear evidence of coverage and loss will almost always pay without a fight.
However if there are high-value decisions which are not so clear cut, then having the option to go to court or some other mediation system to settle is quite useful. One of the critisms of "code is law" is the lack of mechanism for nuanced, human intervention when something unexpected happens due to a bug, design flaw or unexpected consequence that turns out to be unreasonable.
Code can screw up at scale. And at this point if you’re capable enough to understand the edge cases and offer insurance against them, the insurance went really cover that much.
Markets don't care and they will not fix these issues, because suckers losing money is a much better market proposition than losing money on customer support.
Fo go ahead and learn some history, will you? Almost every single regulation we have in place is precisely because markets never ever fix things.
And yet, disputing charges via your bank and issuing chargebacks via VISA/Mastercard are things that definitely exist and work perfectly fine. And as long as there is no equivalent function in crypto, it won't be suitable as a currency for general use.
And no amount of mocking faux laughter will change that.
Cash transactions are done locally when you can typically inspect the object of the transaction before paying. That's why there is not the same need for these kinds of protection.
Crypto combines the worst properties of cash and wire payment into a package that has no customer protection and is almost tailor made for scammers.
There are customer protections in the form of 1) escrow 2) seller reputation 3) seller depositing some risk capital at a selling platform. That said, customer protections have never really worked for me in fiat world.
That is not entirely true. Stock exchanges will reverse some clearly erroneous trades, even when they are not required to by law, because people trade more when they feel protected against mistakes.
There are plenty of do-overs, it's called the "development phase" and involves testing things on your local computer with the team.
No one gets everything right the first time, but with a lot of testing, you can actually write software that does exactly what you think it will do, and you can achieve pretty cool stuff. Remember that humans wrote the software that took humanity to the moon!
As we know, no software has had bugs caught once launched to prod. The existence of some software that worked under this model is not evidence that it is a good model. "Just test prior to release" is not a complete solution.
Are you talking about the user from https://www.reddit.com/r/ethereum/comments/sfz4kw/did_i_just... ? And do you mean "read-only memory"? I'm not sure how that's relevant. The contract they made the transfer to is read-only yes, like any contract on Ethereum. But they could have tested the contract call with a smaller sum before actually performing the bigger one.
Just like the people writing the computer that took us to the moon, I'm pretty sure they tried it before in small-scale simulations before hooking it up to the rocket and letting it go to the moon.
The idea that people need to treat financial transactions in crypto as if they were writing software for a moon mission shows how impractical the entire space is.
If that was the case, I'd agree with you. But as outlined in the comments of this submission time and time again, it was not what happened here.
The user was not doing a normal transfer (at least, they didn't want to, but they ended up doing). They didn't know what they were doing at all, a simply Google search would have showed them the way. Using UIs instead of interacting with the contract directly would have prevented them from making the mistake they did. Doing a small test transfer before doing the big one would have revealed what was wrong as well.
It's not that I'm comparing writing software for moon missions with making cryptocurrency transactions. I was directly replying to mox1 implying that writing 100% correct code is impossible and shouldn't be attempted.
Yeah, because NASA has been utterly fucked by the congress. Because of politics it's better for NASA to spend 5x the money on 1 reliable spacecraft than to build 5 slightly less reliable spacecraft out of which only 1 fails.
Even if the economics of it don't make sense, NASA can't afford to be seen failing because because politicians will not want to fund them.
I guess my point is that NASA is an exceptionally badly managed entity, not something you'd want to aspire to. (Of course the people working at NASA are not the ones to blame for this.)
>Money matters a lot. Should this mess endure, people will forever be saying a little bit of gas would have been worth it.
That gas would probably add up to more money than has been lost here.
>And we've people with six figure arguments as to why such a check makes sense.
The gas fees of such a check would probably be higher than the losses averted, especially in the long run. And any "losses" are essentially distributed among all ETH holders anyway.
"The gas fees of such a check would probably be higher than the losses averted, especially in the long run. And any "losses" are essentially distributed among all ETH holders anyway. "
Of course not. There will be more advanced software for expert users that allows them to manually create potentially riskier transactions. That's perfectly fine.
Client software targeting end-users should have such checks.
This really doesn't line up with the reality of how most people are congregating around user friendly wallet software and steering away from the more advanced options.
You only one need one wallet software to be the official WETH-approved client, sucks for anyone else risking their money with unsupported software.
We shall see. And for me, safely and at a distance.
Frankly, the small cost of robustness in contracts should have been factored in from the beginning. It just does not need to be so damn lean and rickety.
The incentives are wrong here.
My prediction is the current state of affairs all gets ripped up and replaced after a time. And until that happens, we are likely to see activity largely limited to people who have a healthy appetite for risk.
Perhaps it all is as it should be too. Had the reverse been done, emphasis on slightly more expensive contracts that are robust and able to deny the costly errors, I would imagine others clamoring for people to adopt the rock bottom lean stacks...
There are 0 do-overs on smart contracts in production. No stopping the network for a minute to triage, no rolling back a minute, no circuit breakers. No "Error 1202, do you want to continue?" pop-up messages.
Back in the day or at least when I ran my own bitcoin node, any call against the blockchain was free. This sounds like someone charging for hitting the API on a rented node, as opposed to an actual cost imposed by the currency to consult the blockchain (?) But maybe the contract-generators aren't even running their own node, just piggybacking on someone else's API. Sure. Cheaper.
AFAIU, smart contracts on the ethereum VM can be arbitrarily complex, so you pay the network to execute them, or a random user with an infinite loop would bring down the network.
You are indeed renting a machine to run some code, and if you want many people to use your code you want to make it cheap. There's a trade off.
You can fuck up things on the BTC blockchain too, "burning" crypto by sending it to a dead address has been a thing for a long time.
It always seemed stupid to me that it was possible, compared to sending money to an invalid IBAN, but I'm not a crypto enthusiast so I may be biased.
On BTC, you could send things to the wrong address, yes. But you can't send the wrong type of currency or send it to a nonexistent address. In this case it seems like the contract has created the black hole (not the Ethereum blockchain itself), but that's even more absurd since someone ultimately should have control over everything that was put into the contract, regardless of the source.
Sending currency to non-existant addresses is how people encode arbitary data on the bitcoin blockchain, so definitely possible.
Giving a person control over the funds allocated to their smart contract probably opens holes where they can steal the smart contract's money, though obviously creating software that handles money and can't be updated is its own kettle of fish.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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 was a really bad design decision to have smart contracts have this "send to the address" capability, rather than requiring clients call a method that is explicitly defined.
> he sent tokens to smart contract's address and they will stay there forever, not associated with any account.
Wait... so the tokens are really still there, just inaccessible? In what way do the tokens still exist? What makes them inaccessible? Is there really no possibility of restoring the tokens? No possibility of cleverly hacking them out with the assumed myriad of unpublished security flaws?
The tokens are a number in a hash-map of user to balance in the weth program. Any eth program ("smart contract") can be a user. All the smart contract that owns the tokens has to do is tell the weth smart contract to transfer them, or approve mister redditor to transfer them on the contract's behalf. But that contract wasn't built to do such a thing. And now that it's published, it also can't be updated to do such a thing. A new contract could be uploaded, but that new contract won't be the same user. So they're just gone for good. Hope that cleared things up.
So, could the Ethereum community get together and agree to rewrite the blockchain and undo this transaction? Perhaps they could vote on it and have a hearing of the facts. Of course that introduces its own tyranny but is it possible?
It is possible. That's why you have Ethereum and Ethereum Classic, two different chains. The latter one is the unaltered chain, while Ethereum (which is the most popular that's everybody are using) has been forked in such a way that you're describing once after a large hack.
Specifically, it forked because even though the system is specifically designed to make rewriting history impossible, the hackers screwed so many users that they decided to undo it by ignoring history and starting from before the hack.
... Lest anyone ever think Blockchain tech is somehow immune to network effects and social considerations.
Technically, rather than ignoring history and starting from before the hack, they added a nonstandard transaction (not generally allowed) which reversed the effects of the hack.
This did not revert other transactions that happened after the hack.
But, yes, blockchain stuff is fundamentally based on consensus about what the rules are, and people/organizations with more social influence can [...] .
The chain is by nature append only, so you'd have to fork it, which they sure as hell are not going to do for a "little guy," to put it mildly. At least, that's my layman's understanding.
In simple words, he should have done what everyone else does and used Uniswap or Zapper or Sushi or ANY exchange and swapped WETH for ETH that way.
This is just a dumbass user doing dumbass things. This is basic-level stuff right here. Don't interact with contracts directly unless you 100% know what you're doing.
But people are allowed to interact with smart contracts. To obtain the WETH he needed to do that. This is a "why do we even have that lever" kind of situation. If my brokerage had a "permanently burn all of your money" button then it wouldn't be reasonable to just say "well, people shouldn't push that button."
We can even see this with the criticism of wire fraud. Wire fraud is a huge fucking mess that occasionally costs people their life savings. The entire setup is rightly criticized (heck, even by the crypto community) for having users interact with a highly error-prone system with huge consequences.
People are allowed to login as root and delete their systems too. Yes, today's software doesn't make it easy - and the same can be said about this wallet/token; this was a complex sequence of steps in the wrong direction, not a missclick.
And a lot of ink is spilled about systems to make this very difficult, with people continuing to work to improve things. We didn't simply say "well, just don't type those characters" and move on with our lives.
The set of people running a service with a revenue of 500k on a personal device must be minuscule and the people doing it almost certainly know it’s stupid.
This is qualitatively different from crypto that allows you to burn your money on accident, while the people who build the infrastructure for this tell you is a smart, safe place to put your money.
Interesting how your example has just completely changed.
But also, wiring money is a thing that laypeople almost never do. It’s nerve wracking to wire money. But the equivalent in cryptocurrency is just how it’s done. Every transaction is just a fuckup with no recourse waiting to happen.
What's so interesting? I already told you this wasn't a simple missclick. No need to reiterate.
You can dump money into a pit just as easy with the classic banking system. Where I live (EU), wiring money is the primary way of payments and money transfers. People don't use anything else.
> I already told you this wasn't a simple missclick.
Seems like it essentially was. He exchanged ETH for WETH in exactly the same way. Assuming that the reverse would work (as opposed to destroying the money) was not an unreasonable step. He still screwed up, but a design that allows this is user hostile and stupid.
> You can dump money into a pit just as easy with the classic banking system. Where I live (EU), wiring money…
In the US at least, you can get your money back through the legal system. Accidentally dropping your money into someone else’s account does not give them a right to it and for substantial amounts of money people can and do get their money back.
For this amount of money I’d consider pursuing legal avenues against the developers of Etherium. This design seems borderline negligent and Etherium has modified the code at least once already to force a refund.
Consumer wallet software gives you a warning that this is probably not what you want.
> In the US at least, you can get your money back through the legal system. Accidentally dropping your money into someone else’s account does not give them a right to it and for substantial amounts of money people can and do get their money back.
I doubt this is true in the case of uncooperative out-of-country second party - yeah they have no right to the money, but they don't care and the legal system won't do much for you.
If this guy didn't get a warning, they're using power-user software (likely CLI-based).
Of course one shitty design doesn't justify another, but the point is not justification but a reply to all the people saying "this is way worse than and would never happen with the traditional banking" that they are wrong. I agree that better UX is needed.
Regarding your point about legal action against Ethereum designers, well... That'd be like pursuing legal action against the designers of your web browser because it allows you to open phishing sites. Nonsense IMHO.
From what I can tell, the underlying issue is that everything is spaghetti code written in a dynamically typed language.
Ignoring that, it's nuts that the best practice is "send a little money, and see if it works". Apparently they don't even have a working transaction simulator that just runs the relevant logic on your laptop so you can see what it will do.
I think you can do test transaction off-chain, I think they're called test-nets and you can use them through many wallets, and even online IDE's[1]. Unfortunately, crypto is still at the stage where it's built for devs and technically minded individuals, and its pretty user hostile. Sending directly from wallet to wallet is a pretty low level thing to do, and generally people should be executing transactions through swaps or other DAPP's, which to me seems like we're working against the empowerment principle of crypto
Look at NFTs. The empowerment pricnciples are being actively killed by millions of VC dollars. Opensea are nominally recording transactions on a blockchain - but none of the actual meat. Everything 'real' lives inside their centralised system.
A LOT of people are doing it wrong but there are still good projects out there. The two that come to mind are Monero and Bitcoin Cash. Both still work as designed and have low fees and/or instant and/or anonymous transactions.
The underlying issue is that everyone wants to make money. And the quickest way to make money in crypto is to create a new coin, token, smart contract, NFT, web3, whatever. Thus ever increasing complexity.
> Ignoring that, it's nuts that the best practice is "send a little money, and see if it works".
That's what I did the first time I did a bank transfer between two of my banks accounts. Maybe that's just me being paranoid but when sending money I like to test it first.
I haven‘t tried it, because I don‘t do much crypto stuff at all, but I thought this specific functionality, to dry-run any scenario, from any account, was very intriguing.
Already done and it’s already processed more transactions than ethereum and bitcoin have in their entire history combined, as well as having more developers.
As much as I like rust and think this would help increase acceptance for many tech affine people, this issue was a bad design decision, which is even worse. I don't think I will touch anything crypto until I can trust that the system is designed well.
several of these projects will set up a local chain with presets to test exactly this. probably worth doing before sending large amounts to random contracts.
How can you be so naive about this topic yet confident enough to add your 2 cents? There are been test nets from day one and running one yourself is trivial.
Realistically if you just want to try out someone else's contract in a safe environment, the existence of the test nets is entirely irrelevant.
The contract is going to be at a different address, all the accounts involved are entirely different, the state of the contract is different. Even proving a contract at one address is the same as the contract at another address is non-trivial.
Pretending the existence of a test net proves anything is a lot like pretending the availability of source for your OS, compiler and dependency stack proves something. Maybe possibly for a professional with unlimited time, but that's it.
It's not really edge bases, it's how contracts works, and how this contract works.
There is nothing magical here. It's a bit like avoiding the checksums that IBAN has, and then complaining that IBAN is broken. Most people interact with WETH via UIs, but for some reason this user chose not to, and got severely burned because of it.
Things that require expertise usually requires one to know acronyms and how things works underneath, the cryptocurrency space is no different.
Now I don't know what you do for a living, but it certainly isn't cryptocurrencies. I'm sure there are more industries you don't work with on a day-to-day basis, and when people who are in those industries talk with each other on a technical level, you'll see the same amount of jargon. That's just part of expertise in a subject.
For example, two of my friends are chemists, and sometimes they talk chemistry stuff when we're having dinners and stuff. Of course I don't understand most of the stuff they are saying, but I'm not gonna claim "chemistry" is "magical knowledge" just because I don't understand it, so I'm not sure why you would about cryptocurrencies.
> You'd expect that invalid actions lead to idempotent errors, not glitch states where you lose everything.
Indeed, and that's exactly how most cryptocurrencies work today. You try to send funds to an invalid address, the wallet will present you with an error that you cannot do that.
The user in the submission did not perform an invalid action, because they wouldn't be able to perform an invalid action.
So your definition for "valid action" is just that the eth network lets them do it?
They clearly didn't want to burn £500k, and that is now irrecoverable, alongside 260 other people who made the same mistake, on a smart contract that forgoes validation for gas fees.
> So your definition for "valid action" is just that the eth network lets them do it?
Yes, this is indeed the definition for "valid", that the protocol allows them to do it.
It was a valid action, but not the action the user actually wanted to perform. There are two ways of avoiding these scenarios: A) use UIs and don't interact with the protocol without safeguards, as the UI will prevent you from making mistakes (this user interacted directly with the contract, not via a UI) and B) when doing something involving a lot of money, do it once first with a small percentage, so you can verify it's correct (this user didn't do this either).
For example, I know that IBAN has checksum built into the "address" and that the bank could revert transfers, but if I make transfers above a certain sum, I always send a small amount first, make the recipient confirm how much they received (I send a small random sum) and only then do I perform the larger transfer.
As I mentioned elsewhere in the comments on this submission (https://news.ycombinator.com/item?id=30136941), it's impossible to know if someone actually has access to an address or not, so why would the wallet stop them from sending it?
"It was a valid action, but not the action the user actually wanted to perform."
It's an action noone ever has ever wanted or ever will want to perform.
In the same way putting your finger inside a power socket is an invalid action, and people who designed sockets were smart enough to make it impossible.
For example, some holder (maybe a founder) of a certain coin can burn a certain amount of their tokens, making it more rare. This is a quite common practice. If I were to burn a certain amount of tokens, I think the most natural thing to use as a burn address would be the contract address itself.
Making it easy to build contracts that will accept resources and then never do anything with them, destroying the value, is a design mistake.
This is something the developer of the contract should explicitly opt into. As others pointed out, if everything a contract did was via explicit methods, rather than transfers, this type of defect would never have been created.
And this mentality is what will block wider adoption of crypto. Calling people dumb for not understanding a non-intuitive system (after there's so much prior, "return to sender" art in the world) will not get them to use crypto.
Sure, I have no desire for cryptocurrency to get a wider adoption, I have no skin in the game, I'm just looking at the facts. I don't care if the space burns up or saves the world, for me is the same.
This is not the case of a non-intuitive system screwing the user. This is the user purposefully avoiding using the intuitive systems setup for them, and interacting with something directly even though no one does that unless you're a developer. This person has half a million dollars worth of X, while not understanding X.
> (after there's so much prior, "return to sender" art in the world)
That's awesome that you have come up with a solution for this, while the ecosystem hasn't been able to. Could you share your solution?
It's a hard problem to solve in a system that has to A) be decentralized, B) work when less than half the network is trying to screw you and C) prevent double-spending
"return to sender" sounds easy to implement in a centralized system, but it's not that simple for a decentralized one. At least not until you release your solution.
> This is the user purposefully avoiding using the intuitive systems setup for them, and interacting with something directly even though no one does that unless you're a developer.
Of course using the intuitive systems setup for the
means that one has to trust some random people or companies, instead of going directly to the blockchain. What happened to trustless?
"Trustless" is referring to the consensus in the protocols, not to the entire ecosystem. This is a ecosystem built by and for humans, of course there will be trust involved.
You are intentionally misrepresenting the parent comment. The point is not that nobody should be able to transfer from one address to another, and pretending otherwise is pretty dishonest.
But then please share with me what the argument is? The user made a transfer that shouldn't have been done in the first place, and somehow people are saying that the protocol should have safe-guards against doing transfers to the wrong address, but how is the protocol supposed to know what address is right/wrong? There is literally no distinction between them, so therefore you need to allow any transfer, or no transfer.
So I guess, when it comes down to the wire, what wins out, the needs of real users, or the documented description of a protocol?
The fact that said protocol is incapable of addressing real needs is a failure state, and historically this has been addressed by building better tooling on top of the protocol, or replacing it wholesale.
> The user made a transfer that shouldn't have been done in the first place, and somehow people are saying that the protocol should have safe-guards against doing transfers to the wrong address, but how is the protocol supposed to know what address is right/wrong?
Sure, the user sent stuff to the wrong address... Or did he? Seems, rather, that he sent the wrong kind of stuff. Had he sent, whateveritwas, WETF in stead of WETH or vice versa, then it would have gone right.
So then it seems the receiving thingamajig was at least as much at fault: It accepted (and just swallowed) a kind of stuff it shouldn't receive. It's like, say, a one-way currency-changing ATM that takes dollars and returns euros. If you feed in euros by mistake, it fucking obviously should just spit them back out (and preferably display or print an error message, "Wrong currency: Gimme dollars to get euros.") You're saying just swallowing your euros would be a "valid" behaviour for that machine.
That's so obviously bullshit that the only remaining mystery here is whether you're actively trying to defend what you know is indefensible, or actually so deluded that you've somehow convinced yourself this bullshit is true. Well, no, not the only one: The other mystery is, which is worse?
>how is the protocol supposed to know what address is right/wrong?
It's the "right" address for certain transactions--like turning ETH into WETH--but the "wrong" address for other transactions, which makes the whole thing a garbage design. You can say "that's just the way Ethereum/crypto/smart contracts work" all day, but it doesn't matter.
Most people don't care why the design is bad, they just care that it is bad, and that there are better theoretical (or real) alternatives to this tech.
Your analogies make sense to me. Sounds a lot like running a system on Linux. Or maybe assembly is a better metaphor. I like the analogy about avoiding all the safety mechanisms on an electric line and jamming your hand in there...the grid can't tell the difference.
The arguments here are odd. The blockchain isn't built to handle this kind of operation by a non-expert user. Yes, mistakes are expensive. Is that okay? In the same way that a nuclear power plant isn't designed for a rando to go in and operate it.
Yes, raw blockchain stuff is hard and non-experts should not interact directly.
The key question is, is the payoff worth building an entire system around? For nuclear power, yes, because it provides electricity for people to just plug into. For blockchain, maybe, maybe not.
> The blockchain isn't built to handle this kind of operation by a non-expert user.
But the blockchain in general and smart contracts especially are pretty expressly supposed to be, that is, central to trustlessness is not requiring some elite priesthood as an intermediary (either personally or as trusted purveyors of overlay systems) between end users and the authoritative system.
Sticking your dick into a socket results in transfer of electrons from one object to another, thats the entire point of the electric grid! Clearly it's designers had no need to design circuit breakers, ground fault circuit interrupters, etc.
Listen, in this case, there already is circuit breakers, ground fault circuit interrupters and more to prevent problems to happen in the first place. The wallet is the first guard against this, the UIs the various services provide is another, and so on.
But when the user bypasses those and interact directly with the chain, which is not recommended for people who don't know what they are doing, problems can happen.
The same as if someone bypasses all those checks you wrote about, and then complains that they got a ton of electricity zapped into them. Why doesn't the grid just know that it was a human and not something else and stopped sending electricity?!
You know what happens when you transfer money to a non-existent/incorrect IBAN?
Most likely your bank will reject the transaction and not even defund your account - as you mentioned, the IBAN itself is already designed to prevent human error.
If by chance you “crafted” a technically MOD-97 valid but not existing IBAN and the money goes out to the other bank (PACS.008), the other bank cannot book it (as the account doesn’t exist) and should automatically return it to you (PACS.004).
If by chance the other bank is incompliant and does not return the money, you can have your bank send a recall message (CAMT.056) to try and retrieve the funds. The other bank is then compelled to either refund the money (PACS.004 again) or at the least officially communicate they’re keeping your money (CAMT.029).
At that point, there’s still law and legal avenues to pursue.
One thing that does not and can not happen though, is for the money to vanish into a black hole and be removed from the economy. That is what a stable, standardized and reasonably regulated industry with some centralization does for you.
You know what happens when you send Ether to a incorrect Ethereum address? The wallet will reject sending it. If you bypass the wallet and rewrite your own wallet to send it anyways, the validators reading from the mempool will reject it. If you rewrite your own validator to accept it anyways, no other validator will accept it and the transfer will never go through.
What happened here is more like you used IBAN to send to the correct account, the correct bank and everything was correct, but no one actually has access to the account but the bank doesn't know this.
As far as I can tell, no one has argued that transaction validation for this specific smart contract should be built into wallets. You're arguing with a straw man.
The point I see made instead is that the smart contract should not be coded to behave as it does. If a financial product at a retail bank set a pile of cash on fire when you used it incorrectly, regulators would swoop in and make the industry add some safety features, even if that safety came at the cost of convenience.
It's very hard to draw parallels from cryptocurrencies to other things as it's not like other things we have today.
Some sort of analogy could be margin calls/puts. Imagine someone who doesn't know how margin trading works used it, and lost half a million dollars. Who's at fault here? The bank for allowing it, the financial system for having the feature or the user for not educating themselves enough to understand how it works?
> Some sort of analogy could be margin calls/puts.
That is not a comparable situation. The ETH/WETH trader misused a negotiable instrument, and 500K disappeared forever. Someone who loses 500K gambling on margin was gambling and lost. If they somehow mistakenly placed an order on margin, there's probably a process to reverse the transaction and get your funds returned within a specific time window (that's just a guess on my part, though, and it probably depends on the brokerage used).
> It's very hard to draw parallels from cryptocurrencies to other things as it's not like other things we have today.
I don't think this is true; cryptocurrency in this situation is very similar to cash. You can get mugged while holding 500K in a briefcase, and the funds are unrecoverable absent legal restitution. But that's why banks make you sign a waiver of liability when you withdraw large sums in cash.
> Yes, this is indeed the definition for "valid", that the protocol allows them to do it.
I believe that this, right here, is the core disagreement surrounding the utility of cryptocurrencies. There are two orientations to think about software. One is the software orientation and one is the human or problem orientation. "It did what the software says" is a defense often used by crypto advocates who point out, rightly, that there are very strong guarantees that cryptocurrencies provide and other things that they completely do not guarantee. Other people point to the mismatch between the guarantees that cryptocurrencies provide and the actual failure modes that are very common in the real world and complain that advocates seem to be completely ignoring these issues.
I think a relevant comparison is security vulnerabilities in traditional software. If you've got a program that is exploitable through a buffer overrun that enables arbitrary code execution, the program is behaving precisely as programmed. From the perspective of the program and the computer, there is no difference between ordinary operation and the exploit. But from a human perspective one of these behaviors is expected and one is both unexpected and undesirable. And the "well, just don't fuck up your C program" argument is basically failed at this point, for good reason. I would expect to see the same in the crypto space.
This is impossible to solve, in the cryptocurrency space or in the existing structures we have. When you send an email, you cannot know if someone actually has access to that account (maybe they forgot their password?), you can only know if the address is valid or not (by sending the email). Similarly, you don't know if the right person has access to the bank account you're sending funds to, unless you ask the person who is supposed to have access, if they actually can access it.
Since this has already been answered multiple times in this submission already, I'll leave you with this:
> You know what happens when you send Ether to a incorrect Ethereum address? The wallet will reject sending it. If you bypass the wallet and rewrite your own wallet to send it anyways, the validators reading from the mempool will reject it. If you rewrite your own validator to accept it anyways, no other validator will accept it and the transfer will never go through.
> What happened here is more like you used IBAN to send to the correct account, the correct bank and everything was correct, but no one actually has access to the account but the bank doesn't know this.
Let's talk about putting safety rails around large drops.
They should never be necessary with careful use.
And they can't prevent everyone from falling to their death.
But they still prevent some harms, so we generally require them to be present.
Design to do everything with contracts through methods instead of transfers to contract addresses would make this particular type of failure impossible. There would still be other ways to screw up and lose money on accident, of course. But any way that can be reasonably eliminated and isn't, is a design flaw.
SMTP servers are able to reply whether a user exists, and some still do. Your own server will send you a "undeliverable" message if it receives a negative reply.
Haha, that’s why the client software needs Nick-Fury-style safeguards to say “I understand that this a valid transaction, but given that it’s a stupid-ass transaction, I’ve elected to throw a warning.”
What % of the people that use IBAN, know that there is a checksum, know what a checksum even is, or how to apply it?
Thankfully we have banks to deal with that - and legal framework that can help us undo problems.
"But you can use an exchange with ETH!"
Like banks? Making such networks ostensibly not 'decentralized'?
The entire point of Crypto/Blockchain is that is decentralized and is accessible to everyone.
If it requires that we trust 'quasi-centralized nodes' like CoinBase (i.e. banks) then it mostly defeats the purpose. Just use a bank.
At absolute minimum, the purveyors of such tech should be providing 'off the shelf' free wallet software that solves all of these problems of magical knowledge.
All of these arguments are fading quickly and the people doing this are risking a lot of credibility.
We talk about people wasting their time on AdTech, but at least there is actually some value in AdTech. We are facing an entire generation of people doing 'NoTech'. Let's turn this into something useful.
I think you missed that the user went beyond just using something to swap ETH for WETH and instead interacted directly (manually) with the contract, effectively bypassing the safe-guards that are already in place (even without exchanges) to prevent issues.
The user basically guessed that this is how you turn ETH into WETH and vice-versa, without actually reading anything about it.
If the user searched for "How do I turn ETH into WETH?" and read the first few links, they would have avoided this problem. If they made a mistake of entering an invalid address in a wallet for a transfer, the wallet wouldn't allow the transfer in the first place.
> The entire point of Crypto/Blockchain is that is decentralized and is accessible to everyone
Yes, indeed. That also implies that you're responsible enough to have a basic understanding of what you're doing. Or at least recognize that you don't have a basic understanding, and seek to attain one when needed.
It doesn't really matter that 'someone did something they should not'.
People will always press the Magic Red Button without knowing what it does with some, if rare, consistency. That's human nature, ergo, our systems must accommodate.
The fact it's possible to lose $500K whereupon 'nothing can be done about it' is a 'dealbreaker' for this tech.
The truth is, when one goes down the rabbit hole, one discovers that ETH doesn't really solve any problems and creates a bunch of problematic side-effects. When you solve those side-effects you end up with something that looks like a regulated banking system.
There needs to be a new angle/twist or use case that we haven't thought of yet, in order for any of this to make sense. We risk getting into accidents when we drive a car, because the 'upside' of fast travel is worth the risk. There's just no real upside with Crypto yet. NFT was a neat idea, but that's not it either.
> People will always press the Magic Red Button without knowing what it does with some, if rare, consistency. That's human nature, ergo, our systems must accommodate.
Are you also frustrated that you can run `rm -rf --no-preserve-root` on your computer and it's not possible to get back your data unless you had backups since before? Clearly, this is a dealbreaker for UNIX because it allows you to delete your root partition. Why would you ever need that?
> NFT was a neat idea, but that's not it either.
Yeah, no, NFTs were and remain a disgusting idea, but thanks for revealing your opinion on that, makes it easier to understand where the falsehoods in the rest of your message comes from.
Cryptocurrencies give you the OPTION to use a trust-less decentralized system. If that’s not your cup of tea, nobody is forcing you to opt-in to this system. Go use a bank, or a centralized exchange, or whatever makes you happy.
> At absolute minimum, the purveyors of such tech should be providing 'off the shelf' free wallet software that solves all of these problems of magical knowledge.
UI is continually improving and is already much better than in the early days. But the “purveyors of this tech” don’t owe you anything. If you’re not satisfied with the current wallet offerings, you can go build your own, or you can simply choose not to use cryptocurrencies.
If the 'option' implies all sorts of 'costs' (such as lack of oversight, losing money, no insurance') - then it's a choice rational people will not make.
"But the “purveyors of this tech” don’t owe you anything"
You're right.
And it's why nobody in world uses crypto, blockchain or any of this nonsense for doing anything productive and use it solely for trading magic numbers.
Currencies don't come with a prerequisite of intimate knowledge of industrial jargon that requires use on a daily basis to be proficient enough in to not lose everything.
If you're gonna deal directly with the forex industry without any safe-guards there will definitely be a bunch of jargon around, have you ever dealt with the insides of forex trading before?
In general, giving someone money does not require intimate knowledge of what's happening behind the scenes, that's true. But the submission is not about a normal transfer, the user is explicitly avoiding the safe-guards in place, and got burned by it. It's no surprise really.
The idea behind 'smart' contracts is to have immutable and decentralized pieces of code on the blockchain to execute transactions, eg. to swap ETH for NFTs or ETH to WETH like in the OP. They have addresses because they can keep a balance, but because they are supposed to be dencentralized no one can move that balance. If it did have a transfer or withdraw function people would have to trust the creator not to suddenly scam everyone.
But yeah the ability to send the directly to the address is stupid. There are no real world and crypto world use cases do it. I think the most glaring thing is that person has 500k in ETH but no idea how smart contract work or how to use the functions...
> to execute transactions, eg. to swap ETH for NFTs or ETH to WETH like in the OP.
It could apparently only swap from one kind of crypto-"currency" to other stuff.
> But yeah the ability to send the directly to the address is stupid.
Isn't the problem raher the ability to send the wrong "currency" to the address?
If it can only change from one kind to others, then the correct behaviour is obviously to accept only that kind, and reject any others. This is basically an online version of a physical currency-changing ATM, where you feed in dollars to get euros (or other currencies?) in stead. If you feed in euros or pounds or yen by mistake, the ATM should obviously spit it back out. This online version just swallowed the wrong currency. You don't have to know how ATMs actually work internally in order to determine that this is invalid behaviour not only on the user's part, but definitely on the ATM's too. If the ATM can only change from dollars to other currencies, then it should only accept dollars.
Well no, you can use options and swaps to accidentally "gift" your money to more proficient traders or to market-making institutions or just pay it away in fees, but in all those cases you're giving the money to someone, not shredding it.
an immutable black hole might as well be a shredder. the OP in the reddit did precisely that. that money is GONE. locked away forever. it has not been transferred to anyone else.
Indeed, an "immutable black hole" could be described as a shredder, agree. But that's not what that address is. The semi-official "black hole" address for Ethereum is 0x0000000000000000000000000000000000000000 (https://etherscan.io/address/0x00000000000000000000000000000...), currently has $29,461,295.02 worth of ETH in it. Any other (valid) address is just another address on the network.
"It's not a black hole, because black holes are collapsed stars, which is clearly not what we're talking about."
This is basically the style of argumentation being used here. Frequent equivocation over the terms "valid" and "black hole" to avoid addressing anyone's actual point.
This kind of argument came to mind when I first read the thread, but then I thought... isn't the whole point of crypto to be decentralized? To avoid these kinds of concentrated power structures?
The thing that gets overlooked here is this guy had to have an above average understanding of all this to even get into a position to make this mistake. Manually sending weth to a contract address is not a process a newbie would even conceive of doing. Or even having weth in the first place.
This guy was pretty far over on the right side of the bell curve when it comes to Ethereum knowledge.
It's still obviously a giant design gotcha that losing money this way is possible. They fact that it happened to a guy who knew probably 95% of the esoterica he needed to know to complete the transaction successfully and still got completely burned is an issue.
> The thing that gets overlooked here is this guy had to have an above average understanding of all this to even get into a position to make this mistake
You'd think so, but you'd be surprised.
> This guy was pretty far over on the right side of the bell curve when it comes to Ethereum knowledge.
No, that's not true. Even people at the beginning of the bell curve know that you don't send half a million worth of anything around without verifying first that what you're about to do, is correct. You first do that by reading through everything and double-checking. And after that, you do the thing you want to do, but with 1% of the value or less, and verify/double-check again. After that, you do what you actually wanted to do.
The ecosystem is very new, has bunch of sharp edges everywhere and there is no recourse if you do anything wrong, so going through this process is something you learn very early on.
> They fact that it happened to a guy who knew probably 95% of the esoterica he needed to know to complete the transaction successfully
This is obviously not true, as the person seems to not even have search for "How to convert X to Y" before performing something they know they might not be able to undo.
If this happened at a bank, you would be told you submitted the wrong form to withdraw foreign currency from your account (closest analog I can think of) and be given the correct form before it even started getting processed.
A better analogy would be that you sent the money to a bank account you thought belonged to X, but X can no longer prove that they actually are X, so the bank are not allowing them to withdraw the money anymore. Would the bank still send back the money, even though the recipient was technically correct?
This is indeed the level of knowledge required for even just transferring ETH to another person/wallet. There are different kinds of ETH, and if you transfer to the wrong kind of wallet, you lose everything.
Despite the protestations of advocates, this kind of thing is a major hurdle to adoption.
Same. That top reddit comment that crypto is not ready yet is absolutely right. This feels like a small bu2ow er trting to digitalize their whole operation on 1978 micro computers and getting burned for it.
"Any sufficiently advanced technology is indistinguishable from magic."
but yes, I find myself thinking the same with many things. especially when the disciples seem irritatingly proud of their "knowledge" which actually is just a collection of arbitrary and anti intuitive rules.
Agreed. Some people are super careful, like myself, when transferring money between personal (normal bank) accounts I always test with a small amount. Even if the bigger amount is like $200. And that's after triple checking the account number before clicking transfer. I can't imagine what I'd be doing with these exotic crypto accounts and smart contracts.
When I do money transfers on bank accounts, I read the 10 digits 4-5 times. If the person that I'm transfering to is in the room, I ask them to read aloud their account number as I follow.
The fact that you have to get 10 digits right and that a typo can result in sending the money off somewhere unknown, disturbs me a lot. It's amazing how cryptocurrencies mimicked that part about existing digital money to perfection.
Give me a QR code, or wire my wallet up with an address book.
That only proves that banks in your part of the world are way behind the state of the art. The one thing it doesn't prove -- I hope you didn't think it does? -- is that Crypto/Blockchain is necessary for international currency transfers (as some deluded poster here tried to argue a week or two ago).
In Canada we use email for person-to-person money transfers. I transfer money to my contacts by email address. They then get an email which informs them they have a pending transfer, and allows them to deposit it into their bank account.
You can optionally register your email with the central system for autodeposit.
This is one thing that really confuses me about crypto. Whenever I've worked on a website there is an underlying idea that things need to be simple and intuitive because users aren't going to struggle to figure out how to use your site - they'll just bounce.
It's hard to reconcile my experiences with trying to get users to understand and use relatively simple things with the inscrutable nature of the crypto space. Crypto is overflowing with unwieldy acronyms and punishing rakes to step on. And yet, people are putting massive amounts of money into this?
That's disingenuous. These are really basic concepts in the space (where space = smart contract blockchains).
If you're going to slush a cool half mil around, you should really have absolutely basic litteracy of how this stuff works -- just how you should have the same litteracy about the banking system if you're going to half a mil there too. Or hire people who do.
> It sounds like those arguments you'd hear between kids in junior high over magic cards or pogs or something.
"Just as trying to think up startup ideas tends to produce bad ones, working on things that could be dismissed as "toys" often produces good ones. When something is described as a toy, that means it has everything an idea needs except being important. It's cool; users love it; it just doesn't matter."
None of these explanations have ever covered what the hell WETH is, or the reason the person was trying to exchange it. Seems like there's still a lot of implicit assumptions in these explanations.
WETH is short for “wrapped Ether”. It’s a token issued on the Ethereum blockchain. This token conforms to the so-called ERC-20 standard, which is — essentially — the API of the token. Ether itself does not conform to the ERC-20 standard, which is why wrapping it is necessary to e.g. exchange it for other ERC-20 tokens via a smart contract designed for this purpose (confusingly called a “swap”).
> Or a currency conversion machine where you can shove USDs in the slot to get EURs, but if you shove EURs in, to the shredder they go,
This example is kinda funny. If your bank notes were accidentally damaged in germany, you could send them to the federal bank and have them replaced as long as more than half of the bank note can be reconstructed. This is a service intended especially for victims of fire or flood catastrophes, though dog related accidents aren't unheard of either.
AFAIK it's the same in the US (the US mint is in charge of both producing and destroying money), because treasuries want to keep track of the physical money supply.
You don't, and it's not what technically happens, but it's the closest I could find as the actual behaviour can not be replicated in the real world.
The actual behaviour, at least in my understanding, is that the bank check goes in a box to which only the ATM has access, but the ATM was never coded to look for bank checks in the box, and it's not possible to update it, so it's not possible to get the bank checks out of the box.
In the real world you could take the box out and force it open, but in "the blockchain" the contract has sole control of the wallet, an updated version of the contract would be a different contract with a different address.
> Is this the intended functionality or a bug?
It is, in the broadest sense, a bug: the contract was not coded to handle anything other than ETH inputs, so it ignores everything else, but the other things were still moved into the box.
This isn’t genetics, it’s money. Crypto needs to be simple enough for everyone to understand before it can be adopted by everyone. My kids understand stocks and back transfers, while incredibly smart and savvy people are getting confused about crypto and losing money accidentally (it’s not just this single incident, it’s a common story). This isn’t good, and shouldn’t be dismissed as people having unreasonable expectations.
I agree that cryptocurrency has a ton of UX issues to work out in practice, but you don’t need the level of explanation in the top post in order to use it, so the issues mentioned aren’t relevant in practice, and aren’t a good example of “poor cryptocurrency UX for end users”.
What the redditor did was analogous to ignoring the exposed UI elements on a web page and instead opening up the console and calling the JavaScript functions directly. The average user doesn’t try to do that, and so any such failure is not an issue of the website “needing an advanced understanding”; simply following its UI elements is enough.
So it’s unfair to equate the understanding needed for the top explanation with the understanding needed to use a cryptocurrency app.
That user could have used it how other people use it.
There are a lot of things here that have nothing to do with “crypto needs to be simpler” copypasta. This particular thing was not simple and never will be unless everyone stops using it. Focus on that one thing: How to design a better smart contract? How to design a better UI for the end user? Thats a great discussion for a programming forum actually.
> This particular thing was not simple and never will be
The user used a currency-exchanging thing, sent it a currency it shouldn't accept as input, and it swallowed his currency in stead of rejecting it.
What's "not simple and never will be" about that? Seems utterly simple to me: The currency-exchanging thing didn't work as it fucking obviously should. And the cryptards have the unmitigated gall to call this shit "smart"... Sigh. Geroffmylawn.
Treating this transfer of WETH as just 'money' is an overly simplified model that is going to get someone burned in the same way as this reddit user. You are interacting directly with low level APIs that are irreversible while sending a lot of money to them, without knowing what they do. This is NOT good, and believe anyone without thorough understanding of these risks and how ERC APIs work should NOT be doing this.
There is an absolute need for cleaner UX on top of this with assurance/insurance to avoid this scenario (both of which exist and are being improved regularly). In the same way you don't directly interface with SWIFT APIs when doing bank transfers, you should not interface directly with ERC20 approve/transferFrom APIs in Ethereum, unless you really know what you are doing.
You are expecting to understand how a completely new and complex technology works from 5 lines of text. Imagine if someone tried to explain Kubernetes to you in 5 lines of text.
There certainly is a different group who pushes Kubernetes as the savior of DevOps. I’ve seen this put plenty of pressure on teams to adopt it and they’ve gone in too fast, resulting in downtime, security issues, and huge operational costs. These are real costs and can have an affect on someone’s home life and career prospects within their company. I’ve had to go in and save quite a few of these people, and they were pretty miserable.
We shouldn’t shill any technology, and anytime we do talk about it’s virtues we should discuss its shortcomings and why people should be hesitant to use it.
It abstracts away underlying hardware, leaving you with a convenient set of abstractions for deploying containerized networked services. Sort of an OS for a cluster of distributed machines. Unfortunately this involves lots of YAML.
How’d I do?
YAML stands for “YAML Ain’t Markup Language”, (originally “Yet Another Markup Language”).
It it a way of storing the same kind of thing that JSON can store.
Though, unlike JSON, it supports comments, uses a python-like significant indentation, and has a few uh, things not in quotes sometimes being taken as strings, but if it is `NO` then instead, if there are no quotes, it will be interpreted as the constant false .
One could write a sentence like that about smart contracts. One I pulled from Google:
Smart contracts are simply programs stored on a blockchain that run when predetermined conditions are met. They typically are used to automate the execution of an agreement so that all participants can be immediately certain of the outcome, without any intermediary’s involvement or time loss. They can also automate a workflow, triggering the next action when conditions are met.
Knowing nothing about it, this is the question that remains unanswered to me after reading through dozens of comments on this debacle. What was the person who lost half a million trying to accomplish? For what benefit?
I assume that if you just want to use ETH to buy and sell stuff, you don't have to get involved with any of these smart contracts.
There's some detail on weth.io. apparently ETH is not Ethereum (ERC-20) compatible, if you can believe it.
I'm still kind of confused how ypu go from one ERC-20 chain to another. I know there's wrapped Ether on other chains but I'm not clear on how it got there or whether it's a good idea to hold that. Seems like a "not my keys" situation in a way.
You mean buy and sell goods and services? Correct me if I'm wrong, but I don't think basically anyone uses ETH for this (compared to BTC and BCH where at least some merchants exists). If you want to buy and sell tokens in a decentralized fashion, then you'll have to deal with smart contracts.
> I assume that if you just want to use ETH to buy and sell stuff, you don't have to get involved with any of these smart contracts
Correct. If you want to send someone money unconditionally, you can just send it without a smart contract.
> What was the person who lost half a million trying to accomplish?
Why/when to use WETH? From the beginning:
Like Bitcoin, ETH is a crypto currency that has it's own token called ETH (or Ether), you can hold it, send it from one address to another address and earn it by mining. Providing a basic finance and value excahnge platform.
In addition to ETH, Ethereum supports (via Smart Contracts) things called tokens, that are effectively alternative cryptocurrencies. Pre-Ethereum, people needed to create a new chain for each new token, for example you have "NameCoin" and "LiteCoin" and "DogeCoin" and so on. Each has it's own network, initial block, wallet client, mining pools, etc. It's a copy and paste and edit of Bitcoin each time.
With Ethereum, you can create a new token with it's own separate initial supply, precision, allocations etc. on the same blockchain (Ethereum) using a Smart Contract. People can use these tokens on the same network, using the same tools. However there are limits on how different they can be - you can only do what the Ethereum tech allows.
Now as time went on, there were a lot of tokens, and so they developed a standard, ERC20, which is like a C# or Java interface that defines a standard token. With this in place people can write code that interacts with "any token".
I could create a stock exchange contract where people list, place orders etc. to swap tokens. Even once this stock exchange is written and deployed, people can create brand new ERC20 tokens, and because those new tokens meet the interface, the stock exchange will work with it.
This all hots up and of course people naturally want to use these stock exchange, and other contracts (be it gambling, lending, escrow or whatever...) with the original ETH token, since everyone playing has ETH (you need ETH to pay network fees), and it's value is going up and wotnot.
But ETH is not a smart contract. It's hard coded into Ethereum. It was written before ERC20 was standardized. So you can't use Ethereum as one of the tokens in your stock exchange.
WETH offers a way to wrap Ethereum in an ERC20 token and solve that problem!
Since smart contracts can define rules about deposits, withdrawals, etc, and smart contracts can own their own Ethereum. This wrapping can be done purely in code. No need to trust "WETH Inc"*.
WETH is basically an "adaptor" from the gang of 4 design patterns.
* Other wrapped coins usually require trust. For example "Tether" wraps USD, but it requires a company to manage the bank accounts. People may decide they don't believe that company really has the funds, or the parent company could be put out of business by a government. WETH on the other hand is wrapping something on the blockchain in a code-automated way.
You can make mistakes (like the OP) but unless there is a big security hole no one has discovered, you can't have the money stolen or confiscated unless your private keys are compromised.*
Thanks for the explanation. So presumably the person involved was intending ultimately to do something involving some market that uses WETH rather than ETH, and was unwisely testing how the system works with ETH worth half a million dollars rather than five dollars. (Or possibly they changed their minds about using WETH for some purpose, and so just wanted their ETH back?)
Yeah, having done this myself, a use case might be:
1. Buy ETH
2. Convert to WETH
3. Swap for TOKEN
4. Hold TOKEN
5. Swap token back for WETH (hopefully made a profit there)
6. Convert WETH back for ETH
I did this using Metamask / Uniswap so it is all done for you. So I had no need to understand how the contract works. Also didn't have anywhere near $500k!
This is not necessary a problem? If someone waxes lyrical about nodes, pods, containers and ingress and you know nothing of kubernetes it will sound like jargon soup. But people can understand kubernetes and build services with them, and present UIs using these elements that ordinary people can use.
The supporters here are saying "yeah, it shreds dollars, he should have known that". And yeah, if you have a machine that shreds dollars, you better know what it does. That's a good reason for not having such a machine.
Anyway, ETH seems to be full of those features where it shreds money on places that are really not obvious and sometimes gets every single person by surprise.
I have seen real proof of this. The only reason "regular" people buy Android is to save money, but it becomes a support issue for their children and grandchildren. I've made sure my entire family is on iPhone. My mom could never figure out the bottom three buttons on Android. iOS makes more sense to her.
I think this is a problem with crypto that will forever prevent it from becoming mainstream. The average person understands the concept of money but understanding smart contracts is out of scope for a large part of the general population m
Even in todays traditional banking system there are a litany of cases where people refuse to take responsibility for their gullible actions and expect their bank to bail them out.
There are a few stories on the ThisIsMoney (UK's Daily Mail's money rag) front page right now about relatively convincing and sophisticated scams where people were robbed of thousands.
The average person isn't ready for the risk of crypto.
It’s really incredible how easy some of these scams appear to pull off. “I’m your oldest child and no my microphone doesn’t work so I can’t talk to you and I need $2000 immediately” and the parent bypasses warnings from the bank about possible fraud and shoves the transaction through…
It also shows how many of these scams can be defeated with a few simple precautions. Most of them would be defeated by calling the bank back… in other words don’t answer your phone, make all your calls outgoing. Others are defeated by simply not doing anything hastily and under duress (like urgently wiring all your money to an external account for “safekeeping”).
This is one of my actual fears for deep fakes - imagine actually being able to perfectly imitate someone's child to scam them. My parents and I long ago set up a codeword system as a way to delegate trust, but imagine actually hearing your child in distress - it could short circuit your skepticism pretty quickly.
> Even in todays traditional banking system there are a litany of cases where people refuse to take responsibility for their gullible actions and expect their bank to bail them out.
Yeah, but in today's traditional banking system people don't have to contend with currency-changing ATMs that change dollars to euros, and when you feed euros into them by mistake they just shred your money in stead of spitting it back out.
That's not the user being gullible (or OK, maybe that too, but mainly), it's the system being moronic. Or perhaps rather, evil.
Hm, but wouldn't smart contracts have to be as complex as a non-smart contract, if a smart contract were to replace the dumb contract? If I'm looking at the regular B2B contracts I'm supporting at work, even normal contracts are already testing people. Piling (highly complicated, mind you) software on top of that problem seems nuts and entirely not feasible.
Dont know of any traditional contract that can accidentally make money vanish. Also you can go to a centralised authority e.g. bank or court to do something about the wrong party holding the funds at any given point.
You can even retrospectively apply reasonable person type arguments no?
And that is even an argument on top I didn't even mean.
> You can even retrospectively apply reasonable person type arguments no?
Yeah. A significant part of a traditional contract revolves around defining the entities and behaviors you're actually talking about, and another part is about specifying requirements and boundaries for these entities and behaviors. However, it is entirely possible that during a conflict, the parties of the contract disagree about the meanings of the words on paper.
In such a case, you'd bring in a judge by bringing this to court, and a judge has the right to interpret the words and act in the spirit of the contract clauses, not just the words, and to deliberate about the feasibility of clauses. And that's a good thing, because this is a strong defense against scam and fraud.
Like, if something really strongly looks like a contract to buy a car, but technically doesn't say you buy the car, but also doesn't say you don't buy the car. If you get sued for not paying rent or stealing the car in such a case, you could argue you thought you owned it.
The nearest scenario in dumb contracts would probably be wiring funds to the wrong foreign bank account. But there are usually a lot of intentionally placed checks before you do something that stupid. And even if you did, at least there's someone you can call. That seems a bit smarter, really.
Non-smart contracts also have something like the two sides having an understanding of what the spirit of what they agreed was, and they can be discussed in court and interpreted by a judge when all else fails. So not absolutely everything has to be spelled out all the time.
Smart contracts are code and there is no fallback mechanism in case of mistakes.
They probably have to be way more complicated than non-smart contracts?
The equivalent in code is pre-existing libraries, and miles of them. But the law has highly developed ways of ridding itself of cruft and tech debt over time, in a way that lib dependencies really don't.
Legal precedent is a method for defining laws, not a requirement of a legal system. It is absolutely not essential to solve issues of incomplete, ambiguous, or invalid contracts.
I think it is more a fundamental philosophical problem with Ethereum. They have fascinating ideas and workarounds for all sorts of issues, but in the end they keep layering complex solutions on more complex solutions.
Maybe a bit like enterprise software, just add another abstraction layer...
The problem is that irreversible transactions are just bad. There is no way around it. Crypto is broken at the most fundamental level.
This kind of fuckup could not happen with regular banking and if you somehow did mess up you can almost always have your money recovered. There is no way to just black hole it never to be seen again.
Some cryptocurrencies make it impossible to black hole funds by requiring the recipient to prove they can spend the money they're about to receive before they receive it. Needless to say, these cryptocurrencies do not feature smart contracts.
I am unaware of any country where this is true. Many countries have limits on how / when transactions can be recovered but AFAIK there is nowhere where bank transfers are absolutely final with no recourse.
In my country (Germany) afaik if you transfer money, the bank is not guaranteed to be able to get it back (if it has already processed it). There are other forms, for example other people can withdraw from your account and you can contest it within a certain time frame.
Sure, if it is important to you? But I think there are also smart contracts/escrow services that require you to do additional things besides pushing "send".
The classic is for a trade, and the receiver has to confirm they received the stuff before the money is released.
Afaik "traditional" companies like ebay also struggle with that kind of thing.
The problem is, they have a fundamentally simple concept that solved the double spend and trust problems for a decentralized (sort of currency).
That part we kind of figured out, maybe it's ok, albeit super slow and power intensive, but let's put that aside for a while.
But is there a solid mathematical and cryptographical basis for everything else layered on top? I don't get that impression, it just looks like they're just plugging gaping holes because there's a gold rush to be continued!
If they're just rebuilding a crappier version of the global financial system, there's no point in the rest of us following them.
The financial system cannot run on blockchain technology, even if the technology worked well. This is because "decentralisation" requires blockchain assets to be "unconfiscable", but financing is only feasible if the assets are "confiscable" (otherwise the borrower can walk away with the money and suffer no consequences).
That doesn't seem to make sense. Don't people usually borrow money to spend it (for example to buy a house or finance their startup)? So in most cases the borrowed money is also gone and at most you can confiscate the collateral (for example the house). That is still possible with crypto.
In decentralised finance the legal system, which in conventional finance has the power to seize the borrower's assets in the event of default, is replaced with "dumb contracts", but dumb contracts don't have such a power. Financing is basically impossible with decentralised finance.
Just because finance is decentralized doesn't mean the law doesn't still apply. I don't know where you get that idea from. Also not sure what you mean by "dumb contracts" - crypto contracts can contain code on top of text, whereas traditional contracts can only contain text. So obviously the crypto contracts are strictly superior.
The counter-party to both the borrower and the lender is a dumb contract. A dumb contract is not a legal person, and therefore it cannot initiate legal action, nor legal action can be initiated against it. Furthermore, there's no legal agreement between the dumb contract and its counter-parties, since, again, a dumb contract doesn't have a legal personality which is required to enter into legally-binding agreements.
Depends on the service, but I would think (ianal) if somebody publishes a smart contract and says "you can buy my house via this smart contract", then that person is the counter party, not the smart contract.
Of course you can burn your crypto and send it so some random contract. You can also take traditional money, go to the woods and burn it.
If the borrower and the lender sign a loan agreement with an intermediary, or among themselves, then sure, but this is conventional finance, not decentralised finance. In this situation the dumb contract becomes redundant. It doesn't do anything.
In my country at least, the government charges lots of money (several thousands) to change ownership of real estate in a government managed ledger. That obviously could be replaced by crypto, which (in its basic form) is a distributed ledger. Ownership can be proven via the blockchain.
So far you've been using the present tense, "the [dumb] contract replaces the solicitor", or such.
Obviously it doesn't. Or could you tell me in which countries in the world you won't, at present, have to pay the government to register real estate ownership changes in its ledger just because you paid the seller in a crypto-"currency"?
I went to some workshops when Ethereum was developed (sadly I decided against investing in the ICO because some aspects didn't convince me or I didn't understand them well enough). Even back then the discussion was that they were trying to do too much and it would be difficult to make it work reliably. Bitcoin deliberately chose a more conservative approach. Bitcoin also actually has a scripting language and allows for smart contracts, but they were much slower with unlocking its features for real. (I don't know the current state of it).
Just to say, it really doesn't make sense to judge "crypto" by the state of Ethereum. There are different philosophies, different approaches, different people.
Frankly that is the best case scenario for crypto. It's similar to the dot com bubble in 1999 actually, it's 20 years later and the internet is finally somewhat useful and intergrated into our lives. Originally it was just a bubble inflated with ad revenue inflated with investor money
That's a super niche application, not a mass market use.
And yes, I know about the supposed use for people in countries with unstable regimes but I'm not convinced at the moment. Plus that use case, being that of people generally having low disposable incomes (barring China) absolutely doesn't justify the market value of crypto at the moment.
Inflation hits the masses, or in general money supply manipulation schemes. In the last few weeks, markets tanked just because the FEDs announced they plan to increase interest rates. Is that really how we want to go on?
Bitcoin is not being manipulated. You may be confusing it with Bitcoin markets and Bitcoin trading. Nobody can conjure Bitcoin out of thin air or manipulate interest rates on it.
That's exactly what Bitcoin miners do: They take pure thin air and convert it into noxious power plant fumes. Pure air is what the odiferous Bitcoin is conjured out of.
Cabbage patch dolls and pet rocks also work very well at letting people keep and transfer cabbage patch dolls and pet rocks, but that doesn't make cabbage patch dolls and pet rocks a sensible base for the economy. Crypto-"currency" proponents sound pretty much like the folks who used to think cabbage patch dolls and pet rocks would be the future currency.
It seems to me the philosophical mistake is that banking and financial system regulations came about randomly. As if these are just unintended software bugs. As if there was no reason for the regulations.
So all this complexity to get around regulations but you are going to run into the reasons this regulation came about at some scale.
I'm not convinced the government regulations around finance are a net win. Might often just be wishful thinking by politicians, just decree things have to be in some specific way, rather than tackling the root causes for issues.
Agreed. It's so powerful but always so complex and confusing and there's just way too many footguns like this.
"Gas" is one of those concepts where I have to relearn what it is every time I read about it but never can retain it for very long. (See also Big O notation.)
Say what you will about the primitiveness of Bitcoin and other early coins but at least they're quite a bit more comprehensible.
Gas is the reward for servers in tthe distributed system when they are (taking part in?) executing the smart contract, so that a buggy infinite loop would run out of gas soon.
With 500k$ this smart contract will be able to run for a while.
smart contracts rack up fees for every machine instruction
if your gas doesnt cover the runtime of the contract, the process rolls back all transactions and eats the fee. so you have to overshoot and get refunded the difference.
always seemed like a nonstarter to me, that the computer cant tell me how much gas it needs (see: halting problem)
Just because you can do crazy stuff, doesn't mean you have to do it. Like the normal guy isn't trading interst rate derivates or stuff like that.
Also at least with european banking, if you wringly send money to another account, it is also gone forever. A lot of scams regarding old people build up on this. We do not need to buy google play store vouchers like the americans tonget scammed.
>Also at least with european banking, if you wringly send money to another account, it is also gone forever.
Not true. The money is still legally yours if you can prove that it's a mistake or you were deceived, and can be recovered via the legal system if the recipient does not refund it voluntarily. Scammers just move the money away via other, less traceable channels before that can happen.
When someone accidentally sent me 200 EUR about 15 years ago it sure as heck didn’t stay mine: their bank contacted mine, which then contacted me to warn me that they would soon be pulling it back out. The sender had transposed numbers in the Bankleitzahl - the pre-SEPA number codes for German banks that are still in modern IBANs, and I happened to have the same account number as someone at that other bank (all little community Sparkassen). Those Bankleitzahlen didn’t have any sort of checksum digits, but IBANs do, preventing most of these kinds of accidents.
> Also at least with european banking, if you wringly send money to another account, it is also gone forever.
It's not though? The money is still legally yours and can be recovered via the legal system. Only if it is moved out of Europe into less well regulated areas it becomes a problem.
This happens in every case though. If I give you cash and you take it to god knows where it can't be recovered either. If I give you money and let you leave with it then there is only so much any system can do.
> If I give you cash and you take it to god knows where it can't be recovered either. If I give you money and let you leave with it then there is only so much any system can do.
But at least someone still has that money; it hasn't been destroyed.
What happened here is the equivalent of sticking notes of the wrong currency into a currency-exchanging ATM, and it shredded them. The system itself was a destructor of value. That doesn't happen in the regular old cash-cards-and-banking system.
If you send money to the wrong person and they don't give it back, you can try sue them to give it back, but there is no inherent law that they must do so.
Or am I wrongly informed? Because that's the knowledge I have from central european laws.
> Wer durch die Leistung eines anderen oder in sonstiger Weise auf dessen Kosten etwas ohne rechtlichen Grund erlangt, ist ihm zur Herausgabe verpflichtet. Diese Verpflichtung besteht auch dann, wenn der rechtliche Grund später wegfällt oder der mit einer Leistung nach dem Inhalt des Rechtsgeschäfts bezweckte Erfolg nicht eintritt.
> A person who obtains something as a result of the performance of another person or otherwise at his expense without legal grounds for doing so is under a duty to make restitution to him. This duty also exists if the legal grounds later lapse or if the result intended to be achieved by those efforts in accordance with the contents of the legal transaction does not occur.
Basically there is law that says for every money send should be a cause, reason that justifies sending. If there is no such reason, reciever is entitled to send them back.
Yes. Also this is not the first person to make this mistake. One redditor pointed out the person has done the largest such transaction to this contract, representing 45% of the total amount burned.
>Like the normal guy isn't trading interst rate derivates or stuff like that.
Heh, funny you say that, because there was the submission about the danger of the 30-year fixed mortgage, and how the typical borrower is in fact, making an effective bet on interest rate derivatives!
I still don't get WETH. What is the purpose of exchanging ETH, which is a token on the Ethereum blockchain, for WETH, which is also a token on the Ethereum blockchain (with the same nominal value)?
Pretty soon you'll be able to get paid interest on your WETH in WTF. WTF is a meta token based on a smart contract token based on Ethereum. With WTF, you never need to worry about where your money is. You can be assured that 100% of the time you try to redeem it you will stare at your screen for hours going WHAT THE FUCK
Pure coincidence. I had written "wtf" in response to something else and it just sounded like a good coin name for a joke. I don't follow the latest in shitcoins. Not that I'm exactly surprised there's a token called WTF...
We've banned this account for repeatedly breaking the site guidelines.
If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html.
After a while a standard api was invented for tokens that use smart contacts on ethereum. ETH predates these standards and is built in to the operation of the blockchain. Lots of smart contacts know how to deal with standard tokens but don't have a separate code path to deal with ETH. You can get a version of ETH that fits the interface by wrapping it in a standard token.
It is a tool to convert ETH into an erc-20 compatible token. ETH itself can only be spent by the private key, whereas users can grant contracts the permission to manage the user's WETH for them.
WETH is Wrapped Ether. It fulfills the conditions of an ERC-20 token, so other contracts always interact with WETH not ETH. Most of this is obfuscated away so that users don't have to have WETH in their wallet for transactions.
ERC-20 is a token standard [1] that lives on top of Ethereum blockchain. It defines the API that any contract running on ethereum must implement in order to be considered ERC-20 compatible - e.g., transfer(), approve(), and so on. This is what gives tokens composability, and allow DeFi applications to build on top of each other.
As ERC-20 runs on top of ETH, it requires gas (paid in ETH) to execute the contract. But ETH itself is not ERC-20 compatible (after all, it's just the base layer; there's no "ETH contract"), so some folks came up with the idea of wrapping ETH into an ERC-20-compatible contract, thus giving birth to WETH.
The advantage is that now ETH (in the form of WETH) can now provide interoperability with the rest of the standardized tokens, including staking, lending, or anything else implemented via a contract. Pure non-wrapped ETH would never give you that; basically you can send your ETH to someone, and that's it.
Now, the weak link is that you're relying on the trustworthiness and the quality of the implementation of the contract, which - more often than not - is questionable. The WETH contract itself is pretty simple, with only 62 lines of code [3]. But one may argue it's overly simplistic, and they failed to implement basic safeguards, like sending WETH to itself, which is what caused OP to lose half a million dollars.
The other side of the argument is that WETh contract was simple by design. Every line of code in Solidity requires gas to execute, so adding even a basic checking to protect against what OP did would have increased the cost by millions of dollars in aggregate fees for everyone else, besides potentially introducing the risk of attacks or additional bugs.
Given that only ~250 WETH transactions[4] (out of 5,562,041 total tx), made the mistake OP did, one could argue that the design wasn't that bad. That's a 99.9955% success rate.
(to be clear: if I were the original WETH developer, I would have added the checking, in spite of costing a few additional bucks for everyone else. But I understand why someone may have thought otherwise. Besides, it was 2017; a lot has changed since then)
Why was this person experimenting with $500k? Even with traditional ACH I send a $1 test transaction before any significant sum. I also use the “don’t fuck with paste” browser extension to ensure there are no typeos in the routing or account number, but just the same I still want to see a transfer work before I send a significant amount. With crypto where everything is much more complicated, there are no do-overs, and no bank to step in and undo a mistake, I’m even more cautious.
I think this more a story of poor risk management.
But they are in good company. I was on the Bear Stearns trading floor when they went bankrupt and I saw a hundred people loose their entire life savings and all their kid’s college money in a few hours. Those were licensed financial experts that were fully knowledgeable and practiced in a variety of risk mitigation techniques - which they failed to apply to their personal portfolios. The company was bought by JPMorganChase and a year later everyone that came over from Bear was gone - JPMC really just wanted the client list and their midtown office tower.
Also, ERC-777 tokens were supposed to fix this egregious problem by having all transfers check with their destinations (through hooks). There are also various similar extensions to ERC-20 I believe.
Unfortunately, practically no one uses 777 as far as I'm aware? Certainly the OG Wrapped ETH contract doesn't, and it can't be upgraded because it's immutable.
The additional transaction fees that using ERC-777 would cost in the Ethereum network are probably much higher than someone losing half a million every now and then. So economically, adopting ERC-777 would be a step backwards.
I agree that deploying the full 777 would be too costly, yes, and probably open up reentrancy attacks.
But one simple check in the transfer function would have saved this person half a million. I would gladly pay that tiny extra bit of gas for their sake.
Economically, KYC in the real world is a step backwards. Economically, laws made to restrict trading is a step backwards. There's still a damn good reason we do it, but the crypto grifters seem to only see the economical part of it for some reason.
In that sense, crypto to me is like a consultancy taking a complex, legacy codebase and saying it'll be easier to rewrite it from scratch.
We see how that plays out all the time. Something shiny and new is produced but it completely fails to take into account why the original system was so complex. Given enough time, it becomes just as complex as the old system, if not more complex.
Satoshi is a pure ancap, the lack of regulations is a feature for them. Being able to be a grifter and scam people is a feature, not a bug to most of the cryptocurrency community.
Where should one go to learn how all of these systems work? I've been trying to make an honest effort to understand how smart contracts, protocols, decentralized exchanges, etc. work, but after reading about the absolute basics quickly get bogged down in a sea of acronyms and jargon that seemingly lacks any clear explanation. This doesn't even include all of the shills, scams, etc.
> Where should one go to learn how all of these systems work?
Here's the path I'd suggest:
1) If you have no basic understanding of blockchains, read Satoshi's Bitcoin original paper, and Ethereum's Yellow paper.
2) Read about ERC-20 [1][2], to understand what "tokens" really are (TLDR: basically a hashtable stored in the ethereum blockchain, containing a mapping of balances to addresses, and the expectation that you must implement a standard API to be considered an ERC-20 token)
3) Learn about Solidity. The language is dead simple if you have any programming background (preferable C, but not too different than Rust/Python/Go), although it takes some time to wrap your head around the idea that the state is stored permanently in the blockchain. There's plenty of tutorials, but I found Ivan on Tech [3] to be excellent, and Moralis Academy [4] if you want something more structured (plus they offer many other courses in this area).
Solidity documentation [5] is also excellent. And Remix IDE [6] makes it really easy to experiment and run your "hello world" solidity programs in a simulated environment, without worrying about deploying to testnet, faucets, etc.
I don’t understand why these contracts don’t let addresses that make this particular error recover their funds, it would be easy to implement at contract creation or am I missing something?
That would be a good fix, and it is a glaring omission. But the contract can't be upgraded, so all existing contracts depending on wETH would have to be migrated or replaced too.
Basically the smart contract could have been written so that this transaction was rejected or so that the money could have been sent back, but that would make inteacting with the contract a little bit more expensive for everybody. Or maybe the developers wanted it to be possible to burn tokens by sending them to the contract address.
Seems like maybe it would have been good if the ERC-20 standard had been designed such that you couldn’t send the token to an address controlled by a smart contract unless the smart contract had marked itself as being able to receive that kind of ERC-20 token (or as being able to receive all kinds of ERC-20 tokens)
Like, if the contract for the ERC-20 token would, when handling a send instruction, would check whether the recipient address was a contract address or an address controlled by a keypair, and if the former, would check if the recipient had been marked (not sure if this marking would be stored as data on the recipient contract or as data on the ERC-20 contract) as being able to handle the token in question, and if not, cancel the transaction (other than gas costs).
This seems like it would prevent this kind of error (or at least, reduce the problems resulting from this kind of error to just paying the gas fees), but it would also maybe increase the gas cost of sending transactions with the ERC-20 tokens and I’m not sure whether this increased cost would be negligible or not.
Here is background on this for a developer-but-not-crypto-developer.
The Ethereum blockchain has its own money that is built right into "OS" of the blockchain. It's called ETH. Any time one program calls another, the actual function call itself can send ETH along with it. In fact, to transfer ETH from your account, you just make a function call to another account with no parameters, ignore return values, and transfer some ETH along with it.
Now it soon became apparent that this scheme left a bit to be desired:
First developers wanted to create their own moneys. ETH is hardcoded into the system, no one else can use that mechanism.
Secondly, funds can only be sent, never pulled. It turns out that it is really convenient to have funds pulled by trusted programs. It allows funds to be moved when you are not online. For example, you could make an offer to purchase something, and if the seller accepts, the money can be transferred to seller, and the whatever can be transferred to the buyer in the same atomic transaction. This also allows trusted programs to do the math for you using live market conditions.
Lastly, it's a giant security pain to actually have to call someone else's code, and give them the ability to execute right in the middle of the your code, any time code wants to transfer money. (This exact vulnerability lead to the first big hack on Ethereum.)
After a period of experimentation with people making their own money programs, the ERC20 standard was born. This standard is just a very small set of methods calls that a program has respond to in order to count as money. This isn't baked into the OS, it's just a standardized API interface between programs.
So you can call "transfer(...)" to move money, and you can call "balanceOf(...)" to find out how much money someone has etc. It works reasonably well.
The biggest ERC20 you have probably heard of is USDT / Tether. It actualy slightly predates the standardization, and so slightly doesn't match the behavior of everything else. This makes all programs that want to move money have to use a function that checks if the money is acting like USDT or acting like everything else.
Now the ecosystem has two kinds of money: ETH that works at the OS level, and everything else that works as a standard program. And these two have different security properties, and different ways of calling them. It's a pain to securely support both of them because the entire architecture of your code for working with them entirely different. And then there's the matter of not being able to pull ETH, which people often need.
So people decided to make a program that "wrapped" up ETH into and let others treat it as an ERC20 program. It's called wETH. You send the wETH program some ETH, it holds it, and it internally stores that you now have an amount of wETH to match the ETH you sent in. You can then spend it like any ERC20. Anyone can then ask the wETH program reduce the amount of wETH they hold, and give them back a matching amount of ETH.
Most new big blockchain programs, DeFi/NFT/Multichain bridges have switched over to only using ERC20's and requiring users to wrap ETH into wETH to use them. There's even talk/grumbling that the Ethereum blockchain should just provide a special interface allows someone to treat their ETH balance as ERC20.
I'm a senior developer with a massive breadth of knowledge. I read like crazy. I have no idea what you just said. I'm sure I could probably understand after a some research. The point is: this stuff is not for the average Joe!
It's like the famous quote by some dude: "A monad is just a monoid in the category of endofunctors, what's the problem?"
But why wouldn't the contract decline this kind of 'invalid' transaction? It is invalid as it is now stuck over there forever, meaning it's a case that should be rejected.
The thing is that there are enough frontends using this smart contract where you can simply chose 'WETH to ETH' and you'll get the right transaction. For whatever reason this person thought it'd be a great idea to interact with the smart contract directly. This is possible and fine if you either know what you're doing or read the smart contract beforehand.
> The thing is that there are enough frontends using this smart contract where you can simply chose 'WETH to ETH' and you'll get the right transaction. For whatever reason this person thought it'd be a great idea to interact with the smart contract directly.
Getting out of the supposed user-opacity of legalese to something that was safe and reasonable for a non-elite-priesthood users to understand, trust, and interact with directly without an intermediary was, I thought, the whole allure of smart contracts over using the old-fashioned dumb kind to manage transactions and business relations.
Ive been thinking about this in my own smart contract designs: cant a contract have a approve and transfer method that can accept an erc20 contract hash and transfer method from its ABI? Allowing that contract access to the erc20 tokens sent/assigned to it?
Imagine there's a machine that you can deposit dollar bills and it registers in an internal database how much you have. The machine calls these stored values as wrapped dollar. You can withdraw your wrapped dollars back as dollar bills whenever you want.
This machine also allows you to send these wrapped dollars to other people - it just subtracts from your balance and adds to the other person's.
What this guy did is transferring his wrapped dollars to an address no one controls instead of withdrawing as he should. This address was the machine's address, but it's not programmed to handle the balance in it's own account and it runs code that can't be upgraded, so any values sent there are lost.
In this example dollar = ETH, wrapped dollar = WETH, machine = the WETH smart contract.
The real problem here was thinking a ETH transfer (dollar bill deposit in the example) works the same as a WETH transfer (database transaction in the example).
Thanks. This all sounds so complicated and frankly scares me away from using these technologies. I would be worried about making this kind of mistake or worse.
The cold sweats and shame I felt, man... Plus it's on the App Store so there's the review process to deal with which extends the timeline for a fix. Thankfully, they picked it up for review 30 minutes after submission and approved it in a few minutes.