7 ms·

The sad reality of Ethereum: 1. Bitcoin is slow and expensive, Ethereum is the future 2. Ethereum software has security hole, gets hacked 3. Ethereum fans say i

by kbody 9y ago

The sad reality of Ethereum: 1. Bitcoin is slow and expensive, Ethereum is the future 2. Ethereum software has security hole, gets hacked 3. Ethereum fans say it's an experiment there are lots of things that will transform Ethereum (Casper/PoS, Raiden, zkSNARKs, Enterprise Alliance) 4. Low price getting pumped by Ethereum Foundation & big-holder affiliates 5. Back to #1 We've seen it happen again (DAO) and again (Parity) and it will keep happening, because it's broken by design. 90s cypherpunks that pioneered this ideas had considered Turing complete design and discarded it for cryptographic state-machines that allow for formal verification. I appreciate the experimentation, but the takeover-the-world echo-chambers of ethereum that don't focus at all on the real tech behind it and ignore everything negative is pretty disappointing. Especially because we keep getting new people buying this and becoming the greater fools. When talking about engineering on such a critical subject, people should be way more responsible. If Bitcoin had the same attitude regarding security like Ethereum does, we wouldn't be here and cryptocurrencies would be a joke. Lazy engineering comes at great cost as time goes by and the illusion of security is unveiled.

DalasNoin 9y ago
"but the takeover-the-world echo-chambers of ethereum that don't focus at all on the real tech behind it and ignore everything negative is pretty disappointing" i dont think this is a good representation of the ethereum community, most people on r/ethereum for example are quiet self conscious about the security issues. that is at least my impression from reading the threads there.
mbrock 9y ago
The belief that Turing machines aren't amenable to formal verification is a hobgoblin that shows up in every thread like this, but it's not real. Of course there are limited formalisms that make certain types of verification easier, but proving programs has been possible since, like, the 1960s. A multisig, for example, has a finite number of states when considered under symbolic execution. A model checker can rip through it and prove whatever properties you want. Is the Ethereum world right now full of buggy contracts that haven't been proven correct? Yes, absolutely. It's a disaster. But it's a disaster that points the way fairly straightforwardly. Should Ethereum not have been launched until it had solid methods for auditing and proving? Maybe, but that's not how the world works, typically. Worse is better and all that.
- merijnv 9y ago
  Sure, you CAN verify Turing machines, but verifying languages that AREN'T Turing complete is sufficiently simpler. So why not make your verification work easier by using a total language? The only real argument against that would be "we can't do what we want in a total language". I don't buy the argument that what people want to do with smart contracts requires Turing-completeness. In fact, as time goes on I become more and more convinced that Turing completeness is highly overrated. Almost all code wants to do finite and/or structurally inductive operations. The only case that doesn't fall in that are things like request loops where you want to "infinitely" wait, process request, loop back to waiting. But even those things can be done in total languages via co-induction, so exactly why do we want to make our analysis/verification work more difficult by using a non-total language for things like Ethereum?
  - mbrock 9y ago
    The real answer is probably that total languages are obscure and the Ethereum inventors didn't know about them so they chose a simple and ordinary stack machine. But those total systems are, of course, subsets of Ethereum, which means that if you write your program in an obviously finite way, you can use the same inductive proofs you would use for a total language. Turing completeness makes it hard to prove properties automatically about arbitrary programs, but you can still prove properties about specific programs. I'm pretty sure that MOST research on program verification has been done in the context of Turing complete systems, from the work of Floyd and Hoare, to the symbolic execution of Deutsch and King, to temporal logic, TLA+, etc.
    - seanwilson 9y ago
      > The real answer is probably that total languages are obscure and the Ethereum inventors didn't know about them so they chose a simple and ordinary stack machine. I'm not an expert on Ethereum, but even if they did pick a total language, how would you deal with bounding the CPU cost of complex contracts? Even if you could formally verify a loop would eventually terminate, wouldn't long running loops or those with expensive computations have bad impacts on the network? Their "gas" system is their way of dealing with that and perhaps you would still need something similar even with a total language. I can't think of program verification research where both termination and CPU cost is verified. I can think of some papers that deal with identifying Big Oh growth rates though. Either way, smart contracts sound like one of the top tier areas where you want strong static typing that has a route to be formally verified.
