[heliumcraft]

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

[kerkeslager]

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.

[heliumcraft]

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.

[kerkeslager]

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.

[heliumcraft]

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.

[kerkeslager]

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

[heliumcraft]

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.

[isolli]

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.