Ethereum is Doomed
nakamotoinstitute.org
nakamotoinstitute.org
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.
But that's what was wrong with the exploited DAO code - it didn't use gas. The point of the article is that it's very hard or impossible to verify the correctness of the smart contracts.
this is incorrect
"OK, here we go. _recipient.call.value()() is called without a gas amount. That is easily attackable with an attacking wallet."
This is different from the default _recipient.send() which would be limited to 2300 gas
Does -
http://www.joeykrug.com/home/a-serpent-send-exploit
change things at all?
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.
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.
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.
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.
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.
(Also, Brooks later said: "This I now perceived to be wrong, not because it is too radical, but because it is too simplistic. The biggest mistake in the 'Build one to throw away' concept is that it implicitly assumes the classical sequential or waterfall model of software construction." He wrote a later book, The Design of Design, encouraging iterative development.)
In all likelihood, a working and reliable Ethereum simply requires computer science theories we don't have yet. A working Solidity would probably look something like Ada, but with types and invariants the likes of which we've never seen. Its potentially a very interesting research subject! But for now, yes, investing in Ethereum is like climbing aboard in a rocket aimed at Mars- exciting and futuristic, but unlikely to get you where you hope to go.
[...] Rice's Theorem may essentially be generalized from Turing machines to most computer programming languages: there exists no automatic method that decides with generality non-trivial questions on the behavior of computer programs.
The parent comment asks why someone would agree to a "Turing complete contract". But it's not necessary for an Ethereum contract to be "Turing complete" any more than Quicksort is "Turing complete". If the contract's code does something simple, we can verify and prove that it behaves as expected. It wouldn't be impossible to create a "safe" DAO-like contract.
With the current system I imagine one could even utilize homomorphic encryption to implement another Ethereum inside Ethereum that is cryptographically protected not only against modification but also against inspection :)
Maybe we'll also discover a handful of primitive contract building blocks, to be implemented with care and stringency, with methods for combining them.
A Formal Language for Analyzing Contracts, http://szabo.best.vwh.net/contractlanguage.html
Composing contracts: an adventure in nancial engineering, https://lexifi.com/files/resources/MLFiPaper.pdf
The difficulty makes good contract design a valuable service (like hiring lawyers). Otherwise everyone would just write their own contracts. A more declarative, less powerful language would have opened this up at the expense of contract succinctness.
Such a beautiful, terrifying sentence.
"What's Ethereum?"
Imagine that your dollar bills were written in Javascript.
(from @random_eddie)
For starters, Solidity is a compiled, typed language.
It is still new and has to be improved.
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.
Then at some point it terminates itself before emptying the source account (and thereby causing a rollback that would cascade back?)
send(theEther, childDao)
deduct(theEther, tokenHolder)
Do the deduct before the send, and the whole problem goes away.
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.
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...
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.
http://hackingdistributed.com/2016/06/18/analysis-of-the-dao...
What made this particularly devastating is that there was a second bug which allowed the attacker to transfer their token that represented that first ether back to the DAO. So instead of 30x return, they could eventually drain the whole DAO (although they stopped after the discussion of a fork began).
I'm largely basing my understanding off this article: http://vessenes.com/deconstructing-thedao-attack-a-brief-cod...
In fact, there's little reason to believe that something this complicated would be done correctly the first time. Remember... Bitcoin is not the first digital currency either!
The idea of smart contracts is an interesting one, and perhaps another project will come along and do it better. But Ethereum won't be that project.
Ethereum is meant to be a platform and goes far beyond what Bitcoin can do.
In practice the assumptions you mention turn out to be assumptions about totality and termination of certain building blocks and so you are back to a restricted subset of the language which should have been the original language to begin with but instead of automatic verification you have turned the problem into manual labor. Thinking about this more I agree with the naysayers. Etherium was a good experiment to show people what they should not put into a smart contract system.
We are thankfully very very far from a system of Laws which are anything like that. Such a system might be great in certain "sandbox" environments for manipulating resources that have carefully controlled interactions with the outside. But to have arbitrarily complex "smart contracts" running in the affairs of the real world? no thanks!
Solidity language makes very hard to write safe code:
Is Ethereum/Solidity Suitable for Secure Smart Contracts? It's clear that writing a robust, secure smart contract requires extreme amounts of diligence. It's more similar to writing code for a nuclear power reactor, than to writing loose web code.
Yet the current Solidity language and underlying EVM seems designed more for the latter. Some misfeatures are:
A good language for writing state machines would ensure that there are no states from which it is impossible to recover. A good language for writing state machines would make it painfully clear when state transitions can and cannot happen. A good language for maintaining state machines would provide features for upgrading the security of a live contract. A good language for writing secure code would make it clear that there are no implicit actions, that code executes plainly, as read. The current language does not fulfill any of these commandments, and in fact, the last one, involving implicit recursive calls, is what did The Dao in.
The SlockIt team even had the designer and implementor of Solidity perform a review of their code. If he cannot get something like The DAO to be secure, no one can.
But apparently it only takes a fork to freeze/reverse their contracts. I would take my chances with a traditional foundation, Alfred Nobel's is still running smoothly since +110 years ago, yearly executing its "code".
> 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/ Just with wealth gain and tax office instead.
I don't think it's relevant what the person receiving the Bitcoin does with it after (converting directly to dollars, holding, or buying other goods/services), since those are the same things people do with regular dollars anyway.
As for XKCD - where something happens is no longer clear cut. If someone creates a etherium contract during a year in Argentina while SSH'd into a computer in Hong Kong it starts to become very difficult to enforce the law.
I'm not even talking strictly about tax evasion I'm talking about subversion of the states restriction on individual action - and I agree that this isn't a good thing across the board. I don't like the idea of billionaires hiding their influence and wealth, I just think it is inevitable.
Billionaires still have nexuses with the physical world. The machines which execute their code, for example, can absolutely be affected by court orders. So too can their homes, their cars, their planes, their drones and of course their person.
There's a brand of techno-utopianism that assumes that if it's virtual, it's magically immune from the whole mechanism of law. This has never been true. The law asserts itself to be omnipresent in all human affairs and -- unlike a computer program -- the law's power is accepted at face value by billions of people and underlined by men with guns and dogs.
emphasis mine. I find that last bit, though, to be super interesting; "enforced by men with guns" has always been a big part of the rhetoric of any discussion of law, anarchist, or libertarian thought.
But... I'm not sure I've ever seen dogs mentioned in that context.
Except we're just about to prove that an institution can decide to nullify a Ethereum contract with the soft/hard forks. In the very best case that will a cabal of miners with unknown intentions (and clearly they're not too invested in the Libertarian "code is contract" angle of the network) instead of a democratically constructed judicial system.
Unfortunately the ultimate arbiter of the courts' authority is not a piece of code or a piece of paper, but the courts themselves. If someone disputes the authority of a contract (smart or otherwise) that dispute will ultimately be settled in court. Even if the contract contains language claiming that it is not open to interpretation by a certain court or set of courts, the validity of THAT language will ultimately be interpreted by... a court.
There is no degree of technical cleverness that can supersede the authority of a sovereign entity. You can hide things from a sovereign, move things out of the reach of a sovereign, but you can never overrule a sovereign's authority within its own borders.
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.
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.
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.
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.
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'.
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.
Ethereum uses a virtual machine. There already have been several different languages to write contracts.
However, Coq can only run those computations for a given number of steps; in other words, you can't say "run this until it halts, and give me the result", but you can say "give me the result after 3^^^3 steps, or 'Nothing' if it hasn't halted by then".
The reason this is interesting in this discussion is that Ethereum uses "gas" in a similar way.
That would be a really nice application for formal methods, it seems.
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.
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.
Ethereum is not doomed. But devs do need to be educated of this attack.
Note: I loved Charles Stross's suggestion of code-as-contract in Acccelerando, so I dig the concept.
It could have been if they followed bitcoins path and started with 10000btc pizza orders :) Greed take over too soon to realize the flaws.
While this implementation of The Dao has failed, Ethereum is the only blockchain where implementing The Dao is possible.
Given how hard it is to avoid accidentally introducing these three "simple" elements, Turing completeness often turns up without being planned for.
It is meant to be able to do more computation based stuff than Bitcoin, but without being Turing complete.
However, they seem to have confused the halting problem not being computable with Godel's second incompleteness theorem? (They might have corrected this since I saw when they published something with this.)
They seem to be related concepts. See http://www.scottaaronson.com/blog/?p=2725 for discussion of some interesting examples:
> [...] has explicitly constructed a one-tape, two-symbol Turing machine with 7,918 states, whose behavior (when run on a blank tape) can never be proven from the usual axioms of set theory, under reasonable consistency hypotheses. Adam has also constructed a 4,888-state Turing machine that halts iff there’s a counterexample to Goldbach’s Conjecture, and a 5,372-state machine that halts iff there’s a counterexample to the Riemann Hypothesis.
But yes, the two definitely are connected.
For example:
A program which could solve the halting problem would be able to determine whether a given system is consistent.
So, as a result, if a system could prove that a program solved the halting problem, and it could simulate programs running, then it could simulate the program that solves the halting problem being applied to a program that searches for inconsistencies in the system. This would allow it to prove whether it is itself consistent.
Therefore, by Godel's second incompleteness theorem, a system which can simulate programs for any number of steps, and which is consistent, and which can do arithmetic and such, cannot prove that any particular program solves the halting problem.
Admittedly, this is a lot weaker than "no program solves the halting problem", but I think it is a fairly clear connection.
So, yes, I agree that they are related.
But Ethereum's Turing completeness (or, Turing completeness except being limited by gas costs), does not mean that Ethereum is "inconsistent", because that is, uh, pretty much a nonsense claim. And that is the claim that I think the other group was making (Though they may have stopped making it since.)
Also, btw, wrt that blogpost, they got the number of states for a machine which ZFC cannot prove does not halt, but which does not halt, down to, iirc, like 2030 ? But you probably knew that already because it is the next blogpost on there.
But yeah that is a cool result!
The average programmer should not be writing multi-million-dollar contracts.
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.
You heard wrong. Regex is specifically not turing complete. It corresponds to the class of machines called DFAs. Above regexes are CFGs, which correspond to pushdown automata. Above CFGs are CSGs, which correspond to linear bounded automata. Above CSGs are unrestricted grammars, which correspond to turing machines.
You may be thinking of PCREs, which aren't actually regular expressions, but are sometimes erroneously referred to as such. I don't know if those are turing complete or not.
Jesus what has this field come to.
There are an infinite number of non-Turing complete languages. Not-Turing complete != Bitcoin.
I am hoping that the recent events -- Theranos, out-smarted contracts, etc. -- will permit a return to maturity in this field. Money has poisoned this field.
[1]: wrote about (genetically) evolving cellular corporation back in '96 so this is not a case of I don't get it.
I think the idea vehind TC is that now you could write in certain styles that do guarantee termination without sacrificing readability.
For example if you're working with just primitively recursive functions you can always guarantee termination
So the prerequisite for people investing is for the contract to be in a certain style, or something
EDIT: besides, even without TC you still need to check the contract for logic bugs. TC is a bit of a red herring for "due diligence is always needed"
Many high-tech fintech digital contracts are written in languages like Haskell or Ocaml. Fintech people value strong types, declarative programs, immutability, etc.
You usually get that through a restricted subset of an otherwise turing-complete language. The standard approach is to impose a finite metric on the arguments of a function and demonstrate that, as the function recurses, that metric monotonically approaches zero.
>barely becoming practical in languages like Rust.
As far as I know, this cannot be done in Rust. Agda, Coq, and Idris are the primary languages supporting termination checking (because they are syntactically suited for it). Haskell supports it as well through Liquid Haskell.
> Dependent types aren't the easiest thing to pick up.
Look at liquid types. They're a lot easier to leverage in practice. Liquid Haskell is all just comments on top of a regular Haskell program.
Maybe I spent too much time in functional languages and I've been doing too much React stuff lately but the way I see it, we have
Contract_method(state, parameters) => {new state, return value}
Eg transferring 30 eth from contractA to contractB you would have one of the postconditions asserting that ContractA balance is the old balance minus 30.
The notion of gas implies a stack or effort limit, so it's guaranteed that any operation will eventually fail once it runs out of resources. Thus you can specify a theoretical upper limit on resources used in pre-verification, which (AFAIK)is paid by the client contract that requests to withdraw money from the other contract.
I guess one could avoid this by using a DSL that is formally verifiable, but it's still an interesting option
What you described is basically abstract interpretation and if it was designed properly then the type system would have taken care of the simulation piece.
Actually, termination checkers often compare the size of the term being reduced before and after an evaluation step, and if it can prove that it's always smaller, then termination is assured. With the notion of finite amounts of gas, termination seems assured, so this termination analysis can (and should) be added to EVM.
Based on this termination property, all sorts of static analyses now become possible.
(ref: http://www.antipope.org/charlie/blog-static/fiction/accelera... )
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.
'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.
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.
But this may not be up to the miners alone. Perhaps even more important is what for the major exchanges choose to run, since they're needed to convert Ether back into BTC/fiat currency. If a major exchange makes a public announcement committing to either the soft or hardfork, then that will sway a great many miners.
We just need to be a little wiser about how we do it.
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.
The problem with Ethereum is that you can't push a fix to your contract.
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.
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.
"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)."
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?
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?
If you have the ability to invest, this is a good time to do so. you're about to see massive increases in valuation.
Apparently a friend of Vitalik
Every single system has this problem. You think banks aren't hacked?
For example, people from different countries scamming old people out of $1000 for Prince Abu to free his millions.
That being said, I can understand why you think something being legally exploitable is something new. Just like a loophole in a contract is a loophole in a contract.
In the case of smart contracts, there is no recourse unless built in to the contract. This is by design.
All that's going to happen is people will start writing smaller, more testable, less damaging contracts. This regime is different from legal contracts because many lawyers specifically write contracts to create problems later. In this new world, good contract writers will be gods.
So if you're a good software engineer, there is potentially a huge market about to open up for you.
That's not what "legal" means. Just like killing people without leaving traces to find you is not "effectively legal". It may simply be not worth pursuing because of gain/effort trade off.
Oh the hypocrisy.
The terms of The DAO Creation are set forth in the smart contract code existing on the Ethereum blockchain at 0xbb9bc244d798123fde783fcc1c72d3bb8c189413. Nothing in this explanation of terms or in any other document or communication may modify or add any additional obligations or guarantees beyond those set forth in The DAO’s code. Any and all explanatory terms or descriptions are merely offered for educational purposes and do not supercede or modify the express terms of The DAO’s code set forth on the blockchain; to the extent you believe there to be any conflict or discrepancy between the descriptions offered here and the functionality of The DAO’s code at 0xbb9bc244d798123fde783fcc1c72d3bb8c189413, The DAO’s code controls and sets forth all terms of The DAO Creation.
Basically, the code is the only authentic version of the contract. The attacker entered this contract and used its functionality as was programmed in the blockchain, he didn't modify a bit of the code. So it seems pretty legal.
* 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.
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.
So what is the plan going forward - if either party in a "smart contract" feels disadvantaged by the outcome - they go running to the law and outside jurisdictions for remedy? Isn't avoiding all that overhead the point of have a "smart contract" in the first place?
It's an interesting concept and I'd like to see the project survive (from a technology standpoint; I not risking any cash with it)... maybe it is good they did a faceplant 6 weeks in and can start answering some very hard questions that have come up.
The DAO basically said screw the lawyers and case law and precedent bullshit, the contract is nothing more or less than the results of running this program on the Ethereum VM.
As the program executed a way to transfer 10s of millions of dollars and they specifically stated that the program was the contract, by The DAO no contract violation occurred, hence no hack.
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.
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.
Maybe you should read up on financial fraud, white collar crime and Wall Street?
"Ethereum is a decentralized platform that runs smart contracts: applications that run exactly as programmed without any possibility of downtime, censorship, fraud or third party interference."
>You think banks aren't hacked?
There has been a lot of general description of the individual or group that performed the splitting as an "attacker" or "hacker", but the very nature of the system in question subverts the conceptual foundation of "attacking". To be an "attack" rather then a legitimate execution of an agreement, the action would have to be "illegitimate", but when legitimacy is explicitly defined by the code itself, then how can any action allowed by the code be illegitimate? It'd be a different issue entirely if the underlying VM or a system had been exploited, but merely doing as the code allowed when the code is made the agreement's authority?
Also, I've been using "agreement" here too rather then "contract" because, despite the label of "smart contract" Etherium has adopted I think there's a basic legal question about whether legally they're "contracts" at all. A contract is a subset of the space of agreements; all contracts are agreements, but not all agreements are necessarily contracts. There are many factors in determining validity of contracts and a huge body of contract law that has already been discussed a great deal, but all that depends on there being a contract at all, and for that there needs to be an agreement where the parties intend to be bound by the law (of whatever jurisdiction whose enforcement power they wish to invoke). There are many agreements where there is no intention to have legal enforceability, and in that case the courts have nothing whatsoever to say on the matter. Contract law never even enters the picture.
The DAO, and Etherium in general, have made a big deal specifically about not invoking the courts. That was supposed to be part of the entire point of smart "contracts", that they'd have nothing at all to do with any common legal system and be self-contained in and of themselves. In turn though that could mean that any smart contract that declares itself fully self-definitional is in turn not a contract period, so there cannot be an "attacker" in the legal sense.
Bank hacks in contrast aren't much different in concept from bank heists of any other kind. They are able to invoke real world power in response, and have multiple levels of fallbacks and insurance for their customers. It's by design a much softer fail, multiple level system with an expectation of occasional failure built-in and a strong human element. This adds expense and inefficiency, but provides benefits to imperfect human societies too. It came out of ages of real world experience and testing after all.