"contract" is a very poor term since it's often confused with real-life legal contracts. A contract is just code, and the DAO attacker exploited a flaw in one of the methods of the code to do something it was not intend to. It is an attack just like finding some flaw in a bank login system to steal money does not make it okay nor legal.

> Lastly, if they'll fork for one bad contract, why not fork for all bad contracts?

It's not easy to a HF of this nature, there was a lot of discussion for a consensus to come about. In that case the funds were also effectively locked for a time in a single address so it was much easier to do a change to return those funds. the % of eth at the time was also enormous (around 15% of the supply) and arguably enough to cause problems later with future updates like proof of stake.

Okay, that's one way of looking at it, but the core value proposition of Ethereum over i.e. Bitcoin was that you could write contracts. Whether or not they've succeeded at that goal, they're called contracts because the goal was for them to be contracts.

If you're saying that they have failed at that goal I'd agree. The contract language they implemented is too error-prone for writing secure contracts, and the only solution they have is to break every contract in the system except the one large enough to perform a 51% attack on the blockchain.

But if we call these programs or code instead of contracts, are they useful for anything? Why would we invest our wealth in programs that lose that value if the code isn't unrealistically bulletproof and the largest program in the system? Calling it a program instead of a contract doesn't make it any less useless.

The main core value proposition (at least for me) is as an consensus layer for creating truly decentralized applications with a truly distributed and decentralized infrastructure, these applications don't necessary have money involved (ENS being an example). In this sense "smart contracts" are actually just pieces of code you deploy pretty much like one would with aws lambda, which is why the term "contract" is a bit confusing, but alas we're stuck with it now.

That's a lot of buzzwords you've got there. Call them contracts/programs/applications/whatever--whatever you call them, they're fundamentally broken, and not decentralized. If you write your code in their language, it's error-prone, and if you somehow manage to write it correctly, the DAO might reverse your code by hard forking. Rebranding contracts with a bunch of buzzwords doesn't fix the problem.

I was trying to be precise on what I meant and not using buzzwords or rebrand anything. It was being asked what was the value proposition and for many of us in the space the decentralized infrastructure and its implications is it. Often Ethereum is seen through a Bitcoin lenses in which contracts are just bells and whistles on top and that's not really what Ethereum is about.

Regarding the programming language, please note there is VM and Solidity is but one language (although by far the most popular currently) that compiles to bytecode for this VM. Much more restrictive/secure programming languages can be created for this VM and we'll likely see more work towards this as development continues, it's likely in the future developers will use different languages depending on the usecase they are trying to implement on the blockchain. Also in regards to the code deployed (the contracts) they can be decentralized, but contrary to popular belief they can also be as centralized as one wants in order to be possible to an update if something goes wrong. However in either case the Infrastructure remains distributed and decentralized.

Regarding the other comments: "if you somehow manage to write it correctly, the DAO might reverse your code by hard forking" and "the only solution they have is to break every contract in the system except the one large enough to perform a 51% attack on the blockchain."

In one sentence it sounds like you're saying the DAO contract somehow reverses 3rd party correct code, and in the other that every contract gets broken (?) except one contract because it's large? and the contract (?) performs a 51% attack on the blockchain (?)

Honestly I don't understand those sentences which is why I didn't address them, I mean you no offense.

> Regarding the other comments: "if you somehow manage to write it correctly, the DAO might reverse your code by hard forking" and "the only solution they have is to break every contract in the system except the one large enough to perform a 51% attack on the blockchain."

> In one sentence it sounds like you're saying the DAO contract somehow reverses 3rd party correct code, and in the other that every contract gets broken (?) except one contract because it's large? and the contract (?) performs a 51% attack on the blockchain (?)

Yes. When the DAO broke, the Ethereum community banded together and performed a 51% attack on the Ethereum block chain, potentially breaking every other contract in the entire system, even correctly coded ones.

