Ethereum Blog

Thinking About Smart Contract Security

Introduction

user

Vitalik Buterin


LATEST POSTS

Ethereum R&D Roundup: Valentine’s Day Edition 14th February, 2017

December Roundup 31st December, 2016

technical

Thinking About Smart Contract Security

Posted on .

Over the last day with the community’s help we have crowdsourced a list of all of the major bugs with smart contracts on Ethereum so far, including both the DAO as well as various smaller 100-10000 ETH thefts and losses in games and token contracts.

This list (original source here) is as follows:

  • The DAO (obviously)
  • The “payout index without the underscore” ponzi (“FirePonzi”)
  • The casino with a public RNG seed
  • Governmental (1100 ETH stuck because payout exceeds gas limit)
  • 5800 ETH swiped (by whitehats) from an ETH-backed ERC20 token
  • The King of the Ether game
  • Rubixi : Fees stolen because the constructor function had an incorrect name, allowing anyone to become the owner
  • Rock paper scissors trivially cheatable because the first to move shows their hand
  • Various instances of funds lost because a recipient contained a fallback function that consumed more than 2300 gas, causing sends to them to fail.
  • Various instances of call stack limit exceptions.

We can categorize the list by categories of bugs:

  • Variable/function naming mixups: FirePonzi, Rubixi
  • Public data that should not have been public: the public RNG seed casino, cheatable RPS
  • Re-entrancy (A calling B calling A): the DAO, Maker’s ETH-backed token
  • Sends failing due to 2300 gas limit: King of the Ether
  • Arrays/loops and gas limits: Governmental
  • Much more subtle game-theoretic weaknesses where at the limit people even debate whether or not they’re bugs: the DAO

There have been many solutions proposed to smart contract safety, ranging from better development environments to better programming languages to formal verification and symbolic execution, and researchers have started developing such tools. My personal opinion regarding the topic is that an important primary conclusion is the following: progress in smart contract safety is necessarily going to be layered, incremental, and necessarily dependent on defense-in-depth. There will be further bugs, and we will learn further lessons; there will not be a single magic technology that solves everything.

The reason for this fundamental conclusion is as follows. All instances of smart contract theft or loss – in fact, the very definition of smart contract theft or loss, is fundamentally about differences between implementation and intent. If, in a given case, implementation and intent are the same thing, then any instance of “theft” is in fact a donation, and any instance of “loss” is voluntary money-burning, economically equivalent to a proportional donation to the ETH token holder community by means of deflation. This leads to the next challenge: intent is fundamentally complex.

The philosophy behind this fact has been best formalized by the friendly AI research community, where is bears the names of “complexity of value” and “fragility of value“. The thesis is simple: we as human beings have very many values, and very complex values – so complex that we ourselves are not capable of fully expressing them, and any attempt to will inevitably contain some uncovered corner case. The utility of the concept to AI research is important because a super-intelligent AI would in fact search through every corner, including corners that we find so unintuitive that we do not even think of them, to maximize its objective. Tell a superintelligent AI to cure cancer, and it will get 99.99% of the way there through some moderately complex tweaks in molecular biology, but it will soon realize that it can bump that up to 100% by triggering human extinction through a nuclear war and/or biological pandemic. Tell it to cure cancer without killing humans, and it will simply force all humans to freeze themselves, reasoning that it’s not technically killing because it could wake the humans up if it wanted to – it just won’t. And so forth.

In smart contract land, the situation is similar. We believe that we value things like “fairness”, but it’s hard to define what fairness even means. You may want to say things like “it should not be possible for someone to just steal 10000 ETH from a DAO”, but what if, for a given withdrawal transaction, the DAO actually approved of the transfer because the recipient provided a valuable service? But then, if the transfer was approved, how do we know that the mechanism for deciding this wasn’t fooled through a game-theoretic vulnerability? What is a game-theoretic vulnerability? What about “splitting”? In the case of a blockchain-based market, what about front-running? If a given contract specifies an “owner” who can collect fees, what if the ability for anyone to become the owner was actually part of the rules, to add to the fun?

All of this is not a strike against experts in formal verification, type theory, weird programming languages and the like; the smart ones already know and appreciate these issues. However, it does show that there is a fundamental barrier to what can be accomplished, and “fairness” is not something that can be mathematically proven in a theorem – in some cases, the set of fairness claims is so long and complex that you have to wonder if the set of claims itself might have a bug.

Toward a Mitigation Path

That said, there are plenty of areas where divergence between intent and implementation can be greatly reduced. One category is to try to take common patterns and hardcode them: for example, the Rubixi bug could have been avoided by making owner a keyword that could only be initialized to equal msg.sender in the constructor and possibly transferred in a transferOwnership function. Another category is to try to create as many standardized mid-level components as possible; for example, we may want to discourage every casino from creating its own random number generator, and instead direct people to RANDAO (or something like my RANDAO++ proposal, once implemented).

A more important category of solutions, however, involve mitigating the specific and unintuitive quirks of the EVM execution environment. These include: the gas limit (responsible for the Governmental loss, as well as the losses due to recipients consuming too much gas when accepting a send), re-entrancy (responsible for the DAO and the Maker ETH contract), and the call stack limit. The call stack limit, for example, can be mitigated through this EIP, which essentially removes it from consideration by substituting its purpose with a change to gas mechanics. Re-entrancy could be banned outright (ie. only one execution instance of each contract allowed at a time), but this would likely introduce new forms of unintuitiveness, so a better solution is likely required.

The gas limit, however, is not going away; hence, the only solutions there are likely to be inside of the development environment itself. Compilers should throw a warning if a contract does not provably consume less than 2300 gas if called with no data; they should also throw a warning if a function does not provably terminate within a safe amount of gas. Variable names might be colored (eg. RGB based on the first three bytes of the hash of the name), or perhaps a heuristic warning might be given if two variable names are too close to each other.

Additionally, there are coding patterns that are more dangerous than others, and while they should not be banned, they should be clearly highlighted, requiring developers to justify their use of them. A particularly involved example is as follows. There are two types of call operations that are clearly safe. The first is a send that contains 2300 gas (provided we accept the norm that it is the recipient’s responsibility not to consume more than 2300 gas in the case of empty data). The second is a call to a contract that you trust and that is itself already determined to be safe (note that this definition bans re-entrancy as you would then have to prove A is safe before proving A is safe).

As it turns out, very many contracts can be covered by this definition. However, not all of them can; an exception is the idea of a “general purpose decentralized exchange” contract where anyone can place orders offering to trade a given amount of asset A for a given amount of asset B, where A and B are arbitrary ERC20-compatible tokens. One could make a special-purpose contract just for a few assets, and thereby fall under the “trusted callee” exemption, but having a generic one seems like a very valuable idea. But in that case, the exchange would need to call transfer and transferFrom of unknown contracts and, yes, give them enough gas to run and possibly make a re-entrant call to try to exploit the exchange. In this case, the compiler may want to throw a clear warning unless a “mutex lock” is used preventing the contract from being accessed again during those calls.

A third category of solutions is defense in depth. One example, to prevent losses (but not thefts) is to encourage all contracts that are not intended to be permanent to have an expiry date, after which the owner can take arbitrary actions on behalf of the contract; this way, losses would be possible only if (i) the contract screws up, and simultaneously (ii) the owner is missing or dishonest. Trusted multisig “owners” may emerge to mitigate (ii). Thefts could be mitigated by adding waiting periods. The DAO issue was greatly mitigated in scope precisely because the child DAO was locked down for 28 days. A proposed feature in the MakerDAO is to create a delay before any governance change becomes active, allowing token holders unhappy with the change time to sell their tokens; this is also a good approach.

Formal verification can be layered on top. One simple use case is as a way of proving termination, greatly mitigating gas-related issues. Another use case is proving specific properties – for example, “if all participants collude, they can get their money out in all cases”, or “if you send your tokens A to this contract, you are guaranteed to either get the amount of token B that you want or be able to fully refund yourself”. Or “this contract fits into a restricted subset of Solidity that makes re-entrancy, gas issues and call stack issues impossible”.

A final note is that while all of the concerns so far have been about accidental bugs, malicious bugs are an additional concern. How confident can we really be that the MakerDAO decentralized exchange does not have a loophole that lets them take out all of the funds? Some of us in the community may know the MakerDAO team and consider them to be nice people, but the entire purpose of the smart contract security model is to provide guarantees that are strong enough to survive even if that is not the case, so that entities that are not well-connected and established enough for people to trust them automatically and do not have the resources to establish their trustworthiness via a multimillion-dollar licensing process are free to innovate, and have consumers use their services feeling confident about their safety. Hence, any checks or highlights should not just exist at the level of the development environment, they should also exist at the level of block explorers and other tools where independent observers can verify the source code.

Particular action steps that can be taken by the community are:

  1. Taking on the project of making a superior development environment, as well as a superior block/source code explorer, that includes some of these features
  2. Standardization of as many components as possible
  3. Taking on the project of experimenting with different smart contract programming languages, as well as formal verification and symbolic execution tools
  4. Discussing coding standards, EIPs, changes to Solidity, etc that can mitigate the risk of accidental or deliberate errors
  5. If you are developing a multimillion-dollar smart contract application, consider reaching out to security researchers and work with them on using your project as a test case for various verification tools

Note that, as stated in a previous blog post, DEVGrants and other grants are available for much of the above.

profile

Vitalik Buterin

https://ethereum.org

Comments
user

Author Terrence Andrew Davis

Posted at 2:22 am June 19, 2016.

https://beacon.nist.gov/home

