All state is mutable by default (this includes struct fields, array elements, and locals). Functions can mutate state by default. Both are overridable by explicit specifiers, much like C++ "const", but you have to remember to do so. Even then, the current implementation doesn't enforce this for functions.

Integers are fixed-size and wrap around, so it's possible to have overflow and underflow bugs. Granted, with 256 bits of precision by default that's harder to do than usual... but still pretty easy if you e.g. do arithmetic on two inputs.

Operators have different semantics depending on whether the operands are literals or not. For example, 1/2 is 0.5, but x/y for x==1 and y==2 is 0. Precision of the operation is also determined in this manner - literals are arbitrary-precision, other values are constrained by their types.

Copy is by reference or by value depending on where the operands are stored. This is implicit - the operation looks exactly the same in code, so unless you look at declarations, you don't know what it actually does. Because mutability is pervasive, this can can have far-reaching effects.

Map data type doesn't throw on non-existing keys, it just returns the default value.

The language has suffixes for literals to denote various units (e.g. "10 seconds" or "1000 ether"). This is purely syntactic sugar, however, and is not reflected in the type system in any way, so "10 second + 1000 ether" is valid code.

Statements allow, but do not require, braces around bodies. This means that dangling "else" is potentially an issue, as is anything else from the same class of bugs (such as the infamous Apple "goto fail" bug).

Functions can be called recursively with no special effort, but the stack size is rather limited, and it looks like there are no tail calls. So there's the whole class of bugs where recursion depth is defined by contract inputs.

Order of evaluation is not defined for expressions. This in a language that has value-returning mutating operators like ++!

Scoping rules are inherited from JS, meaning that you can declare variables inside blocks, but their scope is always the enclosing function. This is more of an annoyance than a real problem, because they don't have closures, which is where JS makes it very easy to shoot yourself in the foot with this approach to scoping.

Any remotely popular functional programming language created over the last years shows a better design (and taste) than this one.

And if that only attracts a certain type of programmers? (pun intended) That is, programmers valuing languages like Haskell/OCaml/F#/Kotlin/Rust, who would only ever touch C with verified compilers and 5 different static analysis tools?

Well, that's exactly kind of people you to attract to write your security-sensitive code.

Solidity is ostensibly designed to let people write smart contracts for Ethereum.

More realistically, it is a marketing tool for enabling and onboarding people onto the Ethereum platform, which Ethereum benefits monetarily (enormously so) from. Security and design are secondary goals to the extent that they help prevent disasters which hurt adoption or churn developers away.

Through this lens it's not a mystery why the language is "hacky". Perhaps being a good language is not even the driving goal.

Curious question of a non-native speaker: What does this phrase mean? (in general, and in this context)

+1 : My feelings after going thru basics of ethereum.

If they were to be as safe as possible, there would be less news, and they would push the traversal of those dialectics further into the history, when more people are using Ethereum and these kinds of events can do more damage.

It's beta. Don't worry about it. Come back in 10 years when the Heroku of Ethereum is released. Buy a couple Ethers now so you'll be rich then.

The problem is that it's just not easy to get all those details right from day 1, and interest in Ethereum has grown way faster than its capacity to produce a reliable, mature set of tools around it.

This is different from the kinds of objects that you would instantiate in a language like Java, where best practices suggest defining as immutable unless you have a good reason not to.

For starters, not all functions on the contract are supposed to be mutating. Marking those that are as such would catch accidental mistakes when unnecessary mutations happen.

Then there's the issue with structs, collections etc all also being mutable by default, which is separate of contracts.

Finally, none of this actually requires any mutability at all. A contract could treated as a pure function that takes initial state as input, and returns the new state as output. Such a function can be written without any mutations at all, by constructing the new state piece by piece from the old one.

Sure, it would be a more verbose (although functional languages usually offer shortcuts like "give me a copy of this object, but with these fields set to different values", making it not so verbose after all). But on the other hand, it means that you have to explicitly consider the effect of every operation of the contract on every bit of state. "Don't repeat yourself" is not always a good thing - when it comes to security, you often do actually want to make people do redundant things, e.g.: http://www.atlasobscura.com/articles/pointing-and-calling-ja....

