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.
Or those of us who immediately think of AES, RSA, and Diffie–Hellman.
Anyone around tech in the 1990s may also remember:
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.
It's still to much specialized to follow what's going on from a higher viewpoint.
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.
>> 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
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.
A design which actively discourages robust programming and error handling in financial software. Wow.
Want validation? Other people don't want to pay for stuff they're not validating... so it's on you to be careful.
Accidentally fuck up? Not our problem, that's on you for not calling the right API.
Want your money back? We're not paying money to cover for other people's mistakes. You're on your own bud.
Idk why people conflate libertarianism with this hyper-individualist stuff. It really isn’t the case.
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.
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.
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.
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.
Ahahahahahha. Ahahahahahahahahahha. Ahahahahahhahahahahahahahah.
--- several minutes of laughter later ---
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 no amount of mocking faux laughter will change that.
BTW I never had success trying to chargeback VISA for services that were not delivered. Scammers do it without problem though.
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.
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!
What you describe are dry runs.
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 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.
That is how high toxicity systems get made.
The incentive was robust code that would work well, get it done, go to the moon.
Here, machine time is expensive, puts emphasis on code that works, but just barely...
Let's just say NASA would check for the "yup, you are gonna burn some money" case, and reject it.
I think that people are so unlikely to fuck this up that such a check would be rather pointless.
Money matters a lot. Should this mess endure, people will forever be saying a little bit of gas would have been worth it.
And we've people with six figure arguments as to why such a check makes sense.
The idea of minimal code, focused on speed coupled with financials leads me FAR away from all this.
I will watch with great interest and entertainment.
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.
This is also how high toxicity systems get made.
It would be stupid to put these checks in the contract, they would be very expensive and only help people using unsuitable client software.
You feel all client software will be suitable?
I don't. There is NO WAY. Lots of people will do ANYTHING for a bit of margin, hoping for volume.
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.
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...
What it won't all be is dull, will it?
>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.
It really doesn't seem necessary, more complicated contracts require custom frontends to interact with anyway.
How come such a check is so damn expensive?
It should not be.
Clearly Ethereum is far from a ready product, but I think we can expect to see massive improvements when proof of stake goes live this year.
https://www.forbes.com/sites/lanceeliot/2019/07/16/apollo-11...
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.
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.
Of course you can do both things, which is why catastrophic financial ruin is a daily fear when dealing with cryptocurrencies.
https://www.quora.com/How-can-I-find-my-Bitcoin-cash-that-I-...
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.
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.
Try sending cryptocurrency to an invalid address and you'll see that the wallet will reject sending it, just like email bouncing.
A “valid” address locking up funds sent to it without recourse is /dev/null.
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 [email protected] 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.
The stakes are a little bit higher when you’re sending money instead of emails.
Simply said: you cannot send funds to invalid addresses on Ethereum.
A protocol could conceivably require the recipient to verify they're holding the private key for the address before the transaction can take place.
Yet here we are.
Why doesn't it count and why does it matter how Gmail works behind the scenes?
The same thing was done on the bitcoin chain, e.g. counterparty[0] was relying on a "proof of burn" which was basically "Send BTC to a black hole".
There's a reason some contracts (in the regular legal world) are illegal.
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?
... Lest anyone ever think Blockchain tech is somehow immune to network effects and social considerations.
But, yes, blockchain stuff is fundamentally based on consensus about what the rules are, and people/organizations with more social influence can [...] .
... Reminds me of another financial infrastructure I know.
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.
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.
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.
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.
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.
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.
> 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.
I still find the wire transfer comparison lacking, mostly because one shitty design does not justify another.
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.
I tend to agree. Dumbasses clearly designed this system if it allows money to be accidentally destroyed. Dumbasses doing dumbass things indeed.
But if you use any of the exchanges you described, you have to trust that they 100% know what they're doing.
It seems safer to avoid smart contracts and cryptocurrencies altogether.
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.
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.
This passes the "does it sound like email?, it might be decentralized!" smell test, anyway.
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.
We need to re-write this in Rust before there can be universal acceptance!
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.
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.
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.
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.
How is this not invalid?
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'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.
That's not entirely true. Just look at one of the many burn addresses that people willingly send money to all the time, for example: https://etherscan.io/address/0x00000000000000000000000000000...
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.
This transfer was a transfer from one address to another. No one has ever wanted to do that? It's the entire point of cryptocurrencies!
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.
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.
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?
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.
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?
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.
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.
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.
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?!
Reality is not that simple.
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.
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.
Nothing has vanished or been removed.
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.
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?
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.
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.
If you sent a IBAN transfer someone will get the money. You transfer to someone else that gets the money and you could try to go to court.
The money just doesn’t disappear like in crypto.
The e-mail is a great example, the e-mail can be lost, thats why no bank ever made transfer over email! You loose the e-mail text, not 500.000$!
> 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.
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.
Why, is there a way to send currency directly and irrecoverably into a paper shredder on the inside?
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...
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.
No one sent any currencies into a "shredder", so not sure why you're asking this question?
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.
And yes I'm aware the lady in the case suffered and it's terrible. I'm just being facetious
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.
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.
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.
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.
Its not like going to a shell and putting a random command. It was one of the most used GUIs for crypto!
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.
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.
Oh, yes, I'm one of those 'normies' or 'MBA Suits' (!) who can't possibly understand the genius and vision of Crypto and Blockchain.
We see it is a 'Pyramid Scheme Scam' at worst, and completely useless distraction at best, because we're just not enlightened.
You got me.
Isn't it the "contract" that is supposed to be the "smart" thing here?
> effectively bypassing the safe-guards that are already in place (even without exchanges) to prevent issues.
YTF aren't these "safe-guards" built into the "contract", if it's supposed to be so "smart"?
Even the most stupid ordinary non-"smart" conversion program has the "smarts" to reject invalid input, not confiscate it.
This whole Crypto/Blockchain business is so obviously bullshit all the way down.
> 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.
"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.
Despite the protestations of advocates, this kind of thing is a major hurdle to adoption.
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.
"Any sufficiently advanced smart contract system is indistinguishable from Magic the Gathering (tm)."
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.
An „off by one“ typo cannot occur.
Especially in the tech age where they seem to think they're beyond physical keyboard typos and OCR errors.
You can optionally register your email with the central system for autodeposit.
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?
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.
"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."