Calling it an attack is a bit weird. Attacks are typically meant to things like create double spends. An hard fork is the natural mechanism for a blockchain to update. The Homestead release for example was an update that was done through an HF, the next update Metropolis will also be done through a HF.

For the DAO HF: The DAO contract was replaced by a withdrawal one, that was the only change, No other contract broke because of the fork.

Yet the whole point of smart contracts was that the code is the contract. Descriptions of what the contract was seeking to achieve were explicitly non-binding. It will be an interesting legal case if something like this ever goes to trial.

> Lastly, if they'll fork for one bad contract, why not fork for all bad contracts?

Conceptually, they would, it's just that DAO was an exceptional case.

a) The amount was really large. b) Ethereum ecosystem wasn't mature enough (and yesterday's event proved that they can take a hit like that and survive). c) DAO had a 30 day lockdown of the hacker's fund, this is something which allowed for a hard fork to be possible.

The last is really important. Once hacker gets your money out of the hacked contract, no hard fork is feasible. The DAO essentially created a situation where it was impossible for hacker to get the money, nor for the white hat hackers to get the money. Both could have created a script, where hacker would move his funds to a new child contract, and the WHG would follow him to the child contract (thus essentially rendering him unable to get his money out).

> Once hacker gets your money out of the hacked contract, no hard fork is feasible.

Why wouldn't it be feasible? Have all users update to a version of the client which artificially corrects for the balances of the hacked wallets. Isn't anything possible with a hard fork?

Anything is possible, but it gets much harder once the money is in circulation. If the hacker has time to buy socks & soap with the stolen funds, and convert some of it to USD on an exchange - then the soap merchant and exchange will not want their wallets "corrected".

Sorting out who should get their money returned and who gets to keep it would be infeasible.

"That said, if I understand it, the "attacker" was just the first person to truly understand the contract and exploit that understanding, no? If what happened isn't what the creators of the contract intended, then that's the fault of the creators, not the "attacker"."

I would go even further and suggest that the user (not "attacker") of this ethereum contract proudly stand up and identify themselves - without fear of retribution.

This individual played their game by their rules.

They are not an attacker, this was not a hack, and nothing was stolen.

How is this any different than exploiting a web application via something like SQL injection? After all, their implementation legally allows you to supply inputs containing those characters and their system responds by doing whatever with the database. Is that fundamentally different than supplying "expected" input and getting expected outputs?

"Your program just computes a different function than you expected and I supplied legal inputs" can be used as a defense of literally all software exploitation.

He or she shouldn't just stand up and identify themselves, they should claim their right. It would in a way be the ideal case to litigate.

It's a glorious hack in the original sense of the term.

If you were watching a building go up in flames due to arson, exasperated by faulty construction and you knew there were people inside you could save what would you do?

I'm pretty sure you wouldn't just say "It's their own fault for living there and it's also the construction company's fault for not carrying out safety tests. Let them burn because intervening now will only let the construction company & tenants off the hook - they all should have known better."

That's essentially what happens in real life in some places: Don't pay for the fire department (although you should have known better) and in case of a fire the fire department will protect your neighbor's house, but will watch as your house burns to the ground: http://www.kfvs12.com/story/13281481/fire-chief-responds-to-...

Worth noting that it doesn't work like that for the overwhelming majority of residences in the US. Only places where you have to pay a specific fire subscription.

I dislike this analogy as I hold human life in a much higher regard. If you replace people with something like "property with no sentimental value" then the anology would be closer, but still imperfect. In that analogy, I would give pause but "letting it burn" would be much more palatable.

No harm to any sentient being was caused by the unintended DAO usage ("hack").

A more apt comparison would be: Someone found a flaw in my distributed MMORPG and now the game isn't interesting / useful anymore to some people. Should we collectively change the rules, even though we previously committed to not doing so? And before you say "Ethereum is no game", consider how serious some people take their gaming worlds and how much resources (time and money) they invest.

No, but we're not talking about human lives. We're talking about an ecosystem that is, as I understand, built on the premise that code is law. I may be mistaken.