Unsurprisingly, Tezos is actually written by OCaml people who seem to value the correctness of the contract language.

But not the kind of people you want to focus on to get traction for your venture-backed startup if you want a relatively quick and profitable exit

It's also quite hard for programmers to reason about performance or complexity in most functional languages. In the EVM, all functions should either be O(1) or bounded O(n) and should strive to use the most economical bytecode available to perform each task.

Disclaimer: I am a regular contributor to Solidity.

This is why I criticized the VM design as well as the language.

Yes, much effort went into making "cycle counting" as simple and straight forward as possible.

But I don't see any comparable effort doing the same for safety and correctness. (Apart from providing crypto primitives by the VM, which is neat, but only the tip of the iceberg in terms of language design.)

> It's also quite hard for programmers to reason about performance or complexity in most functional languages

This is true for Haskell, but "most" other functional languages don't suffer this issue: SML, OCaml, F#, Rust, etc.

Also note that lots of effort already went into creating lambda calculus variants where performance is especially easy to reason about. However, dismissing functional langauges as a whole already demonstrates that none that the research played any role in the design of EVM and Solidity.

In case you are interested, here is a nice starting point about the state of the art of 2014: "Structure and Efficiency of Computer Programs" https://www.cs.cmu.edu/~rwh/papers/secp/secp.pdf

I don't have much experience with the ML family of languages, so I may have jumped to conclusions based on my previous experience with Haskell/Elm, but I did not intend it to sound as a dismissal of functional languages at all.

In fact, there is a growing community of researchers working on functional language design for the EVM, but I would wager that it's way more complex to build such a compiler than something a bit more "close to the metal", especially since no one had much experience with the implications of the memory/storage/execution model of Ethereum at the time work started on Solidity, let alone the kinds of vulnerabilities these contracts would be exposed to.

Hindsight is 20/20.

Perhaps the Ethereum devs didn't have this experience, but this experience and knowledge was out there. The E programming language has been a vehicle for smart contract and security research for over 20 years. How many Ethereum and/or Solidity devs read the E research, learned the E language and played around with it?

There is also decades of research on formalized smart contract languages. Nick Szabo is well known in this space, and he wrote a draft paper on a great contract language back in 2002:

http://nakamotoinstitute.org/contract-language/

How many of the devs have read this paper?

What are the big ideas from E that Solidity is missing?

Also, the article by Nick Szabo has some interesting ideas, but as far as I understand, it does not describe a language for programming arbitrary smart contracts, just some notation for common financial contracts.

That would be cool. Even cooler would be if they created a code style culture around small contracts such that a contract should print out a legal-looking document with its own source code, when echoed to a printer.

My bet they never took any PL course, and have very vague understanding of what consequences certain design decisions would produce. "20 years of PHP coding" or something like that.

Any decent PL course would emphasize the first-class-everything (procedures , obviously), lexical scooping for proper closures, strong but dynamic typing (no implicit coersions) etc. No matter which sect one belongs to - ML or Scheme - these are universal fundamentals, the well-researched foundation.

PHP/Javascript coders usually do not understand the principles and implications behind languages they use. Otherwise they would develop a healthy aversion, like to a tasteless, vulgar porn.

Sane people with PL background would use a dialect of Scheme as a DSL (the numerical tower and all the nice things) or at least Lua (because packers are afraid of parenthesis and see nothing behind of them).

Actually, Scheme (or a simplified dialect such as the one inside Julia - flisp) would be almost ideal choice for financial DSLs.

For those who are cosplaying a PL expert (with 20 years of PHP and Javascript coding under their belt) there is a good read: http://users.rcn.com/david-moon/PLOT3/

Your comment is an example of virtue signaling, which is equally boring.

Debugging is also a nightmare. There's no way to step through function calls or set break points, even though it's basically just Javascript. Multiple classes of bugs will generate the same "invalid opcode" error that is only visible at run-time with no indication of what line even triggered the error.

This is why I invested in the Tezos crowdsale. Smart contracts are a great idea but there's gotta be a better way.

