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

171–180 of 217 posts

Re: Ethereum is Doomed

#171

Post by Cyph0n »

tomw1808 wrote: post #170
ianpurton wrote: post #153

Earlier quoted context omitted.

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…

Whenever I hear "expert" I think of https://www.youtube.com/watch?v=BKorP55Aqvg

This is the video I was expecting.

Re: Ethereum is Doomed

#172

Post by DennisP »

rtpg wrote: post #79
DennisP wrote: post #25

Earlier quoted context omitted.

If you overflow the stack it throws and rolls back (which is another attack in certain circumstances). What killed TheDAO is basically that childDao called back the sender method, which sends again without having deducted yet. Do the deduct before the send, and the whole problem goes away.

Right, but would the deduction commit even if the send fails? Isn't this the whole concurrency 101 "Atomic deduct and send" problem?

It's not really concurrent, the VM runs one transaction at a time.

The send returns false if it fails. So if you check for that, you can throw an exception, which rolls back the whole transaction just like in SQL.

The reason the send doesn't automatically throw is that if you were doing lots of sends in a loop, you'd actually want to ignore the exception, so if one send fails it doesn't block everybody.

Re: Ethereum is Doomed

#173

Post by DennisP »

yarrel wrote: post #114
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…

Send at the end is like return-once or tail recursion. Does - http://www.joeykrug.com/home/a-serpent-send-exploit change things at all?

Nope, Serpent is a different language that compiles to the EVM, and Krug just noticed that by default, a send in Serpent includes more gas than Solidity does, opening a door to unexpected attacks.

Solidity is the official supported language, Serpent is an earlier and slightly lower-level language that some people still use. I expect they'll fix the gas default.

Re: Ethereum is Doomed

#174

Post by curiousgal »

tomw1808 wrote: post #170
ianpurton wrote: post #153

Earlier quoted context omitted.

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…

Whenever I hear "expert" I think of https://www.youtube.com/watch?v=BKorP55Aqvg

It can actually be done.

https://www.youtube.com/watch?v=B7MIJP90biM

Re: Ethereum is Doomed

#175

Post by cwmma »

edejong wrote: post #135
rwallace wrote: post #134

The problem with Turing completeness is that if it's not there from the start, people inevitably end up needing features that aren't present in the restricted language, and then a Turing complete language is added to either the original system or a successor, and being an afterthought it usually ends up being a hack job. Examples: SQL was supplemented with procedural languages for stored procedures, Excel was supplem…

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.

Coq is pretty specific in what it does like css (also Turing incomplete. There is a pretty low bar for features needed to make something Turing, it doesn't take much more then mutable variables and a while loop or recursive functions to impliment rule 110

Re: Ethereum is Doomed

#176

Post by viraptor »

bendbro wrote: post #121
viraptor wrote: post #38

Earlier quoted context omitted.

I think you're thinking of use cases that would definitely be stopped outside of ethereum world: > Some rich soon-to-be-dead billionaire tech nerds want to be able to do something every year without worrying about a judge taking that away from them. You can do things like this, but the law either already covers this, or will adjust. If you gain money, you're expected to pay the usual tax on that gain. First few may g…

As long as you never convert into traditional currency, how will they know you participated in a transaction?

As long as you never convert, what use is it? (and that's assuming your country doesn't require you to declare cryptocurrency gains)

Re: Ethereum is Doomed

#177

Post by viraptor »

Tinyyy wrote: post #101
viraptor wrote: post #38

Earlier quoted context omitted.

I think you're thinking of use cases that would definitely be stopped outside of ethereum world: > Some rich soon-to-be-dead billionaire tech nerds want to be able to do something every year without worrying about a judge taking that away from them. You can do things like this, but the law either already covers this, or will adjust. If you gain money, you're expected to pay the usual tax on that gain. First few may g…

The point of Ethereum is to provide something that is different from the real world. If not, it is simply fiat, except that it is 1000 times more inefficient and burns up loads of electricity.

It has to affect the real world at some point. If it doesn't, what's the point?

Re: Ethereum is Doomed

#178

Post by wolfgke »

dkarapetyan wrote: post #93
tamana wrote: post #86

Earlier quoted context omitted.

So instead of hiring a juris doctor lawyer to review my contracts, I'll hire a PhD computer scientist ;)

Correct. Programmatic contracts should have democratized the entire business but instead this new scheme creates a new class of "lawyer".

I strongly prefer "laws" that are based on mathematics/computability theory than on social conventions.

Re: Ethereum is Doomed

#179

Post by [deleted] »

graup wrote: post #156
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.

[deleted]

Re: Ethereum is Doomed

#180

Post by brohee »

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…

Right before the theft they would have said "off course", so sure their code was perfect... They made it abundantly clear the truth was in the code, and that men justice was an obsolete concept.
Post reply on HN