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

141–150 of 217 posts

Re: Ethereum is Doomed

#141

Post by pushrax »

aakilfernandes wrote: post #46
anaphor wrote: post #45

What if they had used a language without the possibility of recursion and without loops? I'm being serious. Languages that disallow certain types of recursion, and disallow loops exist. You'd think they would've used something that actually allows for total functions that are guaranteed to terminate in a certain way, instead of a JavaScript clone...

We want to allow recursion and loops. We want to be able to run arbitrary code. We just need to be a little wiser about how we do it.

You don't need recursion to have a useful computing system. Think about GPUs, which don't have a stack at all.

Re: Ethereum is Doomed

#142

Post by cyphar »

Spivak wrote: post #61
cyphar wrote: post #55

Earlier quoted context omitted.

It's fraud. It doesn't pass the officious bystander test.

Yes, this would be considered fraud in the US legal system, but that's not the point. * If you have to involve the legal system then the project has failed because the whole point was to have a contract enforcement mechanism which doesn't need a court system. * If a legal system can override the smart contract then there's no point to even having one since the ultimate authority still resides with the state.

> Yes, this would be considered fraud in the US legal system, but that's not the point.

It is the point though. It is the only point that will matter. Since the writers of the software are US citizens, it's most likely that they will get sued if the transaction is not aborted. Any scenario where the money is not returned to investors will result in the investors suing people -- no matter how much conviction people have that the DAO should be outside of the courts.

> * If you have to involve the legal system then the project has failed because the whole point was to have a contract enforcement mechanism which doesn't need a court system.

$50 million is missing, and people feel wronged as a result. I wouldn't call it a "failure of the project" that it is accountable to the law. Nobody is above the law, not even programmers that write software which governs itself.

> * If a legal system can override the smart contract then there's no point to even having one since the ultimate authority still resides with the state.

Again, nothing and nobody is above the law. You'd have to overrule the Magna Carta if you wanted to change that. And that's just not going to happen.

Re: Ethereum is Doomed

#143

Post by cyphar »

icelancer wrote: post #131
cyphar wrote: post #54

Earlier quoted context omitted.

No, it was fraud. I asked a lawyer, and the stealing of $50 million would not be considered a clause of the contract (it doesn't pass the officious bystander test). As much as programmers might try to remove lawyers and courts from our lives, they are vital to actually doing things with other people where you might have a difference of opinion on what a particular agreement means.

The fact it has to go to the US courts is why it's a failure.

How is not being above the law a failure of a project? If the goal of the project was to be above the law and be accountable to no-one, then the project was doomed from day one. Then again, I never bought the concept of the DAO (lawyers are incredibly important people who are undervalued in our society).

Re: Ethereum is Doomed

#144

Post by cyphar »

coldtea wrote: post #63
cyphar wrote: post #54

Earlier quoted context omitted.

No, it was fraud. I asked a lawyer, and the stealing of $50 million would not be considered a clause of the contract (it doesn't pass the officious bystander test). As much as programmers might try to remove lawyers and courts from our lives, they are vital to actually doing things with other people where you might have a difference of opinion on what a particular agreement means.

First of all, the "officious bystander" test is from English law, not US law. Second, while there are similar tests in other countries' legal systems, it's not that clear cut whether this would be considered such a case or not -- a single lawyer's opinion aside.

> First of all, the "officious bystander" test is from English law, not US law.

Yeah, sorry. But as you say there are similar tests in other countries.

> it's not that clear cut whether this would be considered such a case or not

Whether it would be considered a contract, or what are you referring to? Either way, Etherium and/or the authors of the DAO will get sued, and the investors will win the suit. If you think there's a scenario where someone walks away with $50 million and nobody goes to jail as a result, I'm sorry to say that you're delusional.

And if Etherium hard forks the blockchain, then people have lost faith in the system. So IMO this won't end well for Etherium in either case.

Re: Ethereum is Doomed

#145

Post by lmm »

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.

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

Re: Ethereum is Doomed

#146

Post by SolarNet »

intrasight wrote: post #78
aakilfernandes wrote: post #26

Earlier quoted context omitted.

The whole point of Ethereum is turing completeness. Ethereum without Turing completeness already exists and its called Bitcoin. While this implementation of The Dao has failed, Ethereum is the only blockchain where implementing The Dao is possible.

I also don't see the relevance of it being TC. I've heard regex is TC. Wouldn't want to write a contract in regex.

By definition regular expressions are not Turing complete... There is an ordering relationship between turing machines and regular expressions which explicitly states regular expressions are strictly a subset of turning machines. This is automata theory 101. Ask for a refund from your school.

Jesus what has this field come to.

Re: Ethereum is Doomed

#147

Post by dvdkhlng »

maxander wrote: post #95
SlipperySlope wrote: post #2

The programming classic "Mythical Man Month" had a chapter for the "second system effect". Its where developers put lots of complicated features in to the second system in a series. Its a pattern for failure. In this case, Ethereum developers built a much more complicated cryptocurrency by making it Turing complete - to the extent of writing their own new computer language and virtual machine to run it. They skipped…

Turing-completeness was the entire conceit of Ethereum, as I understand it- without that you would have Bitcoin with a few bells and whistles, and no one would bother. And once you're committed to that, a new language and environment are essential- something this entire fiasco shows is that a language for contract programming has very different requirements than what software engineers are currently used to, in order…

I think we have a lot of theory about turing-complete computation. I really wonder why somebody would be willing to sign a turing-complete contract? The problem of understanding properties of the contract may be NP-hard [1] i.e. practicallly uncomputable. It may even be undecidable by involving instances of the halting problem [2].

[1] https://en.wikipedia.org/wiki/NP-hardness

[2] https://en.wikipedia.org/wiki/Halting_problem

Re: Ethereum is Doomed

#148

Post by lomnakkus »

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.

Edwin Brady's coined(?) a nice term for this: Pacman Complete

Re: Ethereum is Doomed

#149

Post by wila »

tamana wrote: post #86
dkarapetyan wrote: post #77

Earlier quoted context omitted.

So you mean to tell me that taking away the ability to write generic programs to validate contracts is good design? See Rice's Theorem ( https://en.wikipedia.org/wiki/Rice%27s_theorem ). Once you have turing completeness verifying any non-trivial program property starts requiring grad school experience and real proficiency with writing and verifying proofs. Most people, including programmers, do not have the training…

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

.and that PhD computer scientist will have a contract that he/she cannot be held responsible for anything bad that happens with the code he/she writes. Written by a juris doctor lawyer. :)

Re: Ethereum is Doomed

#150

Post by rwallace »

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.

Is it too late now? It seems to me that it should be possible to implement a better language on top of the existing system, there are plenty of languages that compile to JavaScript after all, so it's still worth discussing what a better language might look like.

You say Coq is expressive; okay, but in what sense, for what purposes? A language which isn't Turing complete - or even one which is - isn't going to be expressive for all purposes. As I understand it, Coq is designed to be expressive for the kind of things people doing research in type theory want to write, in the same way SQL is designed to be expressive for database queries.

What sort of things do smart contracts typically want to say? Are they more similar to type theory research, database queries or something else?

One possible answer is that it's too early to say yet, in which case perhaps extensibility is an important attribute. For example, suppose Racket were used as a language for writing smart contracts, with a backend to generate Ethereum byte code. Being a dialect of Lisp, Racket is highly extensible. It also has an optional type system. Do smart contracts tend to be prone to the kind of errors that are caught by a type system? If so, it would be worth using one.

Post reply on HN