Sadly, it's not a common practice to develop contracts with full use of such tooling. See [0] for an analysis of the recent 2017 ICOs and their use of the tooling in crowdsale contracts. A few gems exist, that do quite thorough testing including a CI approach.

[0] https://medium.com/@bocytko/would-you-trust-your-money-to-a-...

I think everyone does. I certainly do. But pushing through that actually helps your designing, because you start thinking of things in terms of how the API will look, how each building block leading to the final computation will look, and the need to be able to unit-test it as you go forces you to write smaller, more tightly-focused components automatically, which ends up making more maintainable code that is easier to reason about

The only small correction I would make concerns this:

> Functions can mutate state by default. Both are overridable by explicit specifiers, much like C++ "const", but you have to remember to do so. Even then, the current implementation doesn't enforce this for functions.

When interacting with Ethereum you can do two things: send a transaction, or call a function against your local copy of the blockchain. The former is mutating, costs ether (in gas fees) and requires the transaction to be included in a block. The latter is entirely local, cost-free, and any mutations to state are ignored.

The 'constant' modifier in Solidity serves only to tag the resulting ABI of a function so that calls to it from common interfaces default to local calls instead of sending transactions. It's not intended to enforce that calls to that contract are read-only, only to indicate to callers that it should be called locally instead of creating a transaction for it.

Actually, let me rephrase this. For better or worse, Solidity is a shipping product now, so you're constrained in your ability to make breaking changes. However, its status as the "official" blessed EVM language can be changed without breaking compatibility. So I guess a better question is, are you planning to replace Solidity with a language that has more emphasis on safety in its design (even if it's called Solidity 2.0 or whatever... clearly it would have to significantly break backwards compatibility).

Now, I know that most feedback that you hear is to just take an existing functional language. But after looking at Solidity and EVM specs, I also see why this is not necessarily feasible. And, as one of your contributors has pointed out in this thread, functional style can often be too high-level to keep track of the underlying opcodes and their gas cost.

But even sticking with the imperative approach, I think it's clear that there's a lot that could be changed, starting with adopting some key principles like "explicit is better than implicit", "don't pick a default unless it's absolutely safe" etc. Looking at the design of Solidity, it's clear to me that the primary inspiration was JS with a dash of C++. The one thing that's common to both is that they allow and encourage "clever" code. Perhaps looking at Ada, Eiffel, and even COBOL for inspiration would be more appropriate for this niche.

In any case, if you're interested in specific suggestions on how to redesign, I do have some thoughts, and would be happy to share them.

There are also proposals out for a number of the issues you have mentioned. I believe that people _do_ want to make Solidity into a better language for safe code authoring, but some things require EVM changes which requires a hard fork, and other things simply require time (discussion and engineering). The impression I get is that at this point there _are_ some voices of reason involved in the Solidity language process, but it will take time before those voices can enact all of the changes listed here.

Also, keep in mind that when Ethereum launched it did so like any scrappy startup, with an MVP that was "good enough" to move things forward. Now that Ethereum is a leading contender in the blockchain race it is starting to have to pay for some of those early decisions.

On the blockchain, the VM only cares about the bytecodes you submit, not the code itself.

https://solidity.readthedocs.io/en/develop/solidity-in-depth...

Daily LoL: Googling "secure language" brings up mostly results about Java.

https://publications.lib.chalmers.se/records/fulltext/234939...