guscost 9y ago
> the takeover-the-world echo-chambers of ethereum You toss out this pejorative description, and then in the next paragraph: > When talking about engineering on such a critical subject, people should be way more responsible. This is absurd. How could it ever become critical without a lot of research and development first? I've been holding a handful of Ethereum since there was a decent dip in the price. I haven't spent much time on it and I have no good leads for program ideas yet, but if the code is buggy and I get hacked and lose my investment, that's fine. A smart contract is a project, and it could fail like any other. Don't put your retirement savings in a smart contract right now unless you're OK with losing it all. Maybe in the future Ethereum will move beyond this phase, and maybe not. All the drama is ridiculous, everyone needs to chill out.
- lawless123 9y ago
  >"I've been holding a handful of Ethereum since there was a decent dip in the price. I haven't spent much time on it and I have no good leads for program ideas yet, but if the code is buggy and I get hacked and lose my investment, that's fine. A smart contract is a project, and it could fail like any other. Don't put your retirement savings in a smart contract right now unless you're OK with losing it all. Maybe in the future Ethereum will move beyond this phase, and maybe not. All the drama is ridiculous, everyone needs to chill out." This is the exact spiel we're all sick of hearing.
  - guscost 9y ago
    Which part do you have a problem with?
    - lawless123 9y ago
      >I've been holding a handful of Ethereum since there was a decent dip in the price. You opened by explain how you clearly have an interest in this, you got in, and since you are saying you bought during a "decent dip" that means you only got in recently. The rest of your post would be shilling only that you disclosed your interest.
grey-area 9y ago
When it comes to contracts I think a more interesting idea is a limited formal expression of them and thus automatic production and evaluation/translation/summaries (would require a formal spec for each domain with very limited options), not a Turing complete expression of them which as you say leaves too many holes. Also tying all of this to a currency and payments makes zero sense and just expands the attack surface massively. Just fixing contract law with automated checks of contracts would be a huge opportunity/challenge.
KirinDave 9y ago
The other sad thing is that Solidity, the language of Etherium, is a trainwreck. It has tons of bugs, properties that maximize the memory cost of the program, and until ~6 days ago had crazy double init bugs in constructors using "this".
- DennisP 9y ago
  Looking at Solidity's release log, the last update was 18 days ago. It fixed some minor bugs from the previous release three days prior, and none of the bugfixes mentioned in the previous release seem to fit your description. Do you have a link? https://github.com/ethereum/solidity/releases https://github.com/ethereum/solidity/releases
  - amouat 9y ago
    A look at the recent commits would suggest they are correct: https://github.com/ethereum/solidity/commit/e506129aee5745e2b7bc8f4b96dcaa8adcc2c2ea https://github.com/ethereum/solidity/commit/e506129aee5745e2...
    - DennisP 9y ago
      That's just an added warning, not a bug fix.
      - KirinDave 9y ago
        Indeed, I mistook the added warning and ticket close for the real fix. I'm sorry, 18 days, not ~6. I said 1/3rd the real duration. Since Solidity has only been around about 800 days, 12 days is a non-trivial error. Still: my complaint that the language is poorly architected and dubiously implemented and tested stands.
        DennisP 9y ago
        I still don't see a bugfix that matches your complaint. The warning is about the compiler behaving as designed; it's for programmers who are probably using that behavior incorrectly. Solidity definitely has design warts; possibly Viper will end up the leading language, once it's production-ready.
ekidd 9y ago
> 2. Ethereum software has security hole, gets hacked The last time this was discussed on Hacker News, I found this comment particularly instructive: https://news.ycombinator.com/item?id=14810008 https://news.ycombinator.com/item?id=14810008 It points out a great many fundamental issues with the Solidity contract language. Basically, the language design sounds extremely amateurish and it appears to have ignored everything we've learned about security in the last 30 years. Samples: - "Operators have different semantics depending on whether the operands are literals or not. For example, 1/2 is 0.5, but x/y for x==1 and y==2 is 0." - "All state is mutable by default (this includes struct fields, array elements, and locals). Functions can mutate state by default" - "Order of evaluation is not defined for expressions. This in a language that has value-returning mutating operators like ++!" I wouldn't trust a Solidity smart contract with $100.
- grogenaut 9y ago
  I hate immutable variables because I'm lazy but I would definitely use them as a feature in a system like this. Maybe I should reconsider using erlang or my position on immutble variables... Nope that's enough self discovery for today... Carry on. Edit: And again erlang people can't take a joke. I'm literally making fun of myself for having an invalid bias and erlang folks take it as an attachment on the language. It's also a commentary on how long it takes for devs to mind shift and incorporate new ideas.
  - pmahoney 9y ago
    There are two distinct features: immutability and single-assignment. Erlang is famous for single-assignment, and also happens to have largely immutable values, but they are not the same thing. Immutability prevents things like in-place appending to an array, or in-place modification of a string. Single-assigment means that the value bound to "someVariable" cannot be changed. E.g. `someVariable = new String("hello"); someVariable = new String("goodbye");` is illegal. But it still may be possible to mutate the value `someVariable.substitute("hello", "goodbye")` if the language allows mutation.
