
Ethereum is Doomed - kushti
http://nakamotoinstitute.org/mempool/ethereum-is-doomed/#selection-7.4-7.22
======
DennisP
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 forwards a small amount of gas. The recipient can write to the
log but that's about it. TheDAO used .value() which forwards all the available
gas.

If you do use .value(), then you can do it safely by doing it only once per
method, as the very last step, and only using it in top-level methods. Then
any sort of reentrant callback will find any required state changes already
done. E.g. subtract from the user's balance, send the funds, and if the send
fails then throw. The recipient can call back but the balance is already
decremented. Using a mutex is another option. I've tested all this and it
works.

There are a lot of reasons Ethereum is designed this way. The most common
reason for a contract to run code when receiving funds is to prevent users
from accidentally losing their money. E.g. in any contract that holds ether
and maintains a ledger with balances for multiple users, if anyone sends ether
to the contract address, they'll lose it, unless the contract either throws an
exception or automatically adds to the user's balance on its ledger.

User addresses and contract addresses are interchangeable, because it lets you
do things like use a multisig timelocked vault to receive funds and anything
can send to it just as if it were a regular user account.

All that said, the devs are working on improvements too.

~~~
ianpurton
_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.

~~~
tomw1808
Whenever I hear "expert" I think of
[https://www.youtube.com/watch?v=BKorP55Aqvg](https://www.youtube.com/watch?v=BKorP55Aqvg)

~~~
curiousgal
It can actually be done.

[https://www.youtube.com/watch?v=B7MIJP90biM](https://www.youtube.com/watch?v=B7MIJP90biM)

------
SlipperySlope
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 over the halfway step of declaring parameters in the payment
transactions, that open source enterprise library code, e.g. Java, could
execute for for required behavior. No. They made the new code itself a user-
contributed and immutable! part of the system.

~~~
viraptor
That's actually a pretty good decision in my opinion. At least in this case.
Think what would happen if they went for alternative solutions:

1\. If it wasn't immutable, you'd never be sure when a contract changes.
That's the basic assumption about contract - once you sign it, whether in real
world, or by doing some action in Ethereum, you don't expect it to change how
it works. That's why immutable is good.

2\. User-contributed is just how it's supposed to work. It's decentralised.
Everyone's a user. The content has to be user-contributed. Having some central
publisher/gatekeeper is contrary to the whole idea.

3\. Own VM is debatable. Sure, they could go with JVM, but the scope would
have to include much more complexity (classes, namespaces, etc.) than just
function/instruction execution. Maybe the limits of javacard would be enough,
maybe not.

I really don't think the second system effect applies here. It's not a rewrite
of something that existed and had issues.

~~~
yawaramin
Solidity contracts are already modules which contain functions. They're
equivalent to Java classes with static methods or Scala objects. As for
namespacing, I don't know how in this day and age programmers can say that's
not worth it.

~~~
viraptor
Solidity contracts do contain functions and some state. But that's at a fairly
different level than Java's classes. Internals are not exported. The
contract's structs belong to contracts. There's no need for namespaces within
code because addresses provides namespacing already - all your code is
normally visible to you already and you'll not get unexpected names shadowing
anything in your code.

I'm not saying namespacing is bad, just that namespacing as defined in Java is
likely not necessary in ethereum world, as I understand it. It would likely
just confuse what's immutable vs what's referenced by name.

------
munificent
> Solidity is like programming in JavaScript, except with your bank account
> accessible through the Document Object Model.

Such a beautiful, terrifying sentence.

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

~~~
sesm
> Solidity is a compiled, typed language.

The same language can be both compiled and interpreted, this doesn't affect
the semantics of the language. For example, OCaml ships with both a compiler
and an interpreter. There exist AOT compilers for JavaScript too.

Also, JavaSript is a typed language. It is just dynamically typed and does too
much type coercion.

~~~
graup
Thanks for the clarification. So, Solidity is a compile-only, strongly typed
language? While Javascript is usually interpreted (or JIT compiled) and
dynamically typed.

------
mmanfrin
Having a little bit of trouble parsing how the attack worked -- so when a
transfer happens, the destination account gets to run a command; they then ran
a command that called the source's send-ether command, which ran because it
was still in 'we owe destination account money' mode because the full initial
contract had not concluded?

Then at some point it terminates itself before emptying the source account
(and thereby causing a rollback that would cascade back?)

~~~
darawk
My understanding is that it looks essentially like this:

    
    
        send(theEther, childDao)
        deduct(theEther, tokenHolder)
    

But that you can get it to overflow the stack in between the two so that the
send completes but the deduction no longer happens.

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

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

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

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

This sounds like the wrong default behaviour. If we're talking about sending
money, and there's a list of people to send money to, I would say that the
default behaviour should be to throw an exception, because if not you could
end up having money not be properly redistributed.

For example, a simple smart contract to share costs. If one member not longer
participates then shouldn't their cut be given to the remaining participants?

The fact that it doesn't roll back everything by default concerns me quite a
bit...

~~~
DennisP
You can accomplish that by checking the return value. But Solidity doesn't
have try/catch, it just rolls back everything upon throw. If send() were to
actually throw upon failure, then it would roll back the entire method call
and nobody gets paid. A troublemaker could use an account that always throws
when it receives funds, and permanently block all payouts for everybody
(unless a contract admin has a way to kill accounts).

The best pattern is not to put sends in a loop at all. Just update a ledger
inside the contract, and have each user call a withdraw() function to get
their money. That way if you're careful you can even use call.value, so users
can include as much gas as required, and can withdraw the money directly into
any sort of contract they like.

------
3pt14159
Ethereum isn't doomed. I don't think it will ever have as much backing as
Bitcoin because of institutional buy-in; but the world needs programmable
smart contracts. 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. Individual will is what cryptocurrencies are about. Bitcoin in
terms of international payments and store-of-value; and Ethereum in terms of
contracts and computing.

~~~
viraptor
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 get away with it, but once it becomes popular, audits will
start.

> Individual will is what cryptocurrencies are about.

Same as above - inheritance tax.

Essentially it's this xkcd situation:
[https://xkcd.com/1494/](https://xkcd.com/1494/) Just with wealth gain and tax
office instead.

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

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

------
rwallace
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 supplemented with VBA, HTML was supplemented with
JavaScript and, well, Bitcoin was supplemented with Ethereum.

So providing a Turing complete language was the right decision as far as it
goes, but it's not enough by itself. If you need reliability - which this does
- it needs to be the case that typical code does _not_ involves arbitrarily
complex computation. Typical code needs to fit stereotyped patterns whose
behavior is predictable.

If Ethereum is to continue, it's clear that exhorting people to try even
harder not to make mistakes in the current version of Solidity, won't cut it.
The language needs to be supplemented or replaced with something that makes it
easy to write correct code for the kind of things people typically want to do.

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

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

~~~
mbrock
Note that Solidity is not JavaScript, it's just superficially similar in some
ways. The comparison with JavaScript is for marketing pretty much.

In particular, Solidity is statically typed.

I would say that smart contracts are a lot like event processors that update
bits of contract-local state and enforce preconditions. They are run in a
single "thread" in blockchain order, but they can also invoke each other
reentrantly (and that's the major source of confusion so far, so it should be
limited and made very explicit).

Some contracts perform more complex calculations, e.g. I know of one that
calculates compound interest using fixed point math.

There might be room for several different simpler languages for different
purposes... It would make sense to use the most restricted language that can
express the contract you want.

~~~
rwallace
From what I've seen of the discussion on this, you're right about uncontrolled
reentrancy being a big source of problems.

One thing that occurs to me: would the command-query distinction be a useful
notion here? I have no truck with it in the general context in which it was
coined, but in this context maybe it would be useful to draw a hard line
distinction between 'I call you to ask for information' and 'I call you to ask
for money'.

~~~
mbrock
Solidity contracts can define "const" functions which aren't allowed to change
state.

For some uses you can also look at the events that a contract emits, which are
indexed and searchable off-chain... so client apps can read them, but not
contracts themselves.

~~~
rwallace
Okay, so const was available as a feature - but not used because it wasn't the
default? Some of the discussion on this seems to be saying Solidity supports
exceptions and transactions, which should provide a lot of safety here (on
error, an exception should be thrown and everything the script just did should
be rewound) but the documentation was still exhorting programmers to check
return values all over the place. Is this at least in part a matter of bad
defaults? I'd be quite prepared to believe so; bad defaults are a much bigger
problem than they are sometimes thought to be.

------
erikpukinskis
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 printing press, and
yet that invention has toppled empires.

At worst, these are back office technologies. At best in a decade or two
someone will figure out how to design a good enough GUI that a novice can
safely explore a powerful subset the technology, trusting that bumpers are in
place around the sharp edges.

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

------
aakilfernandes
Here's a better explanation of the attack: [http://vessenes.com/more-ethereum-
attacks-race-to-empty-is-t...](http://vessenes.com/more-ethereum-attacks-race-
to-empty-is-the-real-deal/)

Ethereum is not doomed. But devs do need to be educated of this attack.

~~~
coldcode
It is doomed, who would trust a contract now with real "money"? Unless you
have a mathematically rigorous proof that the contract is trustworthy I sure
wouldn't.

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

~~~
amaks
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 "experiment" when you're fucking with
people's money. This is not a hacker's playground.

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

------
bithive123
"I thought again about my early plan of a new language or writing-system of
reason, which could serve as a communication tool for all different nations...
If we had such an universal tool, we could discuss the problems of the
metaphysical or the questions of ethics in the same way as the problems and
questions of mathematics or geometry. That was my aim: Every misunderstanding
should be nothing more than a miscalculation (...), easily corrected by the
grammatical laws of that new language. Thus, in the case of a controversial
discussion, two philosophers could sit down at a table and just calculating,
like two mathematicians, they could say, 'Let us check it up ...'"
\--Gottfried Wilhelm Leibniz

------
dkarapetyan
I didn't know the language was turing complete. Isn't this computing 101? If
you want a secure thing then you must be able to reason about it statically.
Making things turing complete means any non-trivial property of program
correctness can not have a generic solution and so you've just opened yourself
up to a world of hurt.

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

~~~
dkarapetyan
This doesn't sound right to me. Contract law should not require turing
completeness. First order logic should be more than sufficient. How does
having a loop in contract law make any sense?

~~~
wyager
There are also a class of total languages (Coq, Agda, Idris) that are
guaranteed to terminate but admit (polymorphic) recursion. This is stronger
than FOL but weaker than turing-completeness, and certainly sufficient to
implement any feasible contract.

~~~
dkarapetyan
I agree. I said first-order logic because I think it is more accessible. Coq,
Agda, Idris, etc. employ I think some pretty sophisticated type theory and
that would all have to be packaged up in a way that is accessible to an
average programmer.

~~~
wyager
> in a way that is accessible to an average programmer.

The average programmer should not be writing multi-million-dollar contracts.

~~~
dkarapetyan
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 first principles with solid theory backing it.

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

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

~~~
wyager
That's what standardized contracts are for. Tellers don't write the legalese
on your credit card receipt. They just print it out.

------
AceJohnny2
I'm getting a strong Accelerando deja-vu here.

(ref: [http://www.antipope.org/charlie/blog-
static/fiction/accelera...](http://www.antipope.org/charlie/blog-
static/fiction/accelerando/accelerando-intro.html) )

------
odrekf
As expected, "Ethereum is turing-complete" turned out to be just a marketing
meme (or a horrible idea at best), just like "Litecoin is silver", "Doge is
community", and all the others.

------
endergen
I love that Smart Contracts act basically as bug bounties to make the Ethereum
systems, community knowledge, and open contracts improve dramatically.

~~~
dragontamer
I love how law and court systems are basically bug bounties on legal systems,
community knowledge, and social constructs. Society will inevitably improve
dramatically.

Oh wait, no. We just turned programmers into politicians and lawyers. I think
more people will be pissed when they find out that "trust in the system"
ultimately means "trust the writer of the smart contract".

Unlike law, which has admitted that insane things happen and provides
"emergency stops" (ie: Supreme Court can say whatever the heck they want and
provide a check against any of Congress's laws)... there isn't really a way to
add human "emergency stops" to the equation of Ethereum.

~~~
endergen
I hear your sentiment. But not your argument as much. Politicians and Lawyers
are inherently > smart contract writers?

'I think more people will be pissed when they find out that "trust in the
system" ultimately means "trust the writer of the smart contract".' How is
this different than not trusting Lawyers?

'Unlike law, which has admitted that insane things happen and provides
"emergency stops" (ie: Supreme Court can say whatever the heck they want and
provide a check against any of Congress's laws)... there isn't really a way to
add human "emergency stops" to the equation of Ethereum.' Agreed on using
Ethereum contracts anytime in the near future (or ever) for anything life or
death or over exposing your self financially is insane. There are plenty of
cases that are a better fit for a smart contract system. People should invest
affordable proportions of their money.

------
bobjones201606
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?

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

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

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

~~~
dkarapetyan
How did this madness start? I don't want law to be turing complete. Especially
programatic law. Why are people so nonchalant about this? This is not sane
design. You want totality and termination proofs. At least that's what I would
look for in any programatic system of law.

~~~
saalweachter
Biggest rock is best rock.

------
pt1988
Its too bad, I really thought Vitalik was the Chosen One, but I think he
reacted incorrectly here by panicking and showing concern.

If I had been him I would have let DAO fail without even discussing any fork.
Be as emotionless about it as the code itself. Admit mistakes were made,
somebody (DAO investors) will lose some money in the short term but stay true
to the principles of Ethereum.

PLUS even after all this drama, $ETH has a market cap of ~$1B as well as
independence (fingers crossed) from government intervention making it an
alternative to Fiat currency, as well as a much better block rate than BTC
lending itself to mining on consumer-grade GPU's for the moment at least. I'm
looking at litecoin LTC as my next crypto-bubble investment as well.

There's still lots of good to be said about Ethereum. DAO is toast, long live
DAO2! Ethereum will come out stronger long term.

------
barisser
Software is almost always flawed to a certain extent.

The problem with Ethereum is that you can't push a fix to your contract.

~~~
vessenes
You absolutely can if you're not too proud to imagine you'll need to upfront.

------
apapli
Surely an issue here irrespective of technology flaws or not is the economic
impact on the time taken to write smart contracts.

If it now takes substantially more dev time to write a smart contract that is
"secure" (ie by spending lots and lots of time testing for vulnerabilities)
this will invariably come at a cost.

So while the theory of smart contracts is brilliant this recent hack might go
down in history as a case study as to why writing contracts is too expensive
to do in all but the top 1% of situations.

------
thelollies
I wonder if a language like Haskell with a strong type system and strict
typing could help. If you were able to express exchange of currency with the
type system.

~~~
codygman
I'm pretty sure you can do that. See units in F# for example.

------
lquist
The Coinbase founder that a month ago called ethereum the future of
cryptocurrency looks kind of silly now.

------
Animats
It's now clear that Ethereum's contract system has major security
vulnerabilities. This is a killer flaw for something which exists only to
secure transactions between mutually mistrustful parties. Maybe someone else
will do this again, better. Etherium itself probably is doomed.

There are also hard questions to ask the people involved. The same people seem
to be behind Etherium, the DAO, and the programmable door-lock startup which
the DAO was supposed to fund. This is suspicious. This might be an inside job.
At least three times in the Bitcoin world, some Bitcoin exchange claimed they
lost money due to a "hack", but in the end it turned out to be an inside job.

------
xoa
I wrote this originally in response to a post by cyphar
([https://news.ycombinator.com/reply?id=11942889](https://news.ycombinator.com/reply?id=11942889)),
but I'd really love a response from anyone with more knowledge or thoughts on
how the law might interpret this situation in relation to already existing
"virtual legal systems". cyphar wrote:

    
    
      "It was definitely fraud. Either it was a contract, in which case "taking $50 million without anyone's consent" doesn't pass the officious bystander test. Otherwise it wasn't a contract, so the default is still fraud (though in that case, the DAO would be the thing being defrauded rather than the investors)."
    

I'd like significantly more details on your legal theory for how this was
"definitely fraud" or how "the default is fraud" if there was no legal
contract, the split executor was a direct party to the agreement, and the
terms of the agreement were followed. "$50 million" was not taken, 3.6 million
or so "ether" was split out from the original smart contract/account, which
may or may not end up having some dollar value.

In at least two previous threads [1, 2], comparisons were made to the MMOG EVE
Online (developed by CCP Games), and I think the analogy raises some
interesting questions. EVE is a self-contained artificial system that, so long
the system framework itself is not exploited, is ruled entirely by code. It
has a digital currency (ISK) that has an official conversion rate from real
world fiat currency to ISK, and an unofficial ToS breaking (but non-criminal
AFAIK) conversion rate from ISK back to fiat. CCP has nothing to do with this
exchange, but exchanges for ether to other currencies are also 3rd party.
Virtual items as well as ISK itself thus have calculable value, both within
the system, in terms of time/rarity, and in terms of nation-state issued
money. There are person-actor driven "contracts" of various sorts, and people
driven markets. There is fraud, piracy, and pure chaotic destruction as well,
and that's considered entirely within the system framework so long as the
overall code rules of the world are not violated.

Given that, what exactly is the legal difference between the DAO and EVE
Online? In EVE, if Alice attacks Bob, or infiltrates his organization, and
steals/destroys a few hundred billion in ISK (equivalent to a few thousand
dollars at current exchange rate), or sets up a fraudulent bank/scheme that
makes off with hundreds of billions or trillions (this has actually happened),
do you think Bob should be able to sue in a real world court of law? The
essence of the situation looks similar/identical to me: that the parties are
operating under a non-contract non-legal agreement to be governed within the a
specific set of world rules, and that therefore any interactions within those
world rules, however angry they might get about it on a personal level and
whatever colloquial English they might use to describe it, creates no legal
standing of any sort outside. If EVE client/server were hacked (the world
rules distorted) it'd be an issue (though still not necessarily a legal one),
just as if the Ethereum VM was hacked it'd be an issue, but if those were
operating entirely as they should be then what's the basis of legal complaint?
What's the generalized objective basis for court involvement in people
agreeing to mess around with made up numbers on computers, even if other
people decide to try to exchange those numbers for money?

1:
[https://news.ycombinator.com/item?id=11925904](https://news.ycombinator.com/item?id=11925904)

2:
[https://news.ycombinator.com/item?id=11929208](https://news.ycombinator.com/item?id=11929208)

~~~
tamana
Legally speaking, CCP goes out of its way to emphasize that isk are play
tokens money with no cash value, and losing it all is part of the game.
TheDAO/Ethereum supports exchanging ether for money. And anyone who lies about
contract (beyond smiling and saying "here the contract code, sign it if you
want" is commiting a fraud

~~~
xoa
>Legally speaking, CCP goes out of its way to emphasize that isk are play
tokens money with no cash value

CCP officially supports converting money to ISK, and there are 3rd party
exchanges for ISK to money. My understanding was that TheDAO ran purely on
ether, and that any exchanges for money (be it fiat or another digital
currency) were also happening purely 3rd party. Does an official line on
"don't go the other way" make a material difference? If CCP merely took no
stance on it at all, involved in no way but not working to ban anyone doing
it, would that change anything? How "seriously" do they have to police it? Is
there any case law on this?

>And anyone who lies about contract (beyond smiling and saying "here the
contract code, sign it if you want" is commiting a fraud

Can you clarify your point here, and what you were referring to?

1\. (and again): How is there any legal contract here, and if there isn't
what's the 'fraud' legally (not a colloquial "fraud" with no legal impact)?
Are you arguing that people should not be allowed to have non-legally binding
(and thus non-contractual) agreements on shifting around "value" based on
coded rules?

2\. In the case of TheDAO, there were no lies, TheDAO stated clearly and
repeatedly that the definitive governing authority was the smart contract
itself, and TheDAO organization itself was not (or at least, publicly claims
it was not) involved in the controversial smart contract execution. Instead it
was at least one of the independent parties to the agreement. So if you were
referring to TheDAO I'm confused.

3\. In the case of EVE, are you arguing that ISK is different and therefore
fraud is legally ok? Or are you arguing that it's still legally fraud?

------
anonbanker
Doom articles mean market debasement is happening.

If you have the ability to invest, this is a good time to do so. you're about
to see massive increases in valuation.

------
baybal2
Fiy, i recently came upon this company
[http://m.imgur.com/Hv9n7fk,55JgdgK](http://m.imgur.com/Hv9n7fk,55JgdgK) that
wants to sell ETH to Chinese. I checked the company registry, and found out
that the guy has registered a proprietorship back in 2013.

Apparently a friend of Vitalik

~~~
amq
It is just a job posting.

------
yarrel
....to succeed. ;-)

------
teslaberry
run for the bitcoin hills!.

------
heliumcraft
Absolute trash article.

------
cheez
> They created a situation in which bugs would be expected to arise in an
> environment in which bugs are legally exploitable. That is hacker heaven.

Every single system has this problem. You think banks aren't hacked?

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

~~~
cyphar
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" then unless both parties would've said
"of course!" then it isn't considered to be a clause of the contract and it is
just simply fraud. The developers of theDAO wouldn't have said "of course" so
it's fraud.

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