You can just skip messing with the termination checker (just don't mark your functions total) in Idris and write Haskell-ish code. The occasional rough edge aside, it's not hard to write the kind of programs we're talking about here: and if you want to prevent DDoS-like infinite looping, put the "total" annotations back in.

Starting from something like the lambda-calculus seems more sensible than starting from something like Javascript.

The E language has been a vehicle for smart contract research for decades. Joe-E is a more recent incarnation of many of the same ideas, that's a secure subset of Java.

Even replacing 256bit ints with arbitrary precision "bigints" wouldn't add too much of a cost if it's a native type of the underlying VM (as it should be for such an application IMO). It might even reduce code size by removing overflow tests.

But I would still expect arithmetic to be overflow-checked by default, as in e.g. VB.NET. This would mean that careless arithmetic on unvalidated inputs could still cause the contract to fail - but at least it would be a controllable failure, with all state changes being reversed, and hence not exploitable.

[1] http://lambda-the-ultimate.org/node/5003#comment-94646

That's not still the case with `const` and `let` in Javascript, is it? Lexical scoping still exists, but Block scoping is default now in JS

The default best practice, you mean? Declaring with 'var' will still get you the same lexical scoping rules as always.

I believe OP meant 'inherited from pre-ES6 JS'

That being said, "const" is already hardwired.

I don't think that one even matters, that the language has side-effecting expressions (through impure functions) is enough to make an undefined OOE problematic.

> Integers are fixed-size and wrap around, so it's possible to have overflow and underflow bugs. Granted, with 256 bits of precision by default that's harder to do than usual... but still pretty easy if you e.g. do arithmetic on two inputs.

That ignores the problematically trivial "type inference" of `var`: type is decided based on the smallest type which can hold the literal. So any implicitly typed variable initialised to 0 is an 8-bit unsigned integer.

In reality, all closures get the same variable, and if it is the loop counter or derived from it, and closures are executed later, then they will all see the same value - the one that said variable had after the last iteration. It's even worse if closures try to write to it.

This is something that is peculiar to JS. In most other languages, there's no similar issue, because either local variables can't be declared inside loops (or, indeed, at all, treating assignment as implicit declaration), as in Python or Ruby; or if they can, then their scope is what you'd expect it to be, as in C#, Java etc.

Writing async code using closures as continuations is not unique to JS, either. All mainstream languages support this now.

  for(var i=0; i < textures.length; i++) {
    textures[i].onload = function (i) {
      pattern[i] = ctx.createPattern(textures[i], 'repeat');
    }
  }

  for(var i=0; i < textures.length; i++) {
    createPattern(i);
  }

  function createPattern(i) {
    textures[i].onload = function() {
      pattern[i] = ctx.createPattern(textures[i], 'repeat');
    }
  }

It's interesting to see how the first virtualmachine specification for the first financial smart contract platform has overlooked all the pitfalls of the language-design industry and it doesn't look that a redesign is going to be addressed very soon because of the difficulty of the redeployment (as naturally backwards compatibility must be the first concern).

> Its hard to read the "I told you so replies", when the price of ETH has remained relatively stable during the news

Haha, so if the price is stable, this means that Solidity is not embarrassing? I'm sorry but this just means that people only care about security when their funds are the ones affected. Not about "potential" security problems or "design flaws" which sound too technical to them.

By the way, I went and looked at the offending contract. The pull request that introduced the line with the bug added 2228 new lines of code while removing 918 lines. In fact, the diff is so large that GitHub doesn't even show parts of it by default (including the part with the bug). The pull request was reviewed by a single other person, and committed on the same day it was submitted.

I don't think I'm comfortable with the barrier being that low, at all.

Not at all. Deconstruction of PL design is a popular pastime here.

> A common criticism is the way for loops and arrays are implemented are broken? Well actually they should rarely be used in contracts

If they cannot be used safely, they shouldn't be in a language.

If they can be used safely, but it requires caution and is to be rarely done, then the syntax should reflect that by not making it so easy to use them.

> Once again the type system doesn't need to be perfect, if your code on the blockchain is broken you pay a transaction fee and the contract doesn't execute it.

The type system enforces invariants that go beyond code being broken in a sense that it doesn't run. Sometimes broken code does run, with catastrophic consequences - remember Mars lander crash? That was one example of an error that could be prevented by a sufficiently advanced type system - in F#, for example, types can reflect units of measurement, and the language will plainly not allow you to do nonsensical things like add together feet and meters, without explicitly converting one way or the other.

By its very nature, smart contracts on a blockchain that deals with money have a huge potential for this sort of thing - a contract that doesn't trigger an error, but which silently behaves differently from what was intended by the author. The consequences, as we can see here, can be staggering, as in millions of dollars in damages.

It follows that the language that is used to write them should use every known mechanism to discover such errors early. This includes strong typing, immutability, explicitness, design by contract etc.

> For a language that was made less than 3 years ago

The language was not made in a vacuum 3 years ago. Other languages preceded it, and provided valuable lessons in PL design. Why these lessons weren't heeded is a reasonable question to ask.

A great motivation: it's always better to write half-assed implementations of rarely used features because they are rarely used.

> You do not need a complete language like F# and C++ to write contracts

Agreed. You need a small verifiable DSL, not an entire new language.

> Once again the type system doesn't need to be perfect

That's the spirit when designing a language!

> it amazing to see the progression

Well... yeah, if you started with the goal of executing without crashing it can only improve over time.

The initWallet function should have been marked internal, but was instead not marked. Unmarked functions default to public in Solidity, so anyone can call that function and reinitialize the wallet to be under their control

Based on the time of your post, I suspect you meant to link to:

https://github.com/paritytech/parity/blob/4c32177ef3f4521c66...

The initial poster posted this link: https://github.com/paritytech/parity/blob/master/js/src/cont...

Where "master" is the branch which normally has the latest code. And #L216 automatically scrolls down to the 216th line.

The issue is that line isn't permanent since the code in the master branch is subject to change. So in order to make a reliable link, you can link to the ref [1].

Like this: https://github.com/paritytech/parity/blob/4c32177ef3f4521c66...

You could also do it with the short ref (4c32177e): https://github.com/paritytech/parity/blob/4c32177e/js/src/co...

Normally you'd have to scroll up to the top right of the document and grab the short form it, e.g. "6b0e4f9" and replace it with master. Note that's only the ref of the last change for that blob (file) [2].

If you click the line number on a GitHub file, it will add the #LineNumber to your URL.

From there, press Y, this will replace master with the latest commit of the repo.

[1] https://git-scm.com/book/en/v2/Git-Internals-Git-References

[2] https://git-scm.com/book/en/v2/Git-Internals-Git-Objects

Language design is actually notoriously difficult in general[1], but if you're doing language design for a security-critical language[2]... well, that requires actual mechanized proof, IMO. Not just proof of "design", but proof of the implementation. Anything else is a huge gamble. (And I'm sure there are some 'investors'/gamblers who made off very well.)