- deleted 9y ago
  [deleted]
hellbanner 9y ago
"90s cypherpunks that pioneered this ideas had considered Turing complete design and discarded it for cryptographic state-machines that allow for formal verification" - are you referring to Bitcoin? Or some other ideas that aren't currently implemented?
macmee 9y ago
> Ethereum software has security hole, gets hacked The exploits so far were NOT security holes in ethereum, they were poorly written smart contracts by third parties.....
- touhonoob 9y ago
  That's pretty like early days of web development when people write SQL-injection vulnerable code on daily-basis
theptip 9y ago
Worth mentioning that there is at least one other language being built on top of the EVM: https://github.com/pirapira/bamboo https://github.com/pirapira/bamboo This one takes a strict state machine approach, and aims to solve some of the tricky reentry and state tracking problems of Solidity.
bguy74 9y ago
This would be compelling were it to contain accurate information. However, likening the parity incident to a "hack of ethereum" is like saying the USD is flawed because wells fargo was broken into. The same thing is true for the DAO, although it is indeed more complex in that the _resolution_ of it was handled by Ethereum proper. I think that was questionable. Literally no one within Ethereum calls it an experiment. You have to cherry-pick from population and then ascribe it to the whole for this to be even sensical. Essentially every technology we can think of can be rooted back to the 90s, or really any period we want to look at since that is how knowledge works. If you've got a particular, say it...rather than just this poor, lazy attempt at a sort of character assassination by employee (fairly inaccurate) appeal to oldness. It is thoroughly _without merit_ to suggest that the analogous components of ETH and BTC have BTC being more secure. In fact, the opposite is true by any reasonable measure. Further, there are indeed things that Ethereum tries to do that add complexity, but if they come with value we shouldn't then find ourselves saying things like you do that amount to a sort of "my abacus is more secure than quickbooks online" - different purposes, solving different problems and creating different sorts of value. Even beyond that BTC holds all records for security events and $ cost of them, coin-loss amounts of of them, and so on.

by kbody 9y ago

DalasNoin 9y ago

"but the takeover-the-world echo-chambers of ethereum that don't focus at all on the real tech behind it and ignore everything negative is pretty disappointing" i dont think this is a good representation of the ethereum community, most people on r/ethereum for example are quiet self conscious about the security issues. that is at least my impression from reading the threads there.

mbrock 9y ago

The belief that Turing machines aren't amenable to formal verification is a hobgoblin that shows up in every thread like this, but it's not real. Of course there are limited formalisms that make certain types of verification easier, but proving programs has been possible since, like, the 1960s. A multisig, for example, has a finite number of states when considered under symbolic execution. A model checker can rip through it and prove whatever properties you want. Is the Ethereum world right now full of buggy contracts that haven't been proven correct? Yes, absolutely. It's a disaster. But it's a disaster that points the way fairly straightforwardly. Should Ethereum not have been launched until it had solid methods for auditing and proving? Maybe, but that's not how the world works, typically. Worse is better and all that.