NIST Random beacon is made by the whitest of the white security scientists. I explain to a nigger that NIST is NASA. The nigger brain cannot understand a legaly certifed random number.

Here is the NIST security policy. http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-30r1.pdf

Here is the technique. http://www.nist.gov/itl/csd/ct/nist_beacon.cfm

Here is explanation. http://hackaday.com/2014/12/19/nist-randomness-beacon/

For some reason the nigger brain cannot understand what a whitest of the white legally certified random number is.

Reply
user

Author Greg Slepak

Posted at 2:42 am June 19, 2016.

Ethereum needs programming language innovation. Programming languages are how humans express their intent.

If the tool is too cumbersome and unintuitive to use, if it has unexpected behavior, then bad things like The DAO situation will happen.

Ethereum needs to pay a research team to design a simple and safe programming language.

By “simple” I mean it contains as few elements are possibly necessary to express the programmer’s intent. By “safe” I mean the compiler detects and prevents a wide variety of bugs from happening in the first place.

Reply
    user

    Author Vitalik Buterin

    Posted at 2:57 am June 19, 2016.

    Agree, but I think an incremental approach is likely to give better results than a from-scratch one, though of course both can and should be done in parallel.

    Reply
    user

    Author Lucas Vella

    Posted at 4:25 am June 19, 2016.

    Well, it is not a domain specific language for smart contracts, but a language that I am familiar with that has a very good “intent representativity” already exists: it is Haskell, and for what I understand, this is mostly true for functional programming languages. In fact, when I first learned of the attack, when a friend emailed me yesterday morning, I half asleep replied that we finally found a good use for Haskell: Ethereum smart contracts. This thread seems to agree with me, but I feel that Vitalik is somewhat resistant to the idea:
    https://www.reddit.com/r/ethereum/comments/4opjov/the_bug_which_the_dao_hacker_exploited_was_not/

    Try coding a complicated algorithm in Haskell: if you can defeat the compiling errors, you most likely will get it right on the first try.

    Reply
      user

      Author The Tooth

      Posted at 1:26 pm June 20, 2016.

      “Try coding a complicated algorithm in Haskell: if you can defeat the compiling errors, you most likely will get it right on the first try.”

      It’s that kind of thinking which brought DAO here. Financial software requires a bit more diligence than making sure you didn’t stick an integer where a file handler should be.

      https://blog.ethereum.org/2016/06/19/thinking-smart-contract-security/#comment-2740333131

      Reply
        user

        Author Lucas Vella

        Posted at 6:25 pm June 20, 2016.

        That is precisely what I meant with “defeat the compiling errors”. Haskell’s static type system would forbid such an error to happen at compilation level. And while I can’t offer a theoretical explanation of why Haskell programs tend to be bug free, my personal experience agrees with empitical evidente on software engineering literature.

        That said, without revising and enforcing any other validation or formal specification practices on the development of contracts, simply using a Haskell family language would be a huge leap forward.

        Reply
        user

        Author Jean-Philippe Green

        Posted at 9:22 pm June 20, 2016.

        The blog post in your link makes a great case for Haskell, since Haskell is a purely functional programming language which focuses heavily on recursion, pattern matching and hard, static typing. It is also much easier proving correctness and doing automatic tests. Parallelization should also be put into consideration, where Haskell outperforms other languages by far without adding any security risks. I suppose this might be a great advantage in the future for scalability (although I’m not sure, haven’t really thought about it much). In my (probably biased opinion), Haskell is absolutely the language of main inspiration.

        Reply
        user

        Author Jean-Philippe Green

        Posted at 9:47 pm June 20, 2016.

        It’s not just good typing mechanism that makes Haskell great (although it is a big part of it). The push for using recursion, higher order functions and pattern matching (where the compiler can tell if a possible pattern is forgotten) is also a huge deal. And let’s not forget how much easier it is to prove mathematical correctness with such a language. Haskell deals with concurrency extremely well and is safe from race conditions unless you use the IO Monad, which I suppose wouldn’t be (fully) supported by this particular Haskell-derivative. I know Haskell might look a bit intimidating to begin with, and I’m all for using some well-known syntax in the same way as F# or Rust does it, but I think the main importance is to teach people recursion and type theory.

        Reply
      user

      Author Biscazziere

      Posted at 10:17 am June 21, 2016.

      No language is able to magically guess what your original intentions were while writing a smart contract that turned out not to do what you expected. What if I code a contract in a certain way and then I claim that I never intended it that way, it was a bug?
      That’s why we have courts and lawyers out there, to help interpret contracts and laws when people disagrees on their meaning.

      Reply
    user

    Author MFWIC

    Posted at 5:03 am June 19, 2016.

    There are times even simple commands and codes could contain flaws which are overlooked by everyone. It is only human to make mistakes. We see new exploits being discovered constantly even from old sources. I think the best approach is to rethink the policies before implementation. I agree with Dave’s idea above.

    Reply
    user

    Author Biscazziere

    Posted at 10:13 am June 21, 2016.

    To me that doesn’t make much sense. You can’t expect someone to invent the ultimate “safe and simple” language, because such thing will never exist. Where you write any piece of software and you introduce a bug.

    Of course you can make it harder to introduce certain categories of bugs, but no matter what tools you use, there will always be the possibility for bugs in the way a contract has been implemented, and these kind of bugs may even be completely independent from the language itself, because no language can magically guess what you (the programmer) actually wanted to implement.

    To me this fact poses some serious doubts about the real value (not just in theory) of the whole smart contract idea.

    Reply
      user

      Author Greg Slepak

      Posted at 10:18 am June 21, 2016.

      You can’t expect someone to invent the ultimate “safe and simple” language

      ?

      Where are you getting this from?

      To me this fact poses some serious doubts about the real value (not just in theory) of the whole smart contract idea.

      You probably shouldn’t use computers then.

      Reply
        user

        Author Biscazziere

        Posted at 10:56 am June 21, 2016.

        I took it from here:
        “By “simple” I mean it contains the smallest number of elements that are necessary to express the programmer’s intent (while remaining flexible). By “safe” I mean the compiler detects and prevents a wide variety of bugs from happening in the first place.”

        The Ethereum VM is supposed to be Turing-complete, so it has to be flexible and expressive enough. You can certainly improve the language so that it’s harder to make silly mistakes, but in the end the problem is there always be bugs that can’t be detected by any sort of super advanced language/compiler, because these are misunderstanding/edge cases in the original problem you’re trying to code.

        You probably shouldn’t use computers then.

        No, the point is we can’t trust computers blindly, because computers are made by humans and are just tools. Here we’re talking about a quite innovative concept: that you can trust (very different from “use) a piece of code to handle million of dollars transactions without any kind of human arbiter in case of conflict of interest.

        Reply
user

Author Dave

Posted at 3:14 am June 19, 2016.

The additional verification and PL tools mentioned here are clearly an important research direction moving forward. But as you pointed out, intent is fundamentally complex, and it’s unrealistic to expect that most contracts will be written with all possible corner cases covered, simply because when dealing with real world events it’s not even possible to know what all possible cases are.

One idea I think is worth exploring is a social convention of designating a contract steward. This is a trusted third party who is empowered to intervene if the contract is buggy or unexpected events arise. The steward should be designated on a contract-by-contract basis so you don’t grant one entity control over all contracts. Possible candidates for the steward can be a mutual friend, an arbiter, or a escrow service-like company.

It’s important to note that, by proposing and supporting a fork, the Ethereum devs are essentially playing this role already. This is controversial for various reasons, not least of which is the fact that it’s totally unexpected and not specified in the original contract. However if a steward had been designated in the original contract, this would be much less controversial. In fact, if a steward had been designated, the attack itself may not have taken place because the attacker would have expected the steward to reverse it.

While this does take away from the automatic nature of the contracts, smart contracts would still retain many advantages over traditional contracts (they would still be self-enforcing as long as the steward does not intervene), and the trade-off may be worthwhile to give peace of mind to users of the platform.

Anyway I wrote up a more detailed exposition and would love to hear comments! Write up is here:
https://medium.com/@coriacetic/in-bits-we-trust-4e464b418f0b#.wzqo51ju9