[1] Beyond surface-level, obviously.

[2] We're talking about 0.0001% of the general population here.

Absolutely, few people really get this. Even those that do get it generally don't know what it looks like in practice because it's so rare.

In case you're curious about what it looks like in practice (at least one way), we presented direct user code compilation and verification[1] in Jan for our smart contract language Pact[2].

The idea that you can write a doc test that triggers a formal verification about some aspect of your code is, for lack of a better term, strange and yet the power to weight ratio is just off the charts. For the first few days that the system started working (I built the FV portion, Stuart the language + H-M type system) I thought it was broken... turned out we just had a bug in our demo code that we never noticed.

Usually, tests check the things you know to check so when they find something it's not a surprise what they find. Sometimes you can fuzz and randomly find something, which is cool but doesn't guarantee that there isn't a problem somewhere else. However, FV just feels uncanny (as a dev) because the test either finds a problem in the code -- and tells you how to replicate the bug -- OR proves that a problem cannot exist.

[1]: https://youtu.be/Nw1glriQYP8?t=1071

[2]: kadena.io/pact

I'm not sure I understand this sentence. Are you doing doctests, or are your doctests statements of formal properties, or have you abandoned that and are now doing formal specs->code type things?

At some point, it's time to blame the tool and not the user. Moreover, it's not like people didn't see this coming, myself included[1]. I mean, who really thought that basically taking JavaScript and swapping out the DOM for a bank account wasn't going to end badly? But then again, maybe I've spent too much time at in the SEC/finance where "move fast and break things" engineering gets you shown the door quite quickly. That mantra's fine for a number of domains but finance isn't one of them as one bug can bankrupt the company (see: knight capital).

It really just underlines the need for a safer/better approach. Formal Verification has to be part of that story. A language that was designed with safety in mind has to be another part.

Also, not an academic (yet at least). Cofounder here: http://kadena.io