merijnv 9y ago
Sure, you CAN verify Turing machines, but verifying languages that AREN'T Turing complete is sufficiently simpler. So why not make your verification work easier by using a total language? The only real argument against that would be "we can't do what we want in a total language". I don't buy the argument that what people want to do with smart contracts requires Turing-completeness. In fact, as time goes on I become more and more convinced that Turing completeness is highly overrated. Almost all code wants to do finite and/or structurally inductive operations. The only case that doesn't fall in that are things like request loops where you want to "infinitely" wait, process request, loop back to waiting. But even those things can be done in total languages via co-induction, so exactly why do we want to make our analysis/verification work more difficult by using a non-total language for things like Ethereum?
- mbrock 9y ago
  The real answer is probably that total languages are obscure and the Ethereum inventors didn't know about them so they chose a simple and ordinary stack machine. But those total systems are, of course, subsets of Ethereum, which means that if you write your program in an obviously finite way, you can use the same inductive proofs you would use for a total language. Turing completeness makes it hard to prove properties automatically about arbitrary programs, but you can still prove properties about specific programs. I'm pretty sure that MOST research on program verification has been done in the context of Turing complete systems, from the work of Floyd and Hoare, to the symbolic execution of Deutsch and King, to temporal logic, TLA+, etc.
  - seanwilson 9y ago
    > The real answer is probably that total languages are obscure and the Ethereum inventors didn't know about them so they chose a simple and ordinary stack machine. I'm not an expert on Ethereum, but even if they did pick a total language, how would you deal with bounding the CPU cost of complex contracts? Even if you could formally verify a loop would eventually terminate, wouldn't long running loops or those with expensive computations have bad impacts on the network? Their "gas" system is their way of dealing with that and perhaps you would still need something similar even with a total language. I can't think of program verification research where both termination and CPU cost is verified. I can think of some papers that deal with identifying Big Oh growth rates though. Either way, smart contracts sound like one of the top tier areas where you want strong static typing that has a route to be formally verified.

guscost 9y ago

> the takeover-the-world echo-chambers of ethereum You toss out this pejorative description, and then in the next paragraph: > When talking about engineering on such a critical subject, people should be way more responsible. This is absurd. How could it ever become critical without a lot of research and development first? I've been holding a handful of Ethereum since there was a decent dip in the price. I haven't spent much time on it and I have no good leads for program ideas yet, but if the code is buggy and I get hacked and lose my investment, that's fine. A smart contract is a project, and it could fail like any other. Don't put your retirement savings in a smart contract right now unless you're OK with losing it all. Maybe in the future Ethereum will move beyond this phase, and maybe not. All the drama is ridiculous, everyone needs to chill out.

lawless123 9y ago
>"I've been holding a handful of Ethereum since there was a decent dip in the price. I haven't spent much time on it and I have no good leads for program ideas yet, but if the code is buggy and I get hacked and lose my investment, that's fine. A smart contract is a project, and it could fail like any other. Don't put your retirement savings in a smart contract right now unless you're OK with losing it all. Maybe in the future Ethereum will move beyond this phase, and maybe not. All the drama is ridiculous, everyone needs to chill out." This is the exact spiel we're all sick of hearing.
- guscost 9y ago
  Which part do you have a problem with?
  - lawless123 9y ago
    >I've been holding a handful of Ethereum since there was a decent dip in the price. You opened by explain how you clearly have an interest in this, you got in, and since you are saying you bought during a "decent dip" that means you only got in recently. The rest of your post would be shilling only that you disclosed your interest.

grey-area 9y ago

When it comes to contracts I think a more interesting idea is a limited formal expression of them and thus automatic production and evaluation/translation/summaries (would require a formal spec for each domain with very limited options), not a Turing complete expression of them which as you say leaves too many holes. Also tying all of this to a currency and payments makes zero sense and just expands the attack surface massively. Just fixing contract law with automated checks of contracts would be a huge opportunity/challenge.

KirinDave 9y ago

The other sad thing is that Solidity, the language of Etherium, is a trainwreck. It has tons of bugs, properties that maximize the memory cost of the program, and until ~6 days ago had crazy double init bugs in constructors using "this".

DennisP 9y ago
Looking at Solidity's release log, the last update was 18 days ago. It fixed some minor bugs from the previous release three days prior, and none of the bugfixes mentioned in the previous release seem to fit your description. Do you have a link? https://github.com/ethereum/solidity/releases https://github.com/ethereum/solidity/releases
- amouat 9y ago
  A look at the recent commits would suggest they are correct: https://github.com/ethereum/solidity/commit/e506129aee5745e2b7bc8f4b96dcaa8adcc2c2ea https://github.com/ethereum/solidity/commit/e506129aee5745e2...
  - DennisP 9y ago
    That's just an added warning, not a bug fix.
    - KirinDave 9y ago
      Indeed, I mistook the added warning and ticket close for the real fix. I'm sorry, 18 days, not ~6. I said 1/3rd the real duration. Since Solidity has only been around about 800 days, 12 days is a non-trivial error. Still: my complaint that the language is poorly architected and dubiously implemented and tested stands.
      - DennisP 9y ago
        I still don't see a bugfix that matches your complaint. The warning is about the compiler behaving as designed; it's for programmers who are probably using that behavior incorrectly. Solidity definitely has design warts; possibly Viper will end up the leading language, once it's production-ready.