Reply
    user

    Author MFWIC

    Posted at 4:56 am June 19, 2016.

    Agreed. Having a designated steward per contract (if elected by the person issuing the contract) is the way to go. It can be seen as an insurance policy or maybe even a bond similar to staking (sort of).

    Reply
      user

      Author sillytuna

      Posted at 10:20 am June 19, 2016.

      I suggested something like this the other day but it should be a consensus model to avoid too much centralised risk. In effect, what’s being created here is a form of internet law.

      Reply
        user

        Author Dave

        Posted at 3:14 pm June 19, 2016.

        Interesting, could you elaborate on how to use consensus? Would the intervention be triggered by the participants in the contract or by an external group?

        Reply
          user

          Author sillytuna

          Posted at 3:49 pm July 8, 2016.

          You could have options for either. It’s very situation dependent but there could be the notion of a legal authority who are paid to manage dispute resolution, including where the contract creator considers the system to be at risk.

    user

    Author Asterix

    Posted at 1:40 pm June 19, 2016.

    Weren’t the DAO stewards already selected at the beginning and listed as curators? Why wasn’t the DAO code inspected by the curators following its implementation and progressive funding via 12% of all ETH?

    Reply
      user

      Author Dave

      Posted at 3:17 pm June 19, 2016.

      The DAO creators (I’m guessing that’s what you mean by curators?) explicitly rejected the responsibility of stewarding the contract by claiming that “the code is the contract” and all other descriptions are in now way enforceable.

      Having a steward would make the opposite statement at the outset: it would say that “the code is an embodiment of the contract, but the contract expresses intents that may not be fully captured by the code”, and that the descriptions offered in conjunction with the code describing its functioning can be used as a to understand the intent behind the contract.

      Reply
        user

        Author Fabian Vogelsteller

        Posted at 6:47 pm June 22, 2016.

        The “curators” or “guardians” where simply asked to whitelist proposals, after they identified the proposal creator. They all having full time jobs, don’t work for slock.it, the DAO or got any money for this.

        Don’t mix up the DAO creators with the curators, or increasing their responsibility.

        Nobody would have thought the DAO will get that much attention.

        Reply
      user

      Author Alexander Orlov

      Posted at 3:23 pm June 19, 2016.

      It was even inspected by some security firm. However inspection is not a guarantee for unintended behavior, no matter how much due diligence is invested.

      Reply
    user

    Author Asterix

    Posted at 1:40 pm June 19, 2016.

    Weren’t the DAO stewards already selected at the beginning and listed as curators? Why wasn’t the DAO code inspected by the curators following its implementation and progressive funding via 12% of all ETH?

    Reply
    user

    Author Asterix

    Posted at 1:40 pm June 19, 2016.

    Weren’t the DAO stewards already selected at the beginning and listed as curators? Why wasn’t the DAO code inspected by the curators following its implementation and progressive funding via 12% of all ETH?

    Reply
    user

    Author Asterix

    Posted at 1:40 pm June 19, 2016.

    Weren’t the DAO stewards already selected at the beginning and listed as curators? Why wasn’t the DAO code inspected by the curators following its implementation and progressive funding via 12% of all ETH?

    Reply
    user

    Author bshanks

    Posted at 2:43 am June 20, 2016.

    Yes, and in order to patch bugs, the Steward would have dictatorial powers
    (via a supermajority vote of the curators) to nullify and replace the
    entire contract. There should be multiple Stewards for most contracts, who vote via supermajority (multisig). Perhaps they should promise to do this only in case of a
    clear and genuine software bug, or if ordered to do so by a court with
    jurisdiction over them, not for any other reason (for example, most of the time ‘game-theoretic vulnerabilities’ ‘where at the limit people even debate whether or not they’re bugs’ would not be considered ‘clear and genuine software bugs’, in the sense that the code is doing what was intended, it’s just that what was intended may have been a bad idea; in this sense the Stewards would be somewhat from traditional legal courts, in that they wouldn’t be considering what’s fair, unless ordered to do so by a court with jurisdiction over them, of course). Many of the Stewards would be professional Stewards, similar to
    professional accountants or trust executors, who work for huge firms
    which, like Big Four accounting firms, have a lot to lose if any of
    their members are caught misusing their power.

    Reply
    user

    Author bshanks

    Posted at 12:25 am June 22, 2016.

    Yes, and instead of having a single person, there should be multiple of these super-curators who vote via supermajority (multisig). They will have dictatorial power to replace the contract (to patch bugs) and perhaps they should promise never to act except in the case of (a) a clear and genuine software bug (this would not include “game-theoretic weaknesses where at the limit people even debate whether or not they’re bugs”), or (b) they are ordered to do so by a court with jurisdiction over them. That is, i would like their role to be smaller and less subjective than arbiters; they would not be supposed to determine if the original contract was well-conceived or fair, only if there was a software bug. I imagine that many of them will be professional super-curators, like professional accountants who audit or professional attorneys who serve as trustees, who are employed by Big Four firms who would have a lot to lose if any of their employees were thought to be abusing their power.

    Reply
user

Author Philip Gladstone

Posted at 3:17 am June 19, 2016.