[1]: https://goldsilverbitcoin.com/jp-morgans-blockchain-research...

I don't see any justification for this statement. The bug could easily have been discovered if there had been better auditing. That the auditing missed the bug doesn't prove that it's "practically impossible" to write secure code with Solidity.

In any case, nothing is stopping you from porting your formally verifiable language to Ethereum. The EVM is not Solidity. In fact there is already a project underway to create a verifiable programming language for the EVM.

Honest question, what would be required in your opinion for before we start considering if the tool is at fault? I ask because, if you're of the opinion that it's never the tools fault then I'll never be able to justify my point of view. Which is fine, we can disagree. I'm all for massive experimentation in this area and thus need people who disagree with me to do research down the other lines.

Also, it's not that I think it will always be practically impossible just that currently (and for the next several years at the very least) it is. We'd need way better tooling and the type of tooling needed is incredibly advanced stuff. We're not talking about a build system here, we're talking about formal verification which is one of the most advanced tools you can build. I can only think of one tool that can formally verify user generated code (cryptol) and even then it's only for a small subset of C/Java that applies to crypto work.

It's not that you can't write safe solidity contracts today but that IMO an element of luck is required. You need to get the right auditors, have them do a good enough job, implement the logic a certain way instead of another and thus avoid a bug no one has thought about before, etc... When people's money is on the line, needing luck is terrifying.

> nothing is stopping you from porting your formally verifiable language to Ethereum

I wish this were true but it isn't. We spent months trying to see if there was a way that it would work because we would have preferred this approach. The EVM itself is stopping us (as well as the shape of the Eth blockchain but we could probably have worked around that problem). Pact is interpreted, so while we could make an EVM version technically it's practically unworkable -- there's nowhere near enough gas to run the interpreter. We couldn't compile directly to EVM either as the EVM just doesn't do enough[1] for you. It's closer to a 1980's era CPU ASM than a modern VM (like the JVM). Moreover, the Pact runtime does a lot of things for you (as a safety feature) that the EVM just doesn't have a notion of. Even then, while all of the Pact-compiled-to-EVM code would work and be safe, we couldn't protect it that code from EVM code that doesn't play by Pact's rules. Moreover, supporting all the extra things that Pact does for you would make it, again, run out of gas on EVM.

This discussion is very similar to putting Ed25519 on the EVM. While you can technically implement it in EVM, it's just too gas-heavy. It's best to extend the EVM itself to do more.

That's the thing about having the EVM be Turing-complete, it makes people think that "it can do anything and thus abstracts over the problem thus solving it." This is technically true but not practically true -- all you are doing is punting a huge number problems/required features (like dispatch and module loading) down the road for the language to figure out. In a gas-metered context, every feature the language adds because the EVM lacks it costs gas and thus makes a number of features impossible in practice.

> In fact there is already a project underway to create a verifiable programming language for the EVM.

Mind linking me to it? I collect references to smart contract languages at this point and haven't heard of this one. I know the people working on the EVM + solidity formal verification project personally (well some of them at least) and it's still years away.

[1]: Great technical discussion about EVM here -- https://news.ycombinator.com/item?id=14689792

The programming language being partly at fault is not the same thing as it being "practically impossible" to write safe smart contracts that language, in my opinion.

I was taking issue with your wording, which I think gives a misleading impression of the attainability of secure Solidity code. Your follow up comment is more measured, as it doesn't characterise the need for some measure of luck to write a safe smart contract as writing a secure smart contract being "practically impossible".

Maybe we're using different definitions of "safe", but I think many use my definition, in which case your statement would give them a misleading impression.

>This discussion is very similar to putting Ed25519 on the EVM. While you can technically implement it in EVM, it's just too gas-heavy. It's best to extend the EVM itself to do more.

Yes I am aware of that. There is research being done on possibly switching the EVM to an Ethereum variant of Web Assembly, i.e. eWASM, which will be able to efficiently execute a wider range of functions.

Further on this point, I have to admit that I am not qualified enough to comment on the portability of Kadena to the EVM, so I'll take that back. What I meant to dispute was the notion that formally verifiable programming languages cannot be built for the EVM, which is the takeaway that I got from your comment. A PL of this type is in fact being developed [1].

