> They clearly did NOT intended to give the coins away.

They designed a cryptocurrency with a floating value that went up or down according to certain rules. Someone read these rules carefully and then borrowed billions of dollars of capital to play the game, according to the rules, in a way that moved the value in their favor.

This isn't like a remote code execution attack because OS designers aren't planning features that allow unauthorized remote code execution.

This is more like an options trade that didn't work out because someone with more money used their capital to blow up the trade. You can't make a bad trade in the stock market and then argue that your loss was a "bug" because you intended to make money, not lose money.

I like your line of reasoning, however, apparently the mechanism the attacker used was patched. According to your logic, this is the fundamental design of the system, and should be impossible to patch. That makes me more inclined toward the belief that this was a bug in their code.

The patch changed the design of the system. They obviously didn't forsee the flaw in their system but it's not like someone found a buffer overflow - they only used the levers and buttons that the system provided them to perform this 'attack'.

If u take money from an open bank door, u aint gonna be waved off with a laugh and good day. Just because u picked the lock using the mechanisms provided, doesnt mean u didnt steal the bounty.

Code is law will only lead to SkyNet.

The subjective element to legal interpretation is why our legal system is not purely algorithmic.

If it was, people will argue malicious compliance like you are, but intent has to be considered, both the intent of the developer and the intent of the exploiter (or loaner, is maybe a less loaded term for them)

“Someone read the rules carefully, then borrowed capital to move the rules in their favor”, you could say the same thing about an integer overflow, both are attacks of excess, with intent for massive personal gain, outside the intended use case of the system

I'm not so sure. Contract law is complex and even if the software is considered a legal contract, the law doesn't always side with pure technicality. For example if a contract indicated that John Doe must pay me $100 for services rendered and then the time to pay up arrives and Jon claims he doesn't have to pay because the contract says John must pay. But he's not John, he's actually Jon. That isn't going to fly because the intent that Jon pay is clear.

> This is more like an options trade that didn't work out because someone with more money used their capital to blow up the trade. You can't make a bad trade in the stock market and then argue that your loss was a "bug" because you intended to make money, not lose money.

100% Agree you can also look up trading patterns on option expiration Fridays to see people making sure that their trades 'work out'

By this logic, a buffer overrun exploit would not actually be an exploit, because it's just a pointer that goes up or down according to certain rules.

Incorrect. A buff we overrun injects new code into the system that gets executed that was never part of the original system.

This is more like setting your screensaver or debugger to cmd.exe on windows NT and waiting for an admin process to crash or the screensaver to start. (I forget exactly how it worked)

I’d compare this “exploit” to playing a coin pusher type gaming kiosk with an especially large bankroll and statistical analysis to determine optimal play strategy.

If someone chose to play such a game intending to win and with appropriate planning to ensure wins through optimal play, I wouldn’t call that an exploit at all. It’s beating the game, and the owner may ban you from playing it, but no laws were broken by you playing it in such a manner with larger than average capital. But your winnings are yours, fair and square.

> their intended system design was obviously flawed

No, the design was so complex that its flaws were well hidden, and therefore not intended.

Quoting C. A. R. Hoare:

“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”

> No, the design was so complex that its flaws were well hidden, and therefore not intended.

That’s no less true for a Chrome sandbox escape.

In fact, this Ethereum loan platform’s behavior is encoded in program source codes, just like Chrome. One expects that some exploitable issues in the Chromium code arise not from syntactical but conceptual errors. The code could match a mistaken programmer intent, and this often happens.

> They clearly did NOT intended to give the coins away.

I frequently make decisions that don’t turn out as I intended. You need a distinction between whether the outcome is what you intended and whether the process is what you intended. It isn’t a clear line.

Even if this is true, what in the world is the point of crypto platforms if courts need to step in and decide intent whenever someone doesn't like the outcome of a transaction?

> what in the world is the point of crypto platforms

Excellent question, one that crypto dudes could ask themselves a little more often.

The point is to speculate in assets hidden from the tax man while destroying the environment. So far, crypto is still living up to that promise.

It is the wet dream that some 100 line script will eventually become the only and unbiased arbiter and judge of anything in the world of finance.

You are probably reading this comment and thinking "yeah, hah, naive fools". About as naive as the fools, that believe in a 100 line program, that gives you a puzzle that nothing will realistically ever be able to solve, yet the program could tell immediately if the solution is wrong or right.

The difference, I think, is that builders of other systems usually don't say "We don't need law enforcement to tell our users what they can and cannot do, because what is allowed is clearly written in code, and the code triumphs everything else. That's the major selling point of our system."

A bug implies a software defect. This however sounds like a design defect.

No, you can't say that about every bug. Many bugs occur in the implementation of systems, not in the design. That was not the case here. The system was implemented as designed.