ekidd 9y ago

> 2. Ethereum software has security hole, gets hacked The last time this was discussed on Hacker News, I found this comment particularly instructive: https://news.ycombinator.com/item?id=14810008 https://news.ycombinator.com/item?id=14810008 It points out a great many fundamental issues with the Solidity contract language. Basically, the language design sounds extremely amateurish and it appears to have ignored everything we've learned about security in the last 30 years. Samples: - "Operators have different semantics depending on whether the operands are literals or not. For example, 1/2 is 0.5, but x/y for x==1 and y==2 is 0." - "All state is mutable by default (this includes struct fields, array elements, and locals). Functions can mutate state by default" - "Order of evaluation is not defined for expressions. This in a language that has value-returning mutating operators like ++!" I wouldn't trust a Solidity smart contract with $100.

grogenaut 9y ago
I hate immutable variables because I'm lazy but I would definitely use them as a feature in a system like this. Maybe I should reconsider using erlang or my position on immutble variables... Nope that's enough self discovery for today... Carry on. Edit: And again erlang people can't take a joke. I'm literally making fun of myself for having an invalid bias and erlang folks take it as an attachment on the language. It's also a commentary on how long it takes for devs to mind shift and incorporate new ideas.
- pmahoney 9y ago
  There are two distinct features: immutability and single-assignment. Erlang is famous for single-assignment, and also happens to have largely immutable values, but they are not the same thing. Immutability prevents things like in-place appending to an array, or in-place modification of a string. Single-assigment means that the value bound to "someVariable" cannot be changed. E.g. `someVariable = new String("hello"); someVariable = new String("goodbye");` is illegal. But it still may be possible to mutate the value `someVariable.substitute("hello", "goodbye")` if the language allows mutation.
deleted 9y ago
[deleted]

hellbanner 9y ago

"90s cypherpunks that pioneered this ideas had considered Turing complete design and discarded it for cryptographic state-machines that allow for formal verification" - are you referring to Bitcoin? Or some other ideas that aren't currently implemented?

macmee 9y ago

> Ethereum software has security hole, gets hacked The exploits so far were NOT security holes in ethereum, they were poorly written smart contracts by third parties.....

touhonoob 9y ago
That's pretty like early days of web development when people write SQL-injection vulnerable code on daily-basis

theptip 9y ago

Worth mentioning that there is at least one other language being built on top of the EVM: https://github.com/pirapira/bamboo https://github.com/pirapira/bamboo This one takes a strict state machine approach, and aims to solve some of the tricky reentry and state tracking problems of Solidity.

bguy74 9y ago

This would be compelling were it to contain accurate information. However, likening the parity incident to a "hack of ethereum" is like saying the USD is flawed because wells fargo was broken into. The same thing is true for the DAO, although it is indeed more complex in that the _resolution_ of it was handled by Ethereum proper. I think that was questionable. Literally no one within Ethereum calls it an experiment. You have to cherry-pick from population and then ascribe it to the whole for this to be even sensical. Essentially every technology we can think of can be rooted back to the 90s, or really any period we want to look at since that is how knowledge works. If you've got a particular, say it...rather than just this poor, lazy attempt at a sort of character assassination by employee (fairly inaccurate) appeal to oldness. It is thoroughly _without merit_ to suggest that the analogous components of ETH and BTC have BTC being more secure. In fact, the opposite is true by any reasonable measure. Further, there are indeed things that Ethereum tries to do that add complexity, but if they come with value we shouldn't then find ourselves saying things like you do that amount to a sort of "my abacus is more secure than quickbooks online" - different purposes, solving different problems and creating different sorts of value. Even beyond that BTC holds all records for security events and $ cost of them, coin-loss amounts of of them, and so on.