When I look at the results of the IOCCC (http://www.ioccc.org/) the code “obviously” implements something reasonable — but in actuality, there is a hidden backdoor that allows the author to subvert the system. There have been some interesting examples of real-life security code that fails in subtle ways (Apple’s “goto fail” bug, the Juniper random number generator, etc) It is unclear whether these “bugs” were deliberately introduced by an attacker or were just accidental.

How do we know that the TheDAO contract was not deliberately implemented this way? Would it make a difference if it was deliberate?

It is extremely difficult to make any code bug free. It is also extremely difficult to keep people from finding bugs if there is an incentive for them to do so. You only need to look at the success of bug bounty programs to see what the lure of easy money will do. The assets of a smart contract are, in effect, its own bug bounty. Big Bug Bounties will (nearly always) lead to bugs being found.

Reply
    user

    Author Asterix

    Posted at 1:58 pm June 19, 2016.

    Great point. A decentralized contract could be a well designed trojan.

    Reply
user

Author Kacper Wikieł

Posted at 3:25 am June 19, 2016.

There is one question. In all that fancy tech there is question – what problem we are solving with forcing ourselves to develop decentralized “DAO” – maybe simple allowing 15 chosen oracles with computes with just database and some “safe” programming language would be sufficient. I am afraid that core thing that bitcoin offered (as prototype) was not requiring to trust third party.

If we have trusted party in ethereum now – namely Vitalik + other devs etc – maybe enlightened absolutism/ benevolent will work better.

Maybe there is no need to build complex decentralized systems and we just need just a slightly distributed system with semi trusted nodes.

“intent is fundamentally complex”

But hey! We can build some “smart contracts” just by writing better law that is understandable by anybody so resolution of any conflict would be resolved by 12 judges?

PS: IMHO anything other than giving attacker full amount which we took will be breach of contract – because it was already written that “DAO code” == “intent and self executing judge”

“The “code was its own documentation,” as people say. It was its own fine print. The hacker read the fine print better than most, better than the developers themselves.

Reply
    user

    Author The Tooth

    Posted at 10:20 am June 19, 2016.

    “It was my exasperated acknowledgement that looking for good software to count on has been a losing battle. Written by people with either no time or no money, most software gets shipped the moment it works well enough to let someone go home and see their family. What we get is mostly terrible.”

    https://medium.com/message/everything-is-broken-81e5f33a24e1#.msa4don6c

    Tl;dr: “let’s just write code without bugs” is a fully insane proposal

    Reply
      user

      Author Anatoly Ressin

      Posted at 7:38 pm June 19, 2016.

      Maybe exactly in the case of Ethereum we should prove the correctness of our programs (and attach formal verification against guaranted properties to the contract itself) (?) Of course, it will make the development more expensive, as the developers should become the lawyers and mathematicians in the same time.

      Also, I’m afraid that languages based on the imperative programming paradigm are unsuitable for the Ethereum smart contract development. I’d risk to insist that only pure functional languages with static type checking (e.g. Haskell) should be used for smart contracts. Any stateful stuff should be used only via monadic machinery…

      Reply
        user

        Author The Tooth

        Posted at 1:17 pm June 20, 2016.

        From a technical perspective, having to deal with concurrency race condition errors and rightfully call it “contract fine print” is insane (which is exactly what DAO did), type safety, functional code, obscure languages, Haskell as such don’t solve it, and the attacker was smart enough to see it.

        One of the things this system isn’t is ACID compliancy (https://en.wikipedia.org/wiki/ACID), writing financial code on a DB backend which is not ACID compliant, is incredibly bad. And this is what we have here, a simple noobie design mistake.

        Transactional memory… Would alleviate some of the problems – https://en.wikipedia.org/wiki/Software_transactional_memory#JavaScript – but I’m not sure if it would drive all the way through to full ACID.

        But from a philosophical perspective,

        it’s just putting patch upon patch of a fundamentally insecure concept to make it less insecure – it will never make it secure.

        If we, as the human race, had ways to perfectly define contract conditions in human / law terms, if our forewisdom and planning and everything was up to the task, we would do it. Instead we have judges and experts and courts and arbitration committees that deal with concepts such as “Act of God” (https://en.wikipedia.org/wiki/Act_of_God#Contract_law), the underlying laws the contracts depend on get changed and updated in time etc etc etc etc

        Slapping a piece of fragile race-condition prone code on top of all of that uncertainty, has literally no way of producing an improvement of the underlying problem,

        ant the problem is that contracts try to anticipate future, predicting future is messy and software is messier.

        If you make a bad contract you made a bad contract, if you made a bad smartcontract someone will while true { … } your ass, which is what happened here.

        Reply
    user

    Author spiroseliot

    Posted at 4:44 pm June 19, 2016.

    this is the real question now. Why anyone to use Ethereum when there are many best regulated systems outhere with a middlemen with judge and better laws?
    There is no any reason anymore.

    Reply
    user

    Author spiroseliot

    Posted at 4:44 pm June 19, 2016.

    this is the real question now. Why anyone to use Ethereum when there are many best regulated systems outhere with a middlemen with judge and better laws?
    There is no any reason anymore.

    Reply
    user

    Author spiroseliot

    Posted at 4:44 pm June 19, 2016.

    this is the real question now. Why anyone to use Ethereum when there are many best regulated systems outhere with a middlemen with judge and better laws?
    There is no any reason anymore.

    Reply
    user

    Author spiroseliot

    Posted at 4:44 pm June 19, 2016.

    this is the real question now. Why anyone to use Ethereum when there are many best regulated systems outhere with a middlemen with judge and better laws?
    There is no any reason anymore.

    Reply
    user

    Author spiroseliot

    Posted at 4:44 pm June 19, 2016.

    this is the real question now. Why anyone to use Ethereum when there are many best regulated systems outhere with a middlemen with judge and better laws?
    There is no any reason anymore.

    Reply
    user

    Author spiroseliot

    Posted at 4:44 pm June 19, 2016.

    this is the real question now. Why anyone to use Ethereum when there are many best regulated systems outhere with a middlemen with judge and better laws?
    There is no any reason anymore.

    Reply
    user

    Author spiroseliot

    Posted at 4:44 pm June 19, 2016.

    this is the real question now. Why anyone to use Ethereum when there are many best regulated systems outhere with a middlemen with judge and better laws?
    There is no any reason anymore.

    Reply
    user

    Author spiroseliot

    Posted at 4:44 pm June 19, 2016.

    this is the real question now. Why anyone to use Ethereum when there are many best regulated systems outhere with a middlemen with judge and better laws?
    There is no any reason anymore.

    Reply
    user

    Author Roger Glyndwr Lewis

    Posted at 7:04 pm June 19, 2016.

    The author of the Dark DAO split is not inncoent of an intent contrary to the good intentions of the large number of people who thought it an interesting experiment and who are horrified at the dishonesty of the Dark Dao split author. The final outcome is as yet unknown, it is really quite easy to find out if people who have contracted with the DAO expected some smart arse to make off with the lions share of the funds to their own ends and at the expense of the original investors. The hard fork and soft fork solutions mooted so far allow for people to make their intent known. The decentralised autonomus description of the grouping involved in a trustless contract does not rob the original investors of their ability to voice their intent by voting their share. On intent in general ´´if it walks like a duck and quacks like a duck ” is usually a good test for most cases and tells one all one needs to know regarding most situations. it seems this case is such a clear cut waddling perambulation that we needen´t worry ourselves overly with the Anarcho Capitalist libertarian dogma, no edge case here fellas, and ladies. The author of the Dark Dao spilit is no white hat hacker, should they turn out to make such a claim then they could justifiably be offered some sort of bounty, time will tell if they have the sense to play such a get out of jail free card meanwhile lets shut the door even after the horse has bolted. An important lesson learned lets move on and fulfill the great potential Ethereum and Bitcoin and Blockchain generally represents. Swarm and IPFS for instance are blindingly amazing innovations.

    Reply
    user

    Author Roger Glyndwr Lewis

    Posted at 7:04 pm June 19, 2016.

    The author of the Dark DAO split is not inncoent of an intent contrary to the good intentions of the large number of people who thought it an interesting experiment and who are horrified at the dishonesty of the Dark Dao split author. The final outcome is as yet unknown, it is really quite easy to find out if people who have contracted with the DAO expected some smart arse to make off with the lions share of the funds to their own ends and at the expense of the original investors. The hard fork and soft fork solutions mooted so far allow for people to make their intent known. The decentralised autonomus description of the grouping involved in a trustless contract does not rob the original investors of their ability to voice their intent by voting their share. On intent in general ´´if it walks like a duck and quacks like a duck ” is usually a good test for most cases and tells one all one needs to know regarding most situations. it seems this case is such a clear cut waddling perambulation that we needen´t worry ourselves overly with the Anarcho Capitalist libertarian dogma, no edge case here fellas, and ladies. The author of the Dark Dao spilit is no white hat hacker, should they turn out to make such a claim then they could justifiably be offered some sort of bounty, time will tell if they have the sense to play such a get out of jail free card meanwhile lets shut the door even after the horse has bolted. An important lesson learned lets move on and fulfill the great potential Ethereum and Bitcoin and Blockchain generally represents. Swarm and IPFS for instance are blindingly amazing innovations.

    Reply
    user

    Author Roger Glyndwr Lewis

    Posted at 7:04 pm June 19, 2016.

    The author of the Dark DAO split is not inncoent of an intent contrary to the good intentions of the large number of people who thought it an interesting experiment and who are horrified at the dishonesty of the Dark Dao split author. The final outcome is as yet unknown, it is really quite easy to find out if people who have contracted with the DAO expected some smart arse to make off with the lions share of the funds to their own ends and at the expense of the original investors. The hard fork and soft fork solutions mooted so far allow for people to make their intent known. The decentralised autonomus description of the grouping involved in a trustless contract does not rob the original investors of their ability to voice their intent by voting their share. On intent in general ´´if it walks like a duck and quacks like a duck ” is usually a good test for most cases and tells one all one needs to know regarding most situations. it seems this case is such a clear cut waddling perambulation that we needen´t worry ourselves overly with the Anarcho Capitalist libertarian dogma, no edge case here fellas, and ladies. The author of the Dark Dao spilit is no white hat hacker, should they turn out to make such a claim then they could justifiably be offered some sort of bounty, time will tell if they have the sense to play such a get out of jail free card meanwhile lets shut the door even after the horse has bolted. An important lesson learned lets move on and fulfill the great potential Ethereum and Bitcoin and Blockchain generally represents. Swarm and IPFS for instance are blindingly amazing innovations.

    Reply
    user

    Author MrPuzzleBox

    Posted at 7:25 pm June 19, 2016.

    Unless, of course … the “hacker”, WAS, one of the developers …

    Reply
    user

    Author Flemming Dal Jørgensen

    Posted at 6:05 am June 22, 2016.

    “PS: IMHO anything other than giving attacker full amount which we took will be breach of contract – because it was already written that “DAO code” == “intent and self executing judge”

    The ultimate judge is the consensus of the Ethereum network, no matter what you or I think to be correct. The DAO is built on Ethereum, and is there by under the Ethereum ‘Code of Laws’.

    And as I understand it (I am not a programmer) the ‘Ethereum’ Code of Laws is consensus is needed for everything.
    That the ‘Hacker’ should also have realized, but he apparently forgot there is a higher power via consensus for the overall block-chain used. But then again, could explain why he did not drain all of the DAO’s holdings. Hoping that the consensus would go in his/hers favor since there was still a considerable amount that could be salvaged from the DAO by the original DAO Token owners.

    And, interesting use of the words “we took” by the way 😉 might wanna change that LOL

    Reply
user

Author Ruchir

Posted at 4:05 am June 19, 2016.

Good read. Runaway computations should have been contained by the gas limit, so this was a surprising breach. Independently there should be a limit to the ether that can be transferred to a single entity, which may be incrementally raised based on past history. Also I think that the contracts would best be kept to simple ones – say restricted to 4 entities max, and any sophistication applied to the inputs to the contracts.

Reply
user

Author redsquirrel

Posted at 7:48 am June 19, 2016.

For anyone interested in implementing Vitalik’s suggestions in the browser-solidity project (https://ethereum.github.io/browser-solidity/ ), I’ve created an issue based on some suggestions from this post: https://github.com/ethereum/browser-solidity/issues/109.

And there’s already a PR submitted for detecting/providing warnings about possible code vulnerabilities: https://github.com/ethereum/browser-solidity/pull/107 <== We need lots of eyes/brains on this one.

Reply
user

Author Matthieu Riou

Posted at 8:33 am June 19, 2016.

“intent is fundamentally complex”

Some are but the majority aren’t. Most intents are actually fairly straightforward, easy to explain and describe in code. The Pareto principle definitely applies here, so addressing simple intentions easily is very important.

Another remark is that people are actually quite good at recognizing when what they intend is simple and easy to assert about (i.e. a should have type A) or highly complex (i.e. game theory). The problem is they only give second thoughts for the latter. So you really really want to address the former.

Reply
    user

    Author Asterix

    Posted at 1:51 pm June 19, 2016.

    Before the discussion becomes too philosophical – let’s be thankful that the DAO was hacked because it exposed many flaws in both technical and strategic decision making areas. It is an expensive lesson but also a key turning point in Ethereum’s evolution. Sometimes it takes a big catastrophe to makes us realize that key problems can’t be ignored only fixed and as Vitalik points out: that takes time and proactive multi layered solutions.

    Reply
    user

    Author Asterix

    Posted at 1:51 pm June 19, 2016.

    Before the discussion becomes too philosophical – let’s be thankful that the DAO was hacked because it exposed many flaws in both technical and strategic decision making areas. It is an expensive lesson but also a key turning point in Ethereum’s evolution. Sometimes it takes a big catastrophe to makes us realize that key problems can’t be ignored only fixed and as Vitalik points out: that takes time and proactive multi layered solutions.

    Reply
    user

    Author Asterix

    Posted at 1:51 pm June 19, 2016.

    Before the discussion becomes too philosophical – let’s be thankful that the DAO was hacked because it exposed many flaws in both technical and strategic decision making areas. It is an expensive lesson but also a key turning point in Ethereum’s evolution. Sometimes it takes a big catastrophe to makes us realize that key problems can’t be ignored only fixed and as Vitalik points out: that takes time and proactive multi layered solutions.

    Reply
    user

    Author Dave

    Posted at 3:11 pm June 19, 2016.

    I disagree. We think that intent is simple but in fact it is usually much more complicated than it looks. To give a flippant but still illustrative example: suppose I go to restaurant and I buy a burger and fries. A simple transaction with simple intent, right? But what if my fries are soggy? Should I get a refund? What if I think my fries are soggy but the store manager doesn’t? Who gets to be the arbiter of sogginess, the customer or the merchant?

    Even in such a simple scenario intent is much more nuanced than at first glance. And intent is not free from context: in America where the customer is always right, it’s likely the store manager will give the customer a refund and maybe even apologize and offer a voucher for a free meal. In France, where the customer is often considered a necessary but barely tolerated aspect of running a business, the customer might get a “C’est pas possible” and be sent on their way.

    Now move that to a serious context where millions of dollars are at stake and you can see that even for simple-seeming contracts we need safeguards for addressing and adjudicating the gap between intent, implementation, and the real world.

    Reply
      user

      Author Matthieu Riou

      Posted at 2:00 am June 20, 2016.

      Buying a burger and fries is both non-trivial and has nothing to do with programming. Simple programming intents can be: “I want to increment that variable by 2”, “I’m expecting a string for input” or “this is only intended for use internal to my program”. Programming languages take different approaches to follow the intent more or less closely. For example Java has locks, strong typing and private packages to satisfy those intents. C has locks, and not much for safety. Haskell picked purity, strong typing and non-exported functions.

      My point is that a programming language is made for humans, and as such should either force humans to clarify their intents, or pick a non ambiguous direction. If a programming language is meant for financial transactions, I’d expect it to deal in excruciating details with safety, only-once behaviors, non-reentrancy, transactions or compensations, etc.

      Reply
        user

        Author Dave

        Posted at 3:14 am June 20, 2016.

        I sort of agree with you; the intent of individual lines of code is clear and a bug like the one that brought down the DAO was completely avoidable. However, I still think in a larger context intent is not clear. Even in larger software systems intent becomes hard to gauge. Bugs in complex software stem not just from coding mistakes but also from the failure, and often the impossibility, of anticipating all corner cases.

        To make it worse, smart contracts are not just about software and programming. They’re supposed to govern real world relationships and transactions, which are even more unpredictable. If you agree that buying a burger and fries carries a non-trivial intent, then I think you would agree that most intents in the real world are not straightforward. It is in the real world where smart contracts will have to prove they can be relied on if we want them to be widely used.

        Reply
        user

        Author Biscazziere

        Posted at 10:30 am June 21, 2016.

        “…a programming language is made for humans, and as such should either force humans to clarify their intents, or pick a non ambiguous direction.”

        Programming languages don’t and can’t force anyone to do anything. They are just a tool you use to express a concept. If that concept is ambiguous or hard to explain, nothing will magically make it easy to define. The point is you can of course create more expressive languages, but the ambiguity most of the time is not in the code, but instead it is in the concept you’re trying to write down in code.

        The same happens with human languages too: how many times you failed to express your true feelings through words because in reality your feelings are way too complicated to the point your very self doesn’t know exactly what they are?

        Reply
user

Author animalparty

Posted at 9:13 am June 19, 2016.

People have now woken up to the fact that Ethereum has very little use cases after all, because it’s mighty hard to do anything on a large scale without extreme risk.

Reply
    user

    Author Asterix

    Posted at 1:43 pm June 19, 2016.

    It is too early to make such a huge judgment. Ethereum as a system presents a very powerful decentralized technology that has ways to go before it matures. Let the DAO scandal be a future lesson that Ethereum’s development needs be proactive, not reactive.

    Reply
      user

      Author spiroseliot

      Posted at 9:15 pm June 19, 2016.

      where you see this decentralized technology when obviously in the first serious problem you use a middle men to clear the mess?
      This project is simple dead and imo will never recover.

      Reply
    user

    Author Asterix

    Posted at 1:43 pm June 19, 2016.

    It is too early to make such a huge judgment. Ethereum as a system presents a very powerful decentralized technology that has ways to go before it matures. Let the DAO scandal be a future lesson that Ethereum’s development needs be proactive, not reactive.

    Reply
user

Author David Roon

Posted at 9:33 am June 19, 2016.

The DAO debacle has shown us two things:
1. It is hard to get everything right in Solidity
2. Although having immutable smart contracts seems powerful, it becomes problematic when the way to update your code takes so much time.

I think most of the issues listed above are due to the fact that it is not trivial to see from the code alone that this may happen.

In the list I see two main bugs where you can’t avoid them without explicitly think about them while coding:
– gas limit
– recursive call

I had seen in a security audit of another smart contract that number overflow might be a problem too. For the recursive call issue, basically we have this bug because the intend is not to trigger code but instead to send funds. Why isn’t it possible to do exactly this? Let’s imagine we can do a msg.sender.call.value(balance).sendOnly(); that will not trigger any call on the other hand.
Then you will have to separate the two and in the case of the DAO you will need to call explicitly an extra function in this case. But then you can knowingly send only ether without having to fear whether some code will be run or not.

And then full IDEs can create a warning if it is not explicit in the code whether you expect code to be run by your transaction or not. I understand that this kind of solutions can create issues with existing smart contracts but I am sure there is a way to handle it properly.

I am sure we can improve compilers to make the generated bytecode safer. We need safegards to prevent this kind of issues. Things like uint overflow and recursive calls can be handled on the language level and they should.

Reply
user

Author David Roon

Posted at 9:33 am June 19, 2016.

The DAO debacle has shown us two things:
1. It is hard to get everything right in Solidity
2. Although having immutable smart contracts seems powerful, it becomes problematic when the way to update your code takes so much time.

I think most of the issues listed above are due to the fact that it is not trivial to see from the code alone that this may happen.

In the list I see two main bugs where you can’t avoid them without explicitly think about them while coding:
– gas limit
– recursive call

I had seen in a security audit of another smart contract that number overflow might be a problem too. For the recursive call issue, basically we have this bug because the intend is not to trigger code but instead to send funds. Why isn’t it possible to do exactly this? Let’s imagine we can do a msg.sender.call.value(balance).sendOnly(); that will not trigger any call on the other hand.
Then you will have to separate the two and in the case of the DAO you will need to call explicitly an extra function in this case. But then you can knowingly send only ether without having to fear whether some code will be run or not.

And then full IDEs can create a warning if it is not explicit in the code whether you expect code to be run by your transaction or not. I understand that this kind of solutions can create issues with existing smart contracts but I am sure there is a way to handle it properly.

I am sure we can improve compilers to make the generated bytecode safer. We need safegards to prevent this kind of issues. Things like uint overflow and recursive calls can be handled on the language level and they should.

Reply
user

Author David Roon

Posted at 9:33 am June 19, 2016.

The DAO debacle has shown us two things:
1. It is hard to get everything right in Solidity
2. Although having immutable smart contracts seems powerful, it becomes problematic when the way to update your code takes so much time.

I think most of the issues listed above are due to the fact that it is not trivial to see from the code alone that this may happen.

In the list I see two main bugs where you can’t avoid them without explicitly think about them while coding:
– gas limit
– recursive call

I had seen in a security audit of another smart contract that number overflow might be a problem too. For the recursive call issue, basically we have this bug because the intend is not to trigger code but instead to send funds. Why isn’t it possible to do exactly this? Let’s imagine we can do a msg.sender.call.value(balance).sendOnly(); that will not trigger any call on the other hand.
Then you will have to separate the two and in the case of the DAO you will need to call explicitly an extra function in this case. But then you can knowingly send only ether without having to fear whether some code will be run or not.

And then full IDEs can create a warning if it is not explicit in the code whether you expect code to be run by your transaction or not. I understand that this kind of solutions can create issues with existing smart contracts but I am sure there is a way to handle it properly.

I am sure we can improve compilers to make the generated bytecode safer. We need safegards to prevent this kind of issues. Things like uint overflow and recursive calls can be handled on the language level and they should.

Reply
user

Author fav

Posted at 9:48 am June 19, 2016.

If you are developing a multimillion-dollar smart contract application, consider reaching out to security researchers and work with them on using your project as a test case for various verification tools

really great post, but this one is triggering me.

why should they? you were one of the first advertising a soft/hardfork to fix the mess thedao created – why should a company blow millions if they can just come up and get their mess-up reversed?

Reply
    user

    Author sillytuna

    Posted at 10:23 am June 19, 2016.

    Because timing. This has shown up the security issues for all to see in glorious technicolour. Peopke forget how early and hew this is, and how poor the tools are right now.

    Reply
user

Author plutoegg

Posted at 10:32 am June 19, 2016.

What about the ~5000 ether accidentally sent here due to whitespace before addresses: https://live.ether.camp/account/0000000000000000000000000000000000000000

Reply
user

Author plutoegg

Posted at 10:32 am June 19, 2016.

What about the ~5000 ether accidentally sent here due to whitespace before addresses: https://live.ether.camp/account/0000000000000000000000000000000000000000

Reply
user

Author Sergey Pepyakin

Posted at 11:19 am June 19, 2016.

For standartisation thing, Solidity definatelly needs something like Cargo, npm, or such community supported tool.

Reply
    user

    Author Nikolai Mushegian

    Posted at 3:23 pm June 19, 2016.

    Want to plug our toolchain https://nexusdev.us, it was initially funded by DevGrants and Maker and is now being maintained by several full-time devs

    Reply
user

Author ETHApps

Posted at 1:31 pm June 19, 2016.

Regarding secure PRNG inside Ethereum contracts here is a “challenge” going on:

https://forum.ethereum.org/discussion/7760/ethereum-prng-challenge

Reply
user

Author ETHApps

Posted at 1:31 pm June 19, 2016.

Regarding secure PRNG inside Ethereum contracts here is a “challenge” going on:

https://forum.ethereum.org/discussion/7760/ethereum-prng-challenge

Reply
user

Author ETHApps

Posted at 1:31 pm June 19, 2016.

Regarding secure PRNG inside Ethereum contracts here is a “challenge” going on:

https://forum.ethereum.org/discussion/7760/ethereum-prng-challenge

Reply
user

Author ETHApps

Posted at 1:31 pm June 19, 2016.

Regarding secure PRNG inside Ethereum contracts here is a “challenge” going on:

https://forum.ethereum.org/discussion/7760/ethereum-prng-challenge

Reply
user

Author SambodhiPrem

Posted at 1:47 pm June 19, 2016.

Typo? “The philosophy behind this fact has been best formalized by the friendly AI research community, where is bears the names of “complexity of value” and “fragility of value“.” – “it bears”?

Reply
    user

    Author Philip Dartnell

    Posted at 2:36 pm June 19, 2016.

    At first I thought you were calling into question the words “bears” and that perhaps you were suggesting it should be “bares”. Ha! But yes, “is” should be “it”.

    Reply
user

Author SambodhiPrem

Posted at 1:47 pm June 19, 2016.

Typo? “The philosophy behind this fact has been best formalized by the friendly AI research community, where is bears the names of “complexity of value” and “fragility of value“.” – “it bears”?

Reply
user

Author Alexander Orlov

Posted at 3:08 pm June 19, 2016.

We should fork the protocol to fix all those contracts as well! …or are those contracts less important, maybe too small not to fail? Are all contracts equal but some contracts are more equals then others? Questions over questions…

Reply
user

Author William Mougayar

Posted at 3:15 pm June 19, 2016.

Intent doesn’t have to be fundamentally complex if it’s clearly communicated. If it’s not, then it can be subject to interpretations which are the causes of complexity as an outcome.

Reply
    user

    Author Dave

    Posted at 3:19 pm June 19, 2016.

    See below my example about burgers and fries. (No, seriously!)

    Reply
    user

    Author Biscazziere

    Posted at 10:41 am June 21, 2016.

    Now I’m no expert in these kind of things, but In my opinion intent is never trivial to clearly communicated, because intent has a personal, not universal meaning.

    See this definition:
    “Intent: the state of a person’s mind that directs his or her actions toward a specific object.”
    Now, how can you formally code that down in a way no one can argue about your original intention?
    For all we know, the bug in the DAO contract could have been placed there intentionally (I personally don’t believe so, but the point is that there should no need to believe!)
    A part from these “obvious” bugs, there are endless cases where bugs are not introduced because of a programming language misuse, but just because you misinterpreted or overlooked some edge cases. What if I write a smart contract in a way and then later on I claim that I didn’t intend for it to behave that way? It’s too late. And because no one will ever be able to write a piece of software bug-free, I believe this challenges the very idea of smart contracts in practice (code is law, no external entities required), as who will actually trust the system?

    Reply
      user

      Author William Mougayar

      Posted at 11:51 am June 21, 2016.

      Well, the intent in this case for the dao was the distribute funds to legit projects. It was clearly stated. The hacker’s intent was to misappropriate the funds. That was clear too.

      Of course there needs to be a tight linkage between any smart contract and their intended purpose to prevent leakage of intent.

      ​Order my new best-seller, The Business Blockchain

      Check out the book site and latest reviews on it. ————————
      William Mougayar

      Founder, Startup Management
      c: 416.648.7010
      e: wmougayar@gmail.com
      t: @wmougayar and @startupmanage
      w: Startup Management

      Reply
user

Author Benjamin Tannenbaum

Posted at 3:42 pm June 19, 2016.

Safety checks at the level of block explorers is better than at the level of development of course, but these block level checks could contain intentional bugs themselves. Then who will check the safety checks?

It is a version of the “who regulates the regulator” issue, whose solution has so far been a court of justice.

Reply
user

Author Bruce Swanson

Posted at 4:14 pm June 19, 2016.

Could the emerging Augur system be relevant to solving this problem?

Reply
user

Author Bruce Swanson

Posted at 4:14 pm June 19, 2016.

Could the emerging Augur system be relevant to solving this problem?

Reply
user

Author Bruce Swanson

Posted at 4:14 pm June 19, 2016.

Could the emerging Augur system be relevant to solving this problem?

Reply
user

Author Bruce Swanson

Posted at 4:14 pm June 19, 2016.

Could the emerging Augur system be relevant to solving this problem?

Reply
user

Author Bruce Swanson

Posted at 4:14 pm June 19, 2016.

Could the emerging Augur system be relevant to solving this problem?

Reply
user

Author Bruce Swanson

Posted at 4:14 pm June 19, 2016.

Could the emerging Augur system be relevant to solving this problem?

Reply
user

Author Bruce Swanson

Posted at 4:14 pm June 19, 2016.

Could the emerging Augur system be relevant to solving this problem?

Reply
user

Author Bruce Swanson

Posted at 4:14 pm June 19, 2016.

Could the emerging Augur system be relevant to solving this problem?

Reply
user

Author Bruce Swanson

Posted at 4:14 pm June 19, 2016.

Could the emerging Augur system be relevant to solving this problem?

Reply
user

Author Bruce Swanson

Posted at 4:14 pm June 19, 2016.

Could the emerging Augur system be relevant to solving this problem?

Reply
user

Author Rich Lockwood

Posted at 4:19 pm June 19, 2016.

The bitcoin blockchain contemplated and coded responses to the fraud triangle whereby incentive, justification, and opportunity to screw the other party in a transaction cost more than could be gained by behaving badly. Automated consensus and proof of work are powerful and extraordinarily difficult to achieve. I’m amazed at Satoshi’s genius.

Reply
user

Author Rich Lockwood

Posted at 4:19 pm June 19, 2016.

The bitcoin blockchain contemplated and coded responses to the fraud triangle whereby incentive, justification, and opportunity to screw the other party in a transaction cost more than could be gained by behaving badly. Automated consensus and proof of work are powerful and extraordinarily difficult to achieve. I’m amazed at Satoshi’s genius.

Reply
user

Author spiroseliot

Posted at 4:42 pm June 19, 2016.

ok and you create a middle man to solve the problem of one crap app? lol what a crap system you have create?

Reply
user

Author spiroseliot

Posted at 4:42 pm June 19, 2016.

ok and you create a middle man to solve the problem of one crap app? lol what a crap system you have create?

Reply
user

Author spiroseliot

Posted at 4:42 pm June 19, 2016.

ok and you create a middle man to solve the problem of one crap app? lol what a crap system you have create?

Reply
user

Author Michael Kilday

Posted at 5:00 pm June 19, 2016.

Right on track as usual V, looks like your on the path to being the next Bill Gates (the decentralized version of course). Thanks for all your VERY hard work and dedication.

Reply
user

Author Michael Kilday

Posted at 5:00 pm June 19, 2016.

Right on track as usual V, looks like your on the path to being the next Bill Gates (the decentralized version of course). Thanks for all your VERY hard work and dedication.

Reply
user

Author spiroseliot

Posted at 5:03 pm June 19, 2016.

You have only to do 3 things to save your system but you do nothing.

to leave the system alone to ballance itself, to leave dao to die
to create better programming tools for the system
to not allow anyone to destroy tha base philosophy of smart contracts.

what you do instead of that?

you have protect the slock.it team and their developer. Is like bitcoin developers protect Karpelas back in 2014.
you are not only leave the flaw active but you do nothing to solve the root of this problem which is the poor programming language of ethereum
3.You decide to destroy the base of your system which is autonomous and decentralised. You decide to create a middlemen decision when any problem appear now and in the future.

And the real question is.
Why anyone to trust you from now?
Why anyone in the future to put money in an smart contract with so high risk of another flaw?
Why anyone not to use better option outhere with way better financial protections and laws?

In my opinion your system is simple dead.

Reply
user

Author Ansgar Dietrichs

Posted at 5:26 pm June 19, 2016.

I don’t like the idea of banning re-entrancy. Why not have some standardized mutex lock?
I think a simple
bool locked;
function lock() internal { locked = true; }
function unlock() internal { locked = false; }
modifier noReentrancy { if (locked) throw; _ }
and then
function doStuff() noReentrancy { lock(); do stuff; unlock(); }
would be sufficient for most contracts. You could even add a
uint unlockBlockNumber;
function emergencyUnlock() { if (unlockBlockNumber && unlockBlockNumber != block.number) {unlock();} else {unlockBlockNumber = block.number} }
function unlock() internal { unlockBlockNumber=0; locked = false; }
to have a manual override if you somehow manage to lock() without unlock().
You could obviously have more complex lock() and unlock() functions. Seems to me to be a reasonable best-practice solution for the re-entrancy problem.

Reply
user

Author Ansgar Dietrichs

Posted at 5:26 pm June 19, 2016.

I don’t like the idea of banning re-entrancy. Why not have some standardized mutex lock?
I think a simple
bool locked;
function lock() internal { locked = true; }
function unlock() internal { locked = false; }
modifier noReentrancy { if (locked) throw; _ }
and then
function doStuff() noReentrancy { lock(); do stuff; unlock(); }
would be sufficient for most contracts. You could even add a
uint unlockBlockNumber;
function emergencyUnlock() { if (unlockBlockNumber && unlockBlockNumber != block.number) {unlock();} else {unlockBlockNumber = block.number} }
function unlock() internal { unlockBlockNumber=0; locked = false; }
to have a manual override if you somehow manage to lock() without unlock().
You could obviously have more complex lock() and unlock() functions. Seems to me to be a reasonable best-practice solution for the re-entrancy problem.

Reply
user

Author Ansgar Dietrichs

Posted at 5:26 pm June 19, 2016.

I don’t like the idea of banning re-entrancy. Why not have some standardized mutex lock?
I think a simple
bool locked;
function lock() internal { locked = true; }
function unlock() internal { locked = false; }
modifier noReentrancy { if (locked) throw; _ }
and then
function doStuff() noReentrancy { lock(); do stuff; unlock(); }
would be sufficient for most contracts. You could even add a
uint unlockBlockNumber;
function emergencyUnlock() { if (unlockBlockNumber && unlockBlockNumber != block.number) {unlock();} else {unlockBlockNumber = block.number} }
function unlock() internal { unlockBlockNumber=0; locked = false; }
to have a manual override if you somehow manage to lock() without unlock().
You could obviously have more complex lock() and unlock() functions. Seems to me to be a reasonable best-practice solution for the re-entrancy problem.

Reply
user

Author Ansgar Dietrichs

Posted at 5:26 pm June 19, 2016.

I don’t like the idea of banning re-entrancy. Why not have some standardized mutex lock?
I think a simple
bool locked;
function lock() internal { locked = true; }
function unlock() internal { locked = false; }
modifier noReentrancy { if (locked) throw; _ }
and then
function doStuff() noReentrancy { lock(); do stuff; unlock(); }
would be sufficient for most contracts. You could even add a
uint unlockBlockNumber;
function emergencyUnlock() { if (unlockBlockNumber && unlockBlockNumber != block.number) {unlock();} else {unlockBlockNumber = block.number} }
function unlock() internal { unlockBlockNumber=0; locked = false; }
to have a manual override if you somehow manage to lock() without unlock().
You could obviously have more complex lock() and unlock() functions. Seems to me to be a reasonable best-practice solution for the re-entrancy problem.

Reply
user

Author Neo Godvicien

Posted at 5:29 pm June 19, 2016.

Please, read this : an high level language for smart contracts :
http://www.commonaccord.org/

Reply
user

Author Neo Godvicien

Posted at 5:29 pm June 19, 2016.

Please, read this : an high level language for smart contracts :
http://www.commonaccord.org/

Reply
user

Author MrPuzzleBox

Posted at 6:11 pm June 19, 2016.

Lawyers: The next professional upgrade. Ethereum will ultimately result in a new certification for lawyers: Digital contracts. Last time I checked, people often consulted attorneys for services such as contract writing. What they often discover is that there are as many hacks in law as in I.T. HOWEVER, find a COMPETENT LAWYER and WOW … the benefits can actually justify the price. And this is what we’re discussing – at least in part: The logic within a contract and beating down loopholes that circumvent INTENT. A digital contract IS a computer program. And, while nobody here may have ever written a program with a bug, –it happens all the time in the real world (and I have seen some wowsers). While some of these perils will be solved by solutions proposed, — the MAJORITY will be tackled by competent minds that pay attention to details and also see intuitively where the Devil may like to go in the details. Odd results compound exponentially with complexity. Simpler is better. And may the next generation of lawyers carry large malpractice policies…

Reply
user

Author MrPuzzleBox

Posted at 6:11 pm June 19, 2016.

Lawyers: The next professional upgrade. Ethereum will ultimately result in a new certification for lawyers: Digital contracts. Last time I checked, people often consulted attorneys for services such as contract writing. What they often discover is that there are as many hacks in law as in I.T. HOWEVER, find a COMPETENT LAWYER and WOW … the benefits can actually justify the price. And this is what we’re discussing – at least in part: The logic within a contract and beating down loopholes that circumvent INTENT. A digital contract IS a computer program. And, while nobody here may have ever written a program with a bug, –it happens all the time in the real world (and I have seen some wowsers). While some of these perils will be solved by solutions proposed, — the MAJORITY will be tackled by competent minds that pay attention to details and also see intuitively where the Devil may like to go in the details. Odd results compound exponentially with complexity. Simpler is better. And may the next generation of lawyers carry large malpractice policies…

Reply
user

Author MrPuzzleBox

Posted at 6:11 pm June 19, 2016.

Lawyers: The next professional upgrade. Ethereum will ultimately result in a new certification for lawyers: Digital contracts. Last time I checked, people often consulted attorneys for services such as contract writing. What they often discover is that there are as many hacks in law as in I.T. HOWEVER, find a COMPETENT LAWYER and WOW … the benefits can actually justify the price. And this is what we’re discussing – at least in part: The logic within a contract and beating down loopholes that circumvent INTENT. A digital contract IS a computer program. And, while nobody here may have ever written a program with a bug, –it happens all the time in the real world (and I have seen some wowsers). While some of these perils will be solved by solutions proposed, — the MAJORITY will be tackled by competent minds that pay attention to details and also see intuitively where the Devil may like to go in the details. Odd results compound exponentially with complexity. Simpler is better. And may the next generation of lawyers carry large malpractice policies…

Reply
user

Author MrPuzzleBox

Posted at 6:11 pm June 19, 2016.

Lawyers: The next professional upgrade. Ethereum will ultimately result in a new certification for lawyers: Digital contracts. Last time I checked, people often consulted attorneys for services such as contract writing. What they often discover is that there are as many hacks in law as in I.T. HOWEVER, find a COMPETENT LAWYER and WOW … the benefits can actually justify the price. And this is what we’re discussing – at least in part: The logic within a contract and beating down loopholes that circumvent INTENT. A digital contract IS a computer program. And, while nobody here may have ever written a program with a bug, –it happens all the time in the real world (and I have seen some wowsers). While some of these perils will be solved by solutions proposed, — the MAJORITY will be tackled by competent minds that pay attention to details and also see intuitively where the Devil may like to go in the details. Odd results compound exponentially with complexity. Simpler is better. And may the next generation of lawyers carry large malpractice policies…

Reply
user

Author MrPuzzleBox

Posted at 6:11 pm June 19, 2016.

Lawyers: The next professional upgrade. Ethereum will ultimately result in a new certification for lawyers: Digital contracts. Last time I checked, people often consulted attorneys for services such as contract writing. What they often discover is that there are as many hacks in law as in I.T. HOWEVER, find a COMPETENT LAWYER and WOW … the benefits can actually justify the price. And this is what we’re discussing – at least in part: The logic within a contract and beating down loopholes that circumvent INTENT. A digital contract IS a computer program. And, while nobody here may have ever written a program with a bug, –it happens all the time in the real world (and I have seen some wowsers). While some of these perils will be solved by solutions proposed, — the MAJORITY will be tackled by competent minds that pay attention to details and also see intuitively where the Devil may like to go in the details. Odd results compound exponentially with complexity. Simpler is better. And may the next generation of lawyers carry large malpractice policies…

Reply
user

Author Jeff

Posted at 11:20 pm June 19, 2016.

Mr. Buterin,

You simply cannot have it both ways. Either the code is binding or it is not. Elimination of “trusted third parties” with imperfect motives and imperfect understanding is THE essential value of the blockchain. It’s the purpose of the blockchain and what makes the blockchain revolutionary.

Now you want to inject “trusted third parties” into the blockchain. That is not the solution. The solution is writing better code. I’ve been a lawyer for 25 years. If a lawyer fails to draft a contract that addresses all contingencies then the contract can fail. Lawyers learn from those failures and contracts get better. You must allow contracts to fail so contracts can become better and so people know they need to write better contracts. The important thing is that people must be able to trust the integrity of the system.

Like all good decisions, you need to look past the short term benefits to you and others in the DAO and look at the long term harm to Ethereum and the blockchain generally. You cannot have ad hoc do-overs like this, even if the equities are overwhelming as they are here. If Ethereum loses its only value, the ability to eliminate trusted third parties in transactions, it will have no value and it will vanish. The blockchain is a revolutionary and wonderful technology. I am afraid you do not truly understand what you have and what you are about to lose forever.

Reply
user

Author Jeff

Posted at 11:20 pm June 19, 2016.

Mr. Buterin,

You simply cannot have it both ways. Either the code is binding or it is not. Elimination of “trusted third parties” with imperfect motives and imperfect understanding is THE essential value of the blockchain. It’s the purpose of the blockchain and what makes the blockchain revolutionary.

Now you want to inject “trusted third parties” into the blockchain. That is not the solution. The solution is writing better code. I’ve been a lawyer for 25 years. If a lawyer fails to draft a contract that addresses all contingencies then the contract can fail. Lawyers learn from those failures and contracts get better. You must allow contracts to fail so contracts can become better and so people know they need to write better contracts. The important thing is that people must be able to trust the integrity of the system.

Like all good decisions, you need to look past the short term benefits to you and others in the DAO and look at the long term harm to Ethereum and the blockchain generally. You cannot have ad hoc do-overs like this, even if the equities are overwhelming as they are here. If Ethereum loses its only value, the ability to eliminate trusted third parties in transactions, it will have no value and it will vanish. The blockchain is a revolutionary and wonderful technology. I am afraid you do not truly understand what you have and what you are about to lose forever.

Reply
user

Author Jeff

Posted at 11:20 pm June 19, 2016.

Mr. Buterin,

You simply cannot have it both ways. Either the code is binding or it is not. Elimination of “trusted third parties” with imperfect motives and imperfect understanding is THE essential value of the blockchain. It’s the purpose of the blockchain and what makes the blockchain revolutionary.

Now you want to inject “trusted third parties” into the blockchain. That is not the solution. The solution is writing better code. I’ve been a lawyer for 25 years. If a lawyer fails to draft a contract that addresses all contingencies then the contract can fail. Lawyers learn from those failures and contracts get better. You must allow contracts to fail so contracts can become better and so people know they need to write better contracts. The important thing is that people must be able to trust the integrity of the system.

Like all good decisions, you need to look past the short term benefits to you and others in the DAO and look at the long term harm to Ethereum and the blockchain generally. You cannot have ad hoc do-overs like this, even if the equities are overwhelming as they are here. If Ethereum loses its only value, the ability to eliminate trusted third parties in transactions, it will have no value and it will vanish. The blockchain is a revolutionary and wonderful technology. I am afraid you do not truly understand what you have and what you are about to lose forever.

Reply
user

Author nagleonce

Posted at 12:16 am June 20, 2016.

Using a Turing-complete programming environment for contracts was a fundamental design mistake. Some declarative form, such as if-then rules, would have been much easier to audit. It’s loop-free, so you get guaranteed termination.

Reply
user

Author nagleonce

Posted at 12:16 am June 20, 2016.

Using a Turing-complete programming environment for contracts was a fundamental design mistake. Some declarative form, such as if-then rules, would have been much easier to audit. It’s loop-free, so you get guaranteed termination.

Reply
user

Author nagleonce

Posted at 12:16 am June 20, 2016.

Using a Turing-complete programming environment for contracts was a fundamental design mistake. Some declarative form, such as if-then rules, would have been much easier to audit. It’s loop-free, so you get guaranteed termination.

Reply
user

Author nagleonce

Posted at 12:16 am June 20, 2016.

Using a Turing-complete programming environment for contracts was a fundamental design mistake. Some declarative form, such as if-then rules, would have been much easier to audit. It’s loop-free, so you get guaranteed termination.

Reply
user

Author nagleonce

Posted at 12:16 am June 20, 2016.

Using a Turing-complete programming environment for contracts was a fundamental design mistake. Some declarative form, such as if-then rules, would have been much easier to audit. It’s loop-free, so you get guaranteed termination.

Reply
user

Author David Krmpotic

Posted at 11:28 am June 20, 2016.

Problems happen, Ethereum goes on

Reply
user

Author Alan Stubbs

Posted at 12:37 pm June 20, 2016.

can I ask a technical question? is this the right place??

these bugs, the re-entrancy one especially…… is it POSSIBLE to write ethereum virtual machine code that doesn’t have any of those bugs? (and gets something substantial like theDao done…. please don’t facetiously say ‘well the empty script has none of the bugs’ lol)

if it IS possible… then the poor choices hidden inside the solidity compiler are the thing to get sorted out. since noone is forced to use solidity, a fork should not happen.

if its NOT possible…. THEN, it seems to me, the e.v.m. language needs sorted out. And that means a fork. Not the theDao-jamming fork though…… i mean a e.v.m. redesigning kind of fork. Which might need a lot of discussion.

Reply
    user

    Author Agnostic

    Posted at 8:06 am June 22, 2016.

    Hi there, I’m newby to blockchain. I want to discuss your tech question. what fork is I know from Github (is it same term here?), Ethereum has page in wiki which says: “The value token of the Ethereum blockchain is called ether. “, but ether has no wiki page (at least ether word is not clickable in https://en.wikipedia.org/wiki/Ethereum). Ethereum greeter says: “Create your own crypto-currency with Ethereum”. If both sources are right, then ether is proposed as some superior value-token to all crypto-currencies that could be cleated with Ethereum tech (IMHO). Or ether and Ether are diffent terms. Or Ethereum term is ambiguous and there should be several wiki pager for it? I can edit wiki to make it clear on the topic. write what value-token is and how term differs from crypto-currency term. I want wiki readers to have clear picture of tech.

    Reply
user

Author FINSCHER

Posted at 1:36 am June 21, 2016.

DAO it! Show VOTINGPOWER

Reply
user

Author abelpatten

Posted at 10:52 am June 21, 2016.

It is clear that Ethereum is in a complicated situation and in need of some fundamental changes. It may be that the best course of action might be to hardfork all of the hacks/bugs and allowing for a ETH/DOA return then place a moratorium on Ethereum dapp development until best practices and solidity or a better language is developed. I also feel that the issue of Ethereum consensus must be addressed. Leaving decisions about forking and governance up to a small group of developers or the block chain miners doesn’t represent the will of the grater Ethereum community. I for one would like to see a community with validated users that have voting privileges and are rewarded for participation develop. We definitely cant allow a voting mechanism like the one used in TheDAO to be what defines consensus decisions for Ethereum! I believe that the block chains true power will be unlocked when we find the balance between human consensus and these new technologies.

Reply
    user

    Author Agnostic

    Posted at 7:32 am June 22, 2016.

    “We definitely cant allow a voting mechanism like the one used in TheDAO to be what defines consensus decisions for Ethereum!”. hi, I’m newby, where can I read about voting machanism?

    “I believe that the block chains true power will be unlocked when we find
    the balance between human consensus and these new technologies.” – I don’t get that at all. How you define balance here (IMHO these two are so different)?

    Reply
user

Author Frantic Bedlamite

Posted at 3:24 pm June 21, 2016.

Great news!
About the DAO, I think that there should be no hard fork but the remaining ETH should be given back to each single DAO investor (including me) in proportional manner. I will lose some ETH but I can take this sacrifice for the future of Ethereum.

Reply
    user

    Author Agnostic

    Posted at 7:27 am June 22, 2016.

    Hi, I do not understand, why you think you will loose some ETH when will get back your investment in proportion? And do you propose to close DAO down?

    Reply
      user

      Author Frantic Bedlamite

      Posted at 2:29 pm June 22, 2016.

      Yes, this DAO should be closed down.
      Also, DAO founders knew about exploit for long enough but ignored the warnings from other developers. It seems like they did nothing to address it.

      Reply
        user

        Author Agnostic

        Posted at 3:18 pm June 22, 2016.

        As I understand, DAO and Ethereum has same founders. Means whole Ethereum framework could be flawed? You gonna convert remaining ETH to bitcoin or what?

        Reply
          user

          Author Frantic Bedlamite

          Posted at 4:05 pm June 22, 2016.

          As far as I know DAO was founded by Slock it guys.
          Anyway, they have just found out great white hat solution to the problem and hard fork may not be needed at all, with all the funds recovered.
          https://www.reddit.com/r/ethereum/comments/4p7mhc/update_on_the_white_hat_attack/

          user

          Author Frantic Bedlamite

          Posted at 6:20 pm June 22, 2016.

          Regarding other question you asked. DAO has as much to do with Ethereum as Gox had with Bitcoin. As far as I understood, the flaw within this dao, was a flaw of this organisation’s application of Ethereum not problem with Ethereum itself. It’s is about how people apply Ethereum blockchain. They may apply it sustainably or not.

          About myself, I plan to hold my ethereum as it was an investment. I plan to keep all of it for, at least, another year hoping that the price will increase. I have not panicked and sold any of it, even when there were crashes/dumps like recent one. I believe that Ethereum will be worth many times more than it is now, after POS release.
          I also invested my ETH in DAO and I got burnt but I did not invest the amount was not able to afford in case things go bad. The problem is that many people invest more than they are able to afford as they are greedy. They are also, the ones who tend to panic sell when there is even a bit of bad news.

user

Author spiroseliot

Posted at 5:07 pm June 21, 2016.

i do a proposal for hard fork to save the lost money from one person that by mistake lost them in Jaxx wallet

https://www.reddit.com/r/ethereum/comments/4p4u3m/soft_fork_and_after_hard_for_to_recover_lost_ether/

Is not fair this person to lost his eth and in other hand the DAO person to recover their because they are only friends with developers. this is not fair.
I have done the same proposal to Bitcoin blockchain system to revert the blockchain transactions before bitfinex recent crash

https://www.reddit.com/r/Bitcoin/comments/4p4n1e/bitfinex_crash_soft_fork_now_and_after_a_hard_fork/

and it seems not to be alone

https://www.reddit.com/r/Bitcoin/comments/4p2vds/we_need_to_come_together_as_a_community_on_this/#oo

Vitalik FTW! You are the Dalai Lama of Blockchain systems. You have create a new soft-hard fork era!

Reply
user

Author twankss

Posted at 4:48 am June 22, 2016.

Forget about the DAO. Where is my damn Olympic Rewards…! No expiry announcement, aug/sept/oct multiple tries to get help, spinup olympic nodes failed in nov NO NODES, major issues, ZERO SUPPORT, tried to skype VB, denied, looks like a select few got some help on an old reddit thread, must be great to be an insider. The rest get screwed i guess. Tried skype/miner channels….zero continuity. Expiry? As long as it benefits the foundation I guess. This is blockchain tech…rewards should be good to be claimed for a year…..some of us cant drop everything for 2 weeks. Especially since the reward process was so cryptic. Intentionally. Tried Taul/Hallum etc…..dead end.
Screw the guys in the trenches. Only Insiders Win.

Reply
user

Author Agnostic

Posted at 7:14 am June 22, 2016.

Hi there.
Here http://arstechnica.com/security/2016/06/bitcoin-rival-ethereum-fights-for-its-survival-after-50-million-heist/ it says:
“Ethereum officials have proposed rolling back the blockchain in a way
that would invalidate the stolen ether. Such a “soft fork” of the
Ethereum protocol would have to be approved by 51 percent of Ethereum
miners in the form of a software update they would install on their
servers. ”

Can somebody with ”authority” (that preferably can be confirmed by some blockchain 🙂 here confirm 51% level agreement of miners is enough to roll back the ethereum blockchain?

Reply
user

Author stream512

Posted at 10:55 pm June 22, 2016.

Vitalik Buterin EXPOSED as a Toyota Illuminati member!
https://stream512.com/2016/06/22/vitalik-buterin-born-toyota-tercel/

Reply
user

Author Sergey Popov

Posted at 2:21 pm June 24, 2016.

ВИТАЛИК, ТОПИ ДАО!!!

Reply
user

Author Raghav Dua

Posted at 5:24 am June 29, 2016.

I’m kind of new to Blockchain and was hoping anyone could explain to me the difference between Ethereum and Lisk.
According to my understanding, Ethereum Apps run on Ethereum’s own standardized blockchain, whereas Lisk allows you to create your own public/private blockchain and run your apps on that.

Clarifications on both the companies’ models would be appreciated 🙂

I also know that this is not the right place to post my question, but I see the ethereum blog to be the most reliable source to get the info from.

Reply
user

Author Michael Arthur Bucko

Posted at 11:26 pm October 22, 2016.

Amazing insights! Thank you!

Reply

Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

View Comments (148) ...
Navigation