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.

In this case, not really. User was calling a "ROM"

What you describe are dry runs.

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.

"simply Google search would have showed them the way"

That is how high toxicity systems get made.

There is a difference!

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.

Well, there's about $3B worth of WETH issued and only about $1.1M worth of those have been lost due to mistakes like the OPs.

I think that people are so unlikely to fuck this up that such a check would be rather pointless.

Again NASA would disagree.

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.

Should this mess endure, people will just keep using dollars and other fiat currencies.

>Again NASA would disagree.

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

This is also how high toxicity systems get made.

The real solution is better client software. Doing these checks on the client-side is free, that's where they should live.

It would be stupid to put these checks in the contract, they would be very expensive and only help people using unsuitable client software.

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

>You feel all client software will be suitable?

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.

But it just won't. You read it here first.

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.

I am quite happy to be proven wrong.

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?

There's a ton of money in providing good wallet software. Many people are making a killing by offering good UX, as offering good wallet software puts them in a prime position to offer profit-generating value added services like currency swaps.

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

Sidebar:

How come such a check is so damn expensive?

It should not be.

I agree with you big time. This is hopefully something we'll see addressed by smart contract platforms in the coming years or decades.

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.

Yes! It is all very interesting, but way too rough, IMHO.

TL;DR: They could have got it right. Didn't.

Yes, and that code had bugs.

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.