Thanks for the link to the technical discussion on Solidity.

[1] https://github.com/pirapira/bamboo

Then, in another section of the documentation, when talking about function types [2], not specifying internal or external defaults visibility to internal.

It doesn't seem like the simplest or most consistent way to express these concepts, and certainly not the safest way.

[1] http://solidity.readthedocs.io/en/develop/contracts.html#vis... [2] http://solidity.readthedocs.io/en/develop/types.html#functio...

Your honour, in my defence, the contract clearly specified that anyone could reset the wallet, and if that's not what they wanted, they shouldn't have agreed to it.

So like most court cases, it will simply be a matter of human influence winning the case.

But yes it seems pretty asinine to use global by default for (not so) smart contracts.

Anyway, I think parent's point was to say this behavior already has been seen in javascript. Actually, it may even be inherited from javascript. When I first looked at solidity last year, I was under the impression it was a modified version of javascript, like unity3d's one. Nowadays, solidity landing page reads "high-level language whose syntax is similar to that of JavaScript", so not sure if it still is (or has ever been, for the matter) derived from something like v8 or rhino.

The reason for that choice seems not far fetched : it's not uncommon, when wanting to add scripting to something, to go with javascript, since it's arguably the most known language, developers knowing "<their main language> and javascript", especially webdevs (a blockchain app project, lisk, even made html/css/js the defacto mean to build apps). Of course, fintech is an industry where the usual values from webdev (release early, release often) have disastrous results.

  "use strict";
  foo = 1;
  var bar = 1;

It's not even in the category of weird timing attacks or complicated internal states allowing unexpected state transitions -- this is a trivial bug that could be spotted by viewing the contract in Remix (the Solidity IDE).

There are certainly some weird edge cases in the Ethereum VM programming model that are hard to UT, and I think that dev efforts in this area are under-resourced (e.g. it's currently impossible to test time-dependent contracts as there's no way of mocking out the clock in the simulated blockchain).

If you are considering writing a smart contract, read and re-read https://github.com/ConsenSys/smart-contract-best-practices, and then write UTs for each of these cases so that you can convince yourself that you've covered them.

Relevant to this bug:

> Understand that your public functions are public, and may be called maliciously. Your private data is also viewable by anyone.

This philosophy permeates the community of Etherum development.

Bitcoin disabled most of the smart contracts op codes for a very good reason.

I wouldn't recommend putting anything of value into an Etherum smart contract and find a project with more responsible developers who take a more "wait and see" approach.

If HE can't get it right, what business do you have running around saying that anyone who can make a webpage can make a decentralized application?

We are playing with money. Dealing with attackers is not as simple as rebooting your server. Mistakes mean irreversible loss.

The devs in this industry are way over their heads and nobody is willing to admit it, because doing so destroys the entire core value prop of Ethereum, the poster child of the current bubble.

"If the creator of Solidity, Gavin Wood, cannot write a secure multisig wallet in Solidity, pretty much confirms Ethereum is hacker paradise."

Parity devs may be academically brilliant, and they put out a fantastic client, but the wallet issue shows how lax their development lifecycle has been.

Though crypto has risen past the high point of each of these bubbles, each price point can be definitively classified as a bubble in it's own time, and was followed by a crash that wiped out >70% of the market cap over the coming months/years.

Though it did recover, that doesn't mean it wasn't a bubble.

I believe cryptocurrency is going to be bigger than e-commerce is today. But it's not there yet, and it shouldn't be valued as though it has changed the world. It hasn't yet, and it's still a few years away at least from doing so.

Don't short hopium.

Bitcoin is also stuck in the past. Yes, Ethereum breaks things, but for me it's not about the money but about the technology stack. We're too early in the process to have the luxury of being able to stop innovating.

If I want to play with cool state-of-the-art technology I use Ethereum. For financial transactions I use my bank and/or Transferwise. Haven't quite yet figured out why I'd use Bitcoin for something.

it should not be this easy to lose sixteen million dollars

I'm amazed that otherwise intelligence people really believe this is a better system than fiat currencies + banks.

Financial institutions are accurate to tiny tiny fractions of percentage points. Not "eh we got 99% of it right".

Now why hasn't there been as much publicity about this? Is it because Vitalik Buterin is a wunderkind genius who simply beat them to market? Nope, the Bitcoiners are simply being more responsible and making sure they get the formula right before rushing to market.

Please see this article to get an idea of the personalities involved:

http://www.newsbtc.com/2016/08/17/gregory-maxwell-vitalik-bu...

https://github.com/OpenZeppelin/zeppelin-solidity

[0] https://github.com/aragon/aragon-network-token

[1] https://github.com/Storj/storj-contracts

Some projects have started sharing audit results publicly directly in their repos [1]. It's a great read to see common errors and yet unsolved issues that originate in the ERC20 token specification.

[0] https://github.com/ConsenSys/smart-contract-best-practices#i...

[1] https://github.com/status-im/status-network-token#reviewers-...

How do these smart contract deal with the real world? I can see how they can work for things that entirely involve activities that take place on the block chain (e.g., a smart contract that automatically pays a crowd funded project if and only if it meets a threshold for pledges by a deadline, and refunds the donors otherwise).

But suppose our contract is something like I will pay you $X in Ethereum when you deliver to me 125 bales of Surat cotton, guaranteed to be middling fair merchant's Dhollorah [1], delivered at the Liverpool docks from Bombay on the next sailing of the Peerless.

How do we put all of that into a smart contract? Can a smart contract trigger payment only when the cotton arrives? Can it check to make sure it arrived on the ship specified in the contract?

And what happens if it turns out that there are two ships named Peerless, unrelated to each other, one of which is sailing from Bombay to Liverpool in October, and one in December? I only know about the December one, and it is on that one that I'm expecting the cotton. You only know about the October one, and so it is on that one you send the cotton. The cotton arrives before I'm ready to deal with.

Unless dealing with all that can be included in the smart contract, and executed by the smart contract without human intervention, lawyers will still be needed...and they will be needed almost as much as they are now.

PS: my cotton hypothetical is based on a real case: Raffles v Wichelhaus, EWHC Exch J19, (1864) 2 Hurl & C 906. There really were two unrelated ships both having and neither deserving the name Peerless, and both working the India / England trade routes, both scheduled for Bombay to Liverpool, one in October and one in December.

[1] Dhollorah is a very dirty cotton of a longish staple, which when cleared is very white, as if bleached. For for more than you probably ever wanted to know on this and other types of cotton, see the book "Cotton Spinning and Weaving: A Practical and Theoretical Treatise" by Herbert Edward Walmsley, page 71. It's from the late 19th century and is public domain now I believe, and you can find it on Google Books.

They can't deal with the real world by themselves, but where they have value in agreements involving real world events is that they allow the real world assessments to be debundled from those aspects of the agreement that can be formalized.

So in the cotton shipment example, the smart contract would have three parties assigned as Oracles that determine whether the correct ship arrives at the correct port on its correct trip. The smart contract would dictate that if 2 out of 3 of the Oracles agree that the condition has been met, then the smart contract will transfer the funds. There could also be a failsafe clause in the smart contract, that is controlled by a set of five oracles, who have the power to override the smart contract if the majority deem that an expected event occurred.

So yes you need human intervention, but only for those parts that cannot be automated. This explicit definition of what the human roles are may encourage better contracts, by forcing the counterparties to spend more time reasoning about which aspects of the smart contract are subject to ambiguity.

This is tautological and therefore means nothing.

At some point you have to ask yourself whether we really prefer that code be law, with the quality of code that's so common these days, or whether we actually like being able to specify something to a lawyer -- rather than a computer -- simply because the lawyer will return the contract and ask for clarification if something is ambiguous/unclear.

The human-to-lawyer interface is the best contract interface that exists, the only reason we use computers is because they're so cheap and fast. When we dream of AI we dream of having a computerized lawyer, who can ask clarifying questions and resolve ambiguity before it becomes a problem.