> The theft wasn't due to an issue in the core protocol of Ethereum

True enough, but what the parent pointed out is that this class of problems is due to a flaw in the core concept of Ethereum - which is much worse than just a flaw in the protocol.

To extend your analogy - Ethereum is like if a company advocated for building bridges using a process that made the bridge's integrity unverifiable using traditional engineering means. Some bridges may hold up, some may fail, with no clear way to identify which bridges will do what.

I understand your counterpoint, but I don't think it's accurate. I mean, if it isn't verifiable, then how would it at all be exploitable, and then patchable?

Even so, any product designed for the network could be tested to death on any of the available testnets. It would be foolish not to ram any project up against everything in that environment, which is why I suggest poor practice as a primary cause.

It was an oversight, to be sure, and a major one. (that's not nearly strong enough language, but I want to be civil)

> I mean, if it isn't verifiable, then how would it at all be exploitable, and then patchable?

Let's assume you're right and smart contracts are verifiable. Verifiable by whom? I can assure you that my non-techie friends could not verify a smart contract themselves, so they will have to trust some authority that verifies the contract for them. The chain of trust now moves entirely into meatspace again and will be subject to the same economic and social forces as existing financial systems. So what has Ethereum accomplished other than adding an automated intermediary to transactions?

For a real-life example of what this might look like consider HTTPS. In theory SSL allows you to cryptographically verify the identity of the site you're looking at. In practice your ability to do this is still bounded by the competence of third parties like browser vendors and the integrity of CAs issuing certificates.

Well you've picked up on very difficult bit of semantics, and one that is probably worth its own discussion entirely.

The code is verifiable by a skilled engineer (in good faith) -- so there is a catch. Any body that produces a smart contract requires the trust of those who take part. Alternatively, it requires trust in one's own expert engineer to verify the content and functioning of a smart contract.

Where Ethereum is trustless is in the execution of the contract once verified. There is then no course for non-delivery if the code is designed this way.

So, it's trustless at one level, and requires trust at another. When I say it's semantics it's just this last point.

Personally I don't see the problems other see with that, because I don't see blockhain tech and tokens replacing everything all in one go, including the need for governing bodies and law. I don't see it as a choice between one or the other. For what it's worth, I'm closer to a socialist than the usual libertarian ranks that flock to these things. I think the world would benefit from the efficiency it could bring about, once the kinks are worked through.

I have zero domain expertise in cryptocurrencies or Ethereum, but much experience with unexpected failures of "guaranteed" things and processes.

To use your analogy - I'd view the bridge design engineer as having guaranteed that the design process could not possibly result in construction of a bridge that fails. That seems closer to what Ethereum would have us believe.

A bridge design domain expert presumably understands: - that design process uses strut calculations (and therefore includes measures to guarantee those calculations can never be wrong); - that bridges may be built from steel (and therefore includes inspection routines that guarantee faulty steel can never be used); - that the environment acts on bridges through corrosion and earthquakes (and therefore includes routines that absolutely always preclude failures arising from the bridge's environment); - etc., etc., etc.

Maybe it's just my ignorance or misunderstanding of this domain, but I see Ethereum as naive in its guarantee of perfectly predictable behavior.

A guaranteed flawless protocol that fails (for whatever reason) when implemented in reality, isn't.

In your description I still take away that the root problem isn't in the technology, but in the engineer's implementation. Even a calculation that is guaranteed to produce the correct results [if implemented poorly or with errors or with exclusions] can fail.

The engineer who wrote the contract appears to have made a critical logical error.

That does bring me to your conclusion, though. I've paid less attention to the marketing and promises and have assessed the technology as-is (within the confines of my knowledge) -- as such I see what's possible instead of seeing it as a product that under-delivers.

I wonder if a lot of people (especially on HN) would view it differently if it weren't for such bold claims on the developers' part. I mean, I think you're probably right in it being naive in its guarantee of predictability. I think any actors on the platform should assume its supposedly perfectly predictable behaviour is not quite so when they take to designing software or a contract. But that's part of what I meant when I've said it comes down to engineering practice -- when it comes to critical systems assumptions just shouldn't be made in young technology no matter what anybody tries to sell you.

Well, the original comment that I excerpted from was discussing the flaw in the very idea of smart contracts superseding human-readable agreements (ie, "the code is the law, and anything we say about the code is just so much noise").

So, yes, in reposting I generalized from "smart contracts are a bad idea" to "Ethereum is a bad idea". Considering how essential the smart contract is to essence of Ethereum, I feel comfortable making that generalization.

Side note: "the essence of ethereum" would make a great subtitle for Drakkar Noir.

Well for one, perhaps systems should not be designed in such a way that a single flaw or mistake brings down the entire system...

Absolutely. A critique one could also point at TCI/IP before anyone running servers began to load balance their websites and other services.

Would you blame the the steel (or the concept of bridges in whole) for the Tacoma Narrows bridge waving in the wind?

The whole point of TCP/IP was understanding that networks are unreliable, and introducing schemes check for the receipt of packets, handling lost ones, and changing connection parameters dynamically so fewer packets would be lost in the future.

In essence, TCP/IP is engineers trying their utmost to design a system where a single flaw doesn't result in the whole data stream being corrupted.

Add HTML browsers into it, which is extremely tolerant of input mistakes and you have a total system that will handle random losses pretty well.

That is until somebody writes a simple script to utilize the protocol to overload an end server with requests, then a server not equipped to handle such a load will fail due to an exploit that wasn't immediately obvious (of course it is now. It's an assumed part of best practice for any large project.)

The protocol doesn't offer any recourse itself, and the end user who might suffer because of such an attack has no defense. They rely on the ability of the engineers involved and some technical voodoo they don't understand to keep everything safe and working for them. That's my point -- I wasn't comparing the technologies directly, but their roles in a larger system.

Solidity is a pretty core part of Ethereum at this moment. It is demonstrably utter garbage, as this bug illustrates.