Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ethereum is Doomed

nakamotoinstitute.org

Post reply on HN
Print view View original

151–160 of 217 posts

Re: Ethereum is Doomed

#151

Post by curiousgal »

DennisP wrote: post #22

I have actually tested this attack technique (using my own contracts on a local test chain), and I've been in discussions with some Solidity developers and the guy who first published the attack. The situation is not as bad as this article claims. For starters, you can use address.send(x) instead of address.call.value(x)(). All computations on Ethereum have to be funded with "gas" (transaction fees), and send() only…

Well Well Well, what do you know, someone who has actually looked into things and not just basing their statements on their anti-crypto beliefs.

Re: Ethereum is Doomed

#152

Post by jbmorgado »

cyphar wrote: post #52
pmorici wrote: post #6

Earlier quoted context omitted.

What _legally_ exploitable bank bugs have you heard of? Keyword there being legally.

This exploit wasn't legal either. It was blatantly fraud. I've asked a lawyer for their opinion and it was a very simple question to answer. Contracts are never entirely literal and usually there are implied clauses in contracts. There is a very simple test called the "officious bystander": if there had been a neutral bystander who had asked "should we allow anyone to take $50 million dollars without our consent" the…

So, you are trying to be a great libertarian by doing without the courts of law and the state but then, when everything goes wrong with your money, you call for the opinion of the courts of law and for the state to enforce that opinion.

Oh the hypocrisy.

Re: Ethereum is Doomed

#153

Post by ianpurton »

DennisP wrote: post #22

I have actually tested this attack technique (using my own contracts on a local test chain), and I've been in discussions with some Solidity developers and the guy who first published the attack. The situation is not as bad as this article claims. For starters, you can use address.send(x) instead of address.call.value(x)(). All computations on Ethereum have to be funded with "gas" (transaction fees), and send() only…

The situation is not as bad as this article claims.

Well it kind of is actually. The people that wrote the DAO script had the script checked by lots of Ethereum experts and the bug slipped through.

So if the Ethereum experts can't stop things like this happening then what chance do individual developers have. Basically creating a turing complete scripting language on the blockchain is not secure.

No financial institution will risk creating smart contracts on this platform.

Re: Ethereum is Doomed

#154

Post by jbmorgado »

erikpukinskis wrote: post #94

People (rightly) make the same critique of Bitcoin: it is very easy for regular people to lose their money. To keep it safe you need to be a security expert, and even then there are no guarantees, and mistakes are forever. My response is the same for both Bitcoin and Ethereum: Even if these technologies are only used by trained professionals, they can still be revolutionary. Almost no one can safely operate a printin…

People at large are not supposed to put money in printing presses they can't use properly, they are supposed to put money in books made by those printing presses.

Ethereum is definitively unsafe, it's basically impossible to create code without any bugs, and it's impossible to prove a piece of code doesn't have any bug. That defeats the all purpose of Euthereum.

Bitcoin is just unsafe by nature for the user, although the protocol itself is most probably safe.

Re: Ethereum is Doomed

#155

Post by patrickk »

bobjones201606 wrote: post #108

Could the person who got the DAO's ETH create a contract to pay out miners who vote against a hard fork with the "stolen" ETH?

Probably quite difficult in practice, unless he/she could somehow convince a mining pool or something.

Another option would be to set up mining hardware in a place like China with low cost electricity. However, this would take time, money and serious effort - if you cash out ether to fund it, you likely crash the price, and if you succeed in fighting the hard fork, the split in the community would likely destroy the trust in Ethereum and your funds go poof.

Re: Ethereum is Doomed

#156

Post by graup »

munificent wrote: post #41

> Solidity is like programming in JavaScript, except with your bank account accessible through the Document Object Model. Such a beautiful, terrifying sentence.

This is a very snarky hyperbole. Solidity has as much to do with Javascript as Java does.

For starters, Solidity is a compiled, typed language.

It is still new and has to be improved.

Re: Ethereum is Doomed

#157

Post by kowdermeister »

amaks wrote: post #98
aakilfernandes wrote: post #65

Earlier quoted context omitted.

Hopefully no on ever trusts a contract with 100 mill for a while, but for lower values and simpler contracts... absolutely i would.

Sorry, but this is bullshit. You sound like Ethereum or SlockIt employee. No one in their sane mind would trust their money a company which can't guarantee security of your funds, let alone good coding practice (the DAO code is shit, sorry -- there are no tests, no comments, no spec, no clear upgrade story etc.). Good attempt, and I can feel for Ethereum folks, but something this important should be rock solid, not "…

"This is not a hacker's playground."

It could have been if they followed bitcoins path and started with 10000btc pizza orders :) Greed take over too soon to realize the flaws.

Re: Ethereum is Doomed

#158

Post by [deleted] »

ianpurton wrote: post #153
DennisP wrote: post #22

I have actually tested this attack technique (using my own contracts on a local test chain), and I've been in discussions with some Solidity developers and the guy who first published the attack. The situation is not as bad as this article claims. For starters, you can use address.send(x) instead of address.call.value(x)(). All computations on Ethereum have to be funded with "gas" (transaction fees), and send() only…

The situation is not as bad as this article claims. Well it kind of is actually. The people that wrote the DAO script had the script checked by lots of Ethereum experts and the bug slipped through. So if the Ethereum experts can't stop things like this happening then what chance do individual developers have. Basically creating a turing complete scripting language on the blockchain is not secure. No financial institu…

[deleted]

Re: Ethereum is Doomed

#159

Post by kowdermeister »

wyager wrote: post #119
dkarapetyan wrote: post #118

Earlier quoted context omitted.

I don't think accessibility is a bad thing. I think computing, its practice and theory, should be taught the same way we teach literacy. I didn't mean "average" as in "incompetent". If writing contracts was as simple as writing a few lines of code in some formal language that didn't require a law or finance degree then I would consider that to be a good thing. It would be even better if the system was designed from f…

I totally agree, but the reality is that in order to write contracts that are sure to be correct, you need a level of expertise that involves much more work than just learning how to write programs. Knowing the syntax and usage of a rigorously-typed language like Agda is the easy part.

Then the platform is flawed. Average programmers should be able to understand it easily.

It's not that hard, some wants X and some wants Y in exchange.

I'm not a lawyer but I write contracts with my clients. If you keep things simple it should fit most people. making g smart contracts complicated you keep it in the area of a small elite who are knowledgeable of playing safe with it.

I wold go as far as make it as simple as HTML.

Re: Ethereum is Doomed

#160

Post by mbrock »

lmm wrote: post #145
edejong wrote: post #135

Earlier quoted context omitted.

There are languages which are both expressive and Turing incomplete, for example Coq. In the Coq language, Turing incompleteness is actually needed to be able to make complete proofs. Maybe Solidity would have been better implemented within Coq, but it's too late now.

See http://publications.lib.chalmers.se/records/fulltext/234939/... (suggesting Idris for this use case)

That particular thesis actually ends up recommending against using a dependent functional language for Ethereum contracts...

I think we might need to think of contracts as very important algorithms and prove them like we prove quick sort. That doesn't require dependent typing and functional programming; you can prove theorems about imperative code if you just have formal semantics.

I'd be interested to see a verified dependently typed compiler to EVM for some simple language... but it kind of seems like a PhD project.

Post reply on HN