Hacker News new | past | comments | ask | show | jobs | submit login
153k Ether Stolen in Parity Multi-Sig Attack (etherscan.io)
943 points by campbelltown on July 19, 2017 | hide | past | web | favorite | 725 comments

Just skimming through the Solidity docs, I see a lot of unwise decisions there aside from the weird visibility defaults.

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.

I never understood why they chose such a hacky language (an a VM model that encourages these kinds of languages), and expect people to write supposedly secure (in the sense of: obviously correct!) code with it.

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.

99 out of 100 questions.

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.

> 99 out of 100 questions.

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

Don't feel too bad, I am a native speaker and I didn't recognize this phrase either.

Brilliant... and so true!

The answer to why most things are done is... Money !

>> it is a marketing tool for enabling and onboarding people onto the Ethereum platform

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

a marketing tool that gets your money stolen is probably counterproductive in the long run

From a Hegelian perspective, the best thing for Ethereum is for it to race back and forth across dialectics as quickly as it can. There will be many money stealing events as we discover how to do cryptocomputing safely. Better to get them over with now while the market cap is small and people know not to rely on it for anything too serious.

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 guys who just stole $30M and $70M beg to disagree.

but so is making developers write smart contracts in haskell, severely limiting the number of developers who can jump in and start coding, leading to a lack of adoption.

Being a good, secure language for writing smart contracts is absolutely one of the most important goals for Solidity. I can say so because I have been involved as a regular contributor to the compiler for more than a year. If onboarding a lot of people to the platform quickly were the goal instead, they would have ported some crippled version of Java or JS and called it a day.

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.

To pick just one: mutable state by default is very difficult to justify as being a decision intended to promote security in a tool that is literally meant to construct financial/contractual instruments.

Not that difficult. There is not much point in creating immutable contracts since they act like singletons.

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.

Just because a contract is mutable doesn't mean that everything needs to be.

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

These things are not just details. Things like scope, mutability, and operator precedence are core language design decisions.

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

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

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

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

None of the languages that you mention target the EVM, and the changes required to do so would turn them into restricted versions that look kind of like the original ones but have several differences that you need to keep in mind while programming in them. It makes quite a lot of sense to create a new language that takes advantage of the particular features provided by the EVM.

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.

> should strive to use the most economical bytecode available to perform each task.

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

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

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.

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

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:


How many of the devs have read this paper?

I mentioned that no one had much experience with the implications of Ethereum's model and you point me to a bunch of articles but I fail to see how they apply to the case of Solidity.

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.

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

Yet another data point for 'why a TC language is a bad choice for smart contracts'.

Maybe they should have restricted their memory access model by using a stackbased language like Postscript.

> like Postscript

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.

Why did you bundle an equally experimental language like kotlin amid those other well established and widely used languages?

I just wanted to also add a JVM-based language to the list, and Kotlin is the only one I'm aware of that plays remotely in the league (in terms of language design/quality) of the ML languages.

Kotlin is young rather than experimental, AFAIK there's no novel feature in Kotlin.

Yet another homegrown PHP-sque language. The Fractal Of Bad Design is actually a pattern.

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/

I feel like what you say is sensible, but that your tone is needlessly derogatory.

Needlessly? I disagree... the idea that yet another person decided to utilize Javascript as the basis for a new language is distressing and totally justifies such a response.

I think the tone of that comment is completely unjustifiable in any polite context. Also, bile obscures text: adding invective just lowers the SNR of your speech.

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

I've taken a PL course, and still have a vague understanding of the consequences of certain design decisions. Just reading this thread alone has already taught me more and ways to think of why X design is needed and what consequence does it mitigate/resolve.

Thank you for succinctly summarizing all my frustrations with Solidity. I am developing a fairly complex smart contract (i.e. not a crowdsale) and it's fucking painful. Trivial computations that would take less than an hour to do in any other language take days to implement correctly.

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.

How do you create unit tests for Solidity code? This would eliminate much of the need for a debugger while also leading to safer code

Unit tests do help, and they are relatively easy in Truffle, the most used JS framework for Solidity. I guess I need to move to more of a TDD style than I'm used to.

In fact the tolling around Solidity and smart contracts is quite rich. It's possible to write unit tests, execute contracts code on a private chain in a similar way to integration/API tests, and measure the code coverage.

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 cannot say enough good things about TDD, but YMMV. I also don't stick to it always... it's just that when I take the time to, my code clearly ends up better. I would imagine it's even MORE beneficial in code that deals with a money...

I find it hard to write tests when I'm still formulating the logic of how a problem should be solved. For money-based logic in Solidity, I now like to model it in MS Excel first, write code afterwards, and then finally tests.

> I find it hard to write tests when I'm still formulating the logic of how a problem should be solved

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

Speaking as an Ethereum core developer here - I see a lot of misdirected criticism and misunderstandings of Ethereum and the platform in the wider tech community. That said, your criticisms here are absolutely spot on; these are definite issues with Solidity as a smart contract programming language.

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.

Do you guys plan to address these at some point?

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 is an EIP that is slated to land in the upcoming hardfork that adds an EVM opcode for effectively "const" call that is enforced by the runtime: https://github.com/ethereum/EIPs/pull/214/files

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.

Seriously, these observations should be submitted to the Solidity team for consideration.

they are excellent observations, but it seems pretty clear the team would be unable to implement them properly this late in the game, or worse unable to understand why they are a good idea.

Most of these observations are well-known to the Solidity devs. I know because I participate in many of the conversations around it. While it's not easy to evolve a language (the API surface is pretty wide compared to many other programs), Solidity is indeed changing and improving regularly, only limited by the available time of their contributors.

I thought they had enough funding to hire just about anyone.

I may have enough funding to pay more that Brendan Eich is making right now. That does not mean that he will join my project. Good talent is scarce regardless of funding.

Isn't the team also working on a new language targeting the same VM? If so, they might be useful.

There are lots of different languages targeting EVM. The (IMO) most promising so far is https://github.com/ethereum/viper

You can also just write bytecode directly. It's a simple stack machine, and contracts should be as simple as possible.

Things are not always simpler at a lower level of abstraction.

It depends what simplicity you mean. The Solidity compiler is very far from simple, so if you consider that part of the complexity incurred by using Solidity, then a reasonably small bytecode program might be much easier to audit. Consider that a typical smart contract is as simple as "if four out of these six addresses make the same proposal then execute it." You can basically write these things in hexadecimal without too much trouble.

Yes, that's definitely a good idea. I will go back to my magnetized needle now, I have some bit flipping to do in order to finish my task for Monday.

Speaking seriously, there is an assembly for Ethereum called LLL. I would love to see code that performs exactly that example you mention and is easier to audit than the equivalent Solidity version.

For a stack machine, Forth might be a great choice.

Can people outside of the Ethereum org implement their own languages that target that VM?

Yes. The VM has a public specification and you can implement your own compilers for it.

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

This is an amazing write up. How long did you spend in the code before jotting this down?

I was literally writing this list down as I was reading through this:


Can someone explain to me why they chose to make their own language instead of creating a DSL inside of an existing language?

What language would you choose? AFAIK there are almost no _actually_ secure languages. The ones that exist (e.g. Idris, Agda) are notoriously hard to use (although their Turing "incompleteness" is arguably a feature for smart contracts/distributed computations).

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

Here's a master's thesis by a couple guys who made Idris compile to Ethereum bytecode.


Idris isn't difficult to use for things that don't require tons of library support (since there aren't many libraries to speak of yet), unlike Agda, which is far from a programming language in the usual sense (it's a proof assistant, and you're only really supposed to typecheck stuff with it).

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.

You might be interested in W7, an object-capability Scheme variant: http://mumble.net/~jar/pubs/secureos/secureos.html

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

> What language would you choose?

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.


Naivety, youth.

Too young, too simple, sometimes naive.

Now who the hell gave them any money for that?

Investors who have FOMO (fear of missing out).

+No Clue.

When I took a look at it, two or three years ago, I think there were three different guys in the organization each busy with his own idea of a high-level language to put on top of the VM, each inspired by a different GP language. That signaled a certain lack of focus.


This new language for Ethereum by Vitalik is exactly what you said: https://github.com/ethereum/viper

Viper's inspired by Python, which (for all the nice things we can say about it) is a _terrible_ place to go for inspiration for this kind of task.

Viper is only inspired by Python's syntax. It's not a highly reflective completely dynamic language like Python. (But this also means that it is not a "DSL inside of an existing language", contrary to what your parent claimed.)

This is because running code on Ethereum VM and storing data is hugely expensive (rightly so, as it's being done on all nodes in the world). Therefore Solidity will try to compile into a VM code that uses the least numbers of cheapest instructions and pack data into as small memory package as possible.

Most of the issues pointed out by int_19h would be handled at compile time during static analysis and wouldn't change much to the generated bytecode. I'm talking about strong typing, immutability by default, less error-prone syntax, tail calls, evaluation order etc...

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.

It's about costing the operations reliably.

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.

In the rationale document they explain that arbitrary length integers were too difficult to determine a reasonable gas cost around for math etc.

"Normal" and "secure" languages don't do this already?

Time for the Underhanded Solidity Contest? (http://www.underhanded-c.org/)

It is kind of implicit, from the core principles of Ethereum, that there is a global 24/7 Underhanded Solidity contest going on, with valuable prizes to be won.

Already happening: http://u.solidity.cc/

I am amazed/not amazed that they write financial applications in this language (and do not have the common sense to not do it).

Everything about the blockchain is a test now, it's just the investors who mindlessly invest hoping for a quick 5x is making it bigger than they should be.

Fixing the language is one step. It will still not prevent hax0rs from targeting the bytecode of the VM itself.

Perfect is the enemy of good.

If that BS was true, we should all just switch to PHP right now

On the contrary. No other language is perfect, so if you can only think of perfect you would keep using PHP; it's only if you recognise the idea that a language can be better while still being imperfect that you can switch to a better language.

The EVM has been formalized in theorem provers [1], so they're already taking that threat seriously. One threat also mentioned in the above thread that is often overlooked are full abstraction failures, ie. exploitable mismatches between high level language constructs and the machine code to which it gets compiled.

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

And you are not saying anything about the VM itself which behaves differently in certain cases... Look at our last article on this specific topic: https://blog.coinfabrik.com/smart-contract-short-address-att...

The devs really need to understand that in the niche that they're targeting, unless they can be absolutely sure that some default is safe, there should be no default. Most of these issues stem from this same fundamental problem - they pick some default, or some implicit behavior, ostensibly for convenience, but with unanticipated undesirable side effects.

I don't agree, you cannot expect to handle millions of dollars with those tools in the same way you don't write mission critical software in bash.

> Scoping rules are inherited from JS, meaning that you can declare variables inside blocks, but their scope is always the enclosing function

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

> 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'

I thought using "var" is deprecated... If there's anyone who has the chance to use let/const but still doesn't, I'd be very curious to learn about their reasoning

Bad habits, arguably. Been using JS for years so occasionally instances where a more vigilant self would use "let" still get "var" instead. I think part of this is because of issues with previous versions of v8/node where using let at the global level or without 'use strict' threw errors.

That being said, "const" is already hardwired.

I know right. Principle of least Privilege. Simple.

to get variable defined in function scope? :)

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

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.

How bound are people to using Solidity? How hard would it be to come up with a competing, more verifiable langauge specification? I don't know much about Ethereum, but I assume the Solidity gets compiled to some sort of bytecode to run on the VM?

Not at all. Solidity is just the most widely used language for the EVM. There are also Mutan (dead), Serpent (dying), LLL (recently revived), and Viper (being drafted).

This was exactly the first thought that came to mind when I first read the Solidity docs.

Your opinion about javascript and closures in particular makes me question the rest of your comment. Closures in javascript makes it easy to write async code.

What I said about the intersection of closures and variable scoping in JS is not an opinion, it's an objective fact. All too often, people try to do something like declare a var inside a loop, and spin off a closure that captures that var. The reasonable assumption is that the scope of the variable is the body of the loop, and thus every iteration gets its own new copy, and all closures are independent.

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.

What you describe is the moment someone would usually go from PITA to Ninja! From programming sequential to async using functions. The WTF code:

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

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

  function createPattern(i) {
    textures[i].onload = function() {
      pattern[i] = ctx.createPattern(textures[i], 'repeat');
In JavaScript you can now however replace var with let and it will be block scoped and the WTF code will work. It's sad though as people learning JavaScript now will not get the beauty of it and will be stuck in callback hell. Function scope in JavaScript pushes you in the right direction. It's like instead of teaching people how to fly, we give them roads so they can walk, like they are used to.

It's way more than just async callbacks. For example, you may be using a lazy sequence abstraction, with high-order functions like the usual map/filter/reduce, but with a deferred implementation (i.e. they're only applied, and functions passed as arguments are evaluated, when the next item is read from the sequence). If you create such deferred sequences inside a loop, they will again capture the mutated counter.

It is interesting to see but I think Solidity is the first software language/framework that people with no experience writing it or running it, comment and write about it on hackernews as if they did.

A common criticism is the way for loops and arrays are implemented are broken? Well actually they should rarely be used in contracts, its not like you can send ether/btc to an array recipients or in a for loop.

You do not need a complete language like F# and C++ to write contracts, The hacked contract should have had a simple modifier describing only the owner can run this command.

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.

For a language that was made less than 3 years ago, it amazing to see the progression. It will be a language that people hire for in the near future (already happening). Companies are notorious looking for 5 years experience.

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

> It is interesting to see but I think Solidity is the first software language/framework that people with no experience writing it or running it, comment and write about it on hackernews as if they did.

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.

The language was not made from "scratch" but a progression from bitcoin scripts, Ethereum is the like to blockchain dev like Unity is to gamedev, it lowers the barrier to entry, it has a lot of the similar apis and functions as bitcoin, I don't really consider this a bad thing

Do we really want to lower barrier to entry for writing code that can misdirect $30 million dollars just like that?

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.

it was missing one keyword that was the parity bug not in the 2228 lines, and the DAO hack had a line that was place 3 lines too early, a monetary system created 3 years ago and is highly demanded might have some growing pains

Can you please link to this pull request?

> It is interesting to see but I think Solidity is the first software language/framework that people with no experience writing it or running it, comment and write about it on hackernews as if they did.

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.

> for loops and arrays are implemented are broken? Well actually they should rarely be used

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.

Here's the root error I believe: https://github.com/paritytech/parity/blob/master/js/src/cont...

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

Please be aware that you can press Y before sharing a link to make it a permalink. The link you shared points to master branch, which will change over time, so the line number you pointed to will have something else.

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


Some explanation of what's happening here:

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

Thank you for that thorough explanation!

BTW, how does y shortcut works? With what is bonded? What effects brings on other sites?

It's only for GitHub. GitHub has custom JavaScript on their site that listens to every key press. If they detect you pressed 'y', they look up the commit hash of the version of the code you are looking at and then set the page URL to a page that shows the code for that version.

You just saved me hours of life time

That Y hotkey is immensely useful. Thanks!

Why would an unmarked function get the broadest possible scope in a language designed for contracts? I'm always surprised by the decisions made around Ethereum, and just how much value people have poured into it.

It's a good indicator that these people may be experts in one area, but not necessarily in others.

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.

> Not just proof of "design", but proof of the implementation.

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

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

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?

It's closest to the middle, assuming that you meant that you're stating the properties that you want to test. It does more than that, but at its base that's effectively how it works so it's close enough for a solid intuition. We're working on a paper about it now -- or at least a sub-paper in the clutch of papers that pertain to a public chain version -- that I'll link to when it's out (a couple weeks probably).

Oh. Dear?

(I mean, I understand the pressures of academia, but... ridiculously bad timing, yeah?)

Why bad timing? This is really just an example that while safe smart contracts are technically possible using Solidity/EVM, it's practically impossible. "One of the best Solidity devs" just failed to write a safe contract to the tune of a $30M exploit. Given that, what chance does anyone else have?

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

>This is really just an example that while safe smart contracts are technically possible using Solidity/EVM, it's practically impossible.

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.

> That the auditing missed the bug doesn't prove...

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

>Honest question, what would be required in your opinion for before we start considering if the tool is at fault?

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

Experts in what area? Not in programming, to think exposing functionality by default is a good design concept.

Read the Solidity documentation on visibility [1]. Public, private, internal, external, that really seem to mix overlapping concerns. In the visibility documentation, it explains that the default is public.

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

Imagine the court case:

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.

I cannot imagine the court case. The courts are utterly incapable of understanding enough of the technical aspects of far simpler software cases.

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

If you are interested in a really good counter example to your assertion you should look at Judge Alsup https://www.techdirt.com/articles/20170325/23492137003/judge...

For the same reason every variable in JavaScript is global by default... I.e. I don't have a clue how that could seem like a good idea.

That's not how JavaScript works. Variable declarations are hoisted to the start of the enclosing function scope and only undeclared variables are global by default.

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

Another way of describing that is that variables are global (scoped to the lobby, to borrow a term from the languages which came before JavaScript) unless explicitly marked with the "var" keyword, which has semantics that some languages might have chosen to give the name "local". Like: your entire premise that a variable is only the declared variables makes no sense to me as someone who teaches college-level classes in programming languages. In Python variables default to local unless marked "global". In JavaScript, variables default to captured via scope unless marked "var".

And even that undeclared-are-global thing is gone in modern js. It's explicitly an error in strict mode.

Well, if they are global when they are undeclared, that pretty much means they are global by default. Maybe a better way of putting it would be "js variables are declared global by default, when unspecified and not using strict mode".

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.

In javaScript, the following lines does different things:

  "use strict";
  foo = 1;
  var bar = 1;
"foo=1" changes the variable foo (this is very useful) and "var bar=1" creates variable bar and adds it to the function/lexical scope. If the variable foo is not created/declared, it will throw an error! But without "use strict", "foo=1" would add variable foo to the global scope! Which might create unexpected bugs if you are used to other languages that does the sane thing and adds it to the local function/lexical scope. So I suggest to always "use strict" !

Sounds like you don't know anything about JavaScript.


Would you please stop posting snarky and/or uncivil and/or unsubstantive comments? especially on divisive topics?

You've done this repeatedly, it lowers the quality of discussion, and we're hoping for better than that here. If you have a substantive point to make, make it thoughtfully; otherwise please don't comment until you do.

i know that you're not really serious when you generalize against all of us crypto simpletons, but anytime theres a stupid amount of money on the table people are bound to rush to pick it up. and that means mistakes.

the work being done on public blockchains is unlike anything else done before. You don't have he luxury of keeping your db behind a vpn running on a vm platform secured and maintained by the worlds largest companies. These engineers put themselves out there, waaaaaaaay out there to try and make shit happen. And they mostly do good work. But if banks and major retailers who have huge budgets can get hacked, of course we can too.

I think a big part of the complaint is about the implicit assumption that because people are smart, and have experience with cryptography, they necessarily have the experience to design a sane and safe programming language given their goals.

They did put themselves way out there, and that takes ambition, but also hubris. I wish they were able to figure out which one was driving them at certain points a bit better, as while some of these problems are because they are doing new and interesting things, some are old as dirt for computing, and there's little defense.

If some company tried to tout a new language with all the pitfalls of C, but none of the benefits of being really inter-operable and known the same way, I'd like to think we could recognize that as having some very bad design choices given what we've learned from C, and at little benefit other than being different. Ignoring decades of research and experience on the topic through ignorance is not laudable, even if you've put yourself out there. I can't help but feel we have a similar scenario going on here.

Actually, I think Solidity being designed to turn bad node.js coders into bad smart contract coders was key to Ethereum's success.

I've written a book on this (hit upload five minutes ago! release Monday!) which hammers on this point (and all the stuff surrounding this issue). I think Solidity is actually designed with worse is better in mind, because Ethereum is the first smart contract platform that anyone actually used. Some tried doing them in Bitcoin, but Ethereum's the first that gets lots of action. And so many other blockchains lift the smart contract functionality straight from Ethereum.

That may be, but if so, it might be worse. What's worse, not getting a lot of uptake for this idea that's been hard going for others, or getting the uptake because of trade-offs you made that make it a ticking time-bomb that may damage the reputation of the idea for years to come and set it back?

Solidity is like PHP in the 90's, easy to learn and easy to screw up. Though Solidity just compiles to the EVM, and there is no reason new, safer languages can't be built on top.

As far as I can remember, the EVM has never failed, just programmers.

That comparison may be apt. PHP at that time was a mix of some good ideas (ease of deployment) with some horrible ones (register globals on by default is unexcusable), and some poor planning. We all lived with the fallout of that for a very long time.

The register globals issue could have been avoided at very little cost, if any cost at all, to the popularity and spread of the language and many millions of dollars and much personal information would have been saved.

I disagree, Solidity is really not easy to learn. It is easy to screw up, though.

You've wet my appetite. Got a link to your book?

Pedantry: you mean whet, not wet. To "whet" means to excite, stimulate.

Literally, to sharpen, as in "whetstone".

This should save anyone else a few clicks: https://www.amazon.com/dp/B073CPP581

Check out his profile.

Thanks. Glad I checked the profile.


I don't think your personal attacks lie within the standards set by this community. There are many ways of disagreeing, even vigorously, without being a jackass. It's discrediting to yourself.

You appear to have misconstrued my words. I don't in any way think this is a good idea; just one that has the viral characteristics of "worse is better".

I spent about three thousand words on the smart contracts chapter, attempting to conclusively stab this bad idea in the face and supply a suitable rhetorical ammo dump for anyone faced with having to deal with these things to kill the idea stone dead. Absolutely everything about smart contracts is terrible and misconceived. I don't believe there is any way to do them right, because the idea is fundamentally wrong.

Here's (an older draft, need to update) what I actually say about Solidity and Ethereum smart contracts: https://davidgerard.co.uk/blockchain/ethereum-smart-contract...

Are you asserting Szabo's original smart contracts idea "is terrible and misconceived", or Ethereum's implementation "is terrible and misconceived". The latter, I would have to agree; hard forking as a response to these kinds of security holes is neither sustainable nor scalable, and I'm very partial to mechanical proof-based designs and implementations as a result.

Szabo's idea was a hypothetical for two decades. Ethereum is the first smart contracts platform people actually write for. There were attempts to do it previously, but Ethereum is the one that actually took off.

So if you're talking about Ethereum as a bad implementation of a good idea, you're weighing up reality against something that was a hypothetical from 1994 to 2014.

In any case, there's plenty really obviously wrong with the idea of immutable smart contracts. Legal code is a bad match for computer code; immutability means changes in circumstances can't be allowed for; immutability means you must code with zero bugs; the oracle problem (getting real-world data in and out of your smart contract) ...

"Dr. Strangelove" is the story of a smart contract going wrong, unstoppably, immune to human intervention.

Szabo's stuff is better than the reality - he does actually understand law as well as code, and at least early on he considered there was a role for human intervention - but it's still the sort of thing that's "interesting" rather than "a good idea".

> But if banks and major retailers who have huge budgets can get hacked, of course we can too.

Here's the thing: banks and major retailers can't get hacked. At least, not in the sense you're using "hacked".

When Target's credit card systems were compromised, resulting in the CEO resigning and and about $300M in costs to the company to deal with the breach, not one customer lost a penny.

When $171M from Union Bank of India was fraudulently wired via NYC to two Cambodian banks and one Thai one, they got all the money wired back within a day.

The traditional banking system is designed to be unhackable, because the numbers on computers are not authoritative. They're a cache, and they're periodically reconciled, but humans (and other computers!) will look at the cache during reconciliation for obvious attacks like these. A bank can call up another bank, or a retailer can call up a credit card company, or whatever, and say, "Hey, these transactions were fraudulent, please reverse them," and it'll happen. Target did that. Union Bank did that. A hacker can get to some bank's MySQL database? Sure, whatever, it's not what matters. Definitely it's a greater headache than if they got to the bank's website, but at the end of the day it's exactly as fixable as hackers getting to the website.

There are a lot of bright people trying very hard and putting honest work into a problem that simply doesn't need to be solved and shouldn't be solved: making the computers authoritative. When you do that, you're suddenly hackable. When you do that, of course $16M gets actually stolen irrevocably from time to time, no matter how bright you are or how honest your work is.

I'm inclined to agree but I must say this traditional system is unscalable. Sure it can detect millions of dollars of fraudulent transactions, but what if it's a single person who's the victim of identity theft and lost just a few thousand dollars? A few thousand dollars is nothing in the grand scheme of things but they are a lot to a single individual.

I've had calls from my bank's fraud detection department about single transactions of less than fifty pounds that they were concerned weren't from me, so clearly the traditional system is plenty scalable enough.

Doesn't this happen every day, over trivially small sums? You've never heard of a credit card chargeback?

Right, and also, a good part of why credit cards have 2-3% overhead is essentially insurance against chargebacks. I'd rather pay $51 for groceries every week than $50 for groceries plus a risk of irrevocably losing tens of thousands of dollars at some point with no warning.

If cryptocurrencies think that they can provide this service for substantially cheaper than 2-3% (note that this is an additional service on top of simply making the transfer happen, so mining fees aren't the right thing to compare), that sounds awesome, but also I'd like to understand why it's possible.

Even that 2-3% is way high, in some places like Europe and Australia, interchange fees are capped at values around 0.3% and that doesn't seem to be a hindrance in getting business done.

But Bitcoin and Ethereum can do this too. In fact Ethereum already has done it (and is arguably designed to do it). Ethereum simply has to convince a majority of the participants to fix the bug and reset to a good hash (whereas bitcoin would need a majority of the mining power unless they went out of band and used old school politics/force/coercion).

They did this already? I'm guessing it happened in the dao accident?

If so, this seems terrifying, what if I had accepted stolen ETH to sell physical goods?

The stolen DAO funds were sitting in a time-locked account and couldn't be spent for several weeks.

It seems to match the real world in some ways; If I barter and end up accepting stolen physical goods, things can go rather badly for me.

yes, but in many (most?) legal systems you cannot change the rules so you are liable for past events.

I.e. if you accept counterfeit money, it's on you, but your money should not become counterfeit overnight.

From this and your previous comments, I am trying to figure out your basic point. Would you summarize it as, "I have a low tolerance for financial risk and others should think as I do"?

I don't think that's a good way to summarize my point - I have expressed no opinion about financial risk, either my own or others. (Did you mean to address someone else?)

However, whatever financial risk you would like to tolerate, you should make sure you're pursuing goals that do in fact match that financial risk, and that you're not concluding that something more or less risky than it is because you are uninformed. Also, if you are tolerating increased risk, you should do so because there is a purpose for it (e.g, better potential upside), not because high financial risk seems inherently cool. It isn't, and I will certainly defend that point, but it's just a lemma on the way to my actual point.

Arguing that it's okay that cryptocurrencies are hackable because the traditional financial system is hackable is simply factually incorrect: it's a misunderstanding of why the existing financial system looks the way it does, and why its risk tolerances are built the way it is (not a lot done to secure transactions, but a lot done to be able to reverse transactions if needed).

If you really want a simple point out of me, I think G. K. Chesterton made it in 1929:

> In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."

If you do not understand the existing financial system, you cannot honestly claim that your new one is better. First figure out how it works and why, and get that right, then you can describe how your changes are improvements.

One of the more important skills in this craft is the combination of intuition and knowledge to know when you don't know something well enough to achieve the goal. The difference between "ambition" and "hubris" is small but critical.

That's a valid point. But its hard to be humble when you work on something that was designed to topple national banks.

Then you shouldn't be working on it. If you can't be humble, you should not be working on things that can hurt people because you're creating risk for them that they can't actually measure. (It's why I consciously avoid such projects; knowing one's propensity to arrogance makes it unethical not to.)

If it's important, you need to be good. If it's very important, you need to be good and sure.

I don't disagree, it's just easier said than done.

The thing is, cryprocurrency people usually think of themselves as smarter and better programmers than the rest of us. They even co-opted the term "crypto" to mean their toy currencies instead of actual real life, useful cryptography.

But yeah I admit, cryprocurrencies are good toy projects on which to learn real crypto, that's true. But then it's time to move on. And not to pour millions of dollars into that

These mistakes are predictable and inexcusable.

The Ethereum developers sold a vision of smart contracts, where the code is the contract. However, their hubris lead to them attempting to implement a complex language, instead of starting the endeavor with a small, simple, verifiable language. Similarly, their belief in their own infallibility lead them to write code that is not tested, and to create capabilities that are literally untestable.

This was bound to result in multiple massive failures. The dao was one. This is another. There will be more, because it's an overly complex implementation.

It doesn't matter, though. Only dumb-fuck crypto futurist suckers have ether exposure, so it won't matter that they get zero'd out once a competent team enters the space. That said, the space attracts incompetence like lights attract moths, so it'll take a while to find a team that is technically competent and also has the marketing chops to get traction.

There's essentially no legitimate use case for crypto-currency. Cypherpunks have been at it for decades and all they have to show for it is drugs, ponzis, assassination markets, and conspiracy theories.

It would be nice to see some sort of casual hawala-type federated micropayments system based on real national currency, with instant settlement, low fees, and no fake money value store. But, that would be a pre-9/11 idea. Nowadays that's basically illegal and useless.

Paypal is more or less good enough, and hopefully regulators and market forces will control the fees and abuses.

Sorry, but have you looked on the democracy and justice-culture index maps worldwide? The democratic, end-of-history, justice-seperatly-delivered state is currently in full retreat. I agree, the futurists got it the wrong way around, assuming something cyper-punk-currency enough would blow the state away and allow for crypto-anarchy to rule. Instead, we got states that on slight economic decline implode on themselves (a whole thinker caste in denial about human nature hunting scape goats) and suddenly the crypto-currency nonsense doesent look idiotic, because it can work on, even as the state becomes hostile.

Thats the vision- a somalia like decline, but society moves on, with schools back uped to youtube, with contracts backed up to the block chain, with the currency back uped to bitcoin. I find the ideals of crypto-anarchy laughable (those guys would be gunned down on the first corner, in a real anarchic world), and yet, i can agree to the path we taken. Cellphones and facebook, to have a culture of shame, that fights wild mobs and public hysteria, because the internet does not forget your lowest point. Anyone in power in fear of getting caught in public, for the world to see as just another corrupt, well fed monkey?

Yes, that is something to work towards.

When my work introduced me to the guy that explains to us how the retirement fund works, I asked him if the Euro is safe (this was 2011-12), and what the safest investment is. He said "the safest investment is to buy a farm and grow your own food, because you can't eat money or gold.".

And in this Somalia 2.0 future of yours, how will the computers and networks be powered?

you don't think 200m ico's counts as marketing traction?

This space doesn't atract incompetence, it atracts everyone. When you have tech thats so transparent and accessible, degrees and diplomas don't get to decide who can or cannot work on it. Plus, the world most experience blockchain developer has at most, 9 years of experience. That's not a lot of time to work out the kinks.

Predictable, but not necessarily inexcusable. What is gained and learned in attempting more complex smart contracts sooner rather than later when all the building blocks for absolutely secure smart contracts are built can certainly justify the approach.

I like your point about language complexity. Can you point to a language that would fit the simple and verified criteria? I don't really follow the subject, so it would be interesting reading.

You could take inspiration from a system like Dafny or F-* and write your contracts with the assistance of a type system and compiler that generated proofs that your contracts satisfied some postcondition given a precondition. People have already written moderately complicated applications like operating systems in these languages, so there's some evidence they could be applied to contracts on the blockchain.

There is some research using dependent types in the Idris language to build safe smart contracts. The earlier discussion (quite limited sadly):


idris is not exactly simple, is it?

My favorite smack-talk so far is "Dunning-Krugerrands".

That is certified brilliant.

That pun is golden.

would've missed it, thx

If you have such a bright mind, you often need a dark hat, to avoid blinding the others.

Poking around in that project, I don't see any specific tests of the Wallet contract... would be interested to see what UTs/STs were included if anyone knows where they are -- or was it just manually tested on the testnet? It seems that a basic set of UTs for this contract should have caught this issue.

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.

As I said here last week "Also the lead developer is some kid who believes very much in moving fast and breaking things. This philosophy may work for a social network site but not for other people's money."

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.

People write this stuff off so fast. Here we have a parity developer, probably one of the most competent in the Ethereum ecosystem, and he screwed up to the tune of losing $30m of other people's money.

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.

He may be brilliant, but he played fast and loose without real testing or concern, so I wouldn't call him the "most competent". For a wallet contract they knew would secure many millions of dollars, there should have been dozens of people auditing it before rolling out to users.

You're "no true Scotsman"ing so hard Mary, Queen of Scots doesn't even qualify.

I wish I could see how the op is employing the no true Scotsman fallacy, but I can't.


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

Charlie is trolling. The architect isn't going to be the best craftsman, that requires very different set of skills.

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.

Gavin Wood didn't not make the code change that caused this...

I can't edit my post above to add this now, but looks like Charlie retracted this as Gavin was the original author, but not the one who made the mistake.

Dear god, I've been thinking crypto is a bubble since 2010. At some point, we have to admit this is not just a bubble. It's a new unproven evolving technology

Crypto has had at least 3 distinct bubbles. There's the current one, marked by Eth's absurd rise to $300. The previous one was when Bitcoin made an absurd rise to $1200 in 2014. There was a bubble before that where Bitcoin rose to $266 in 2011. And one before that I believe where Bitcoin rose to $32 in 2010.

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.

It's only a bubble if you can identify it ahead of time. Stating that something became much more valuable over a short period of time doesn't mean you know how to identify bubbles. Bitcoin is 70-80 times more valuable now than when it was at 32, and had you bought it then you would be up a lot. So, to say crypto is in a bubble today is the same thing as to predict that in a few years it will be worth less than today. Do you know that definitively ? I don't

Downvoters, since you know how to indentify bubbles, I'm assuming you shorted ethereum on margin on GDAX when it hit 400 and made a ton? No? If not, why not, if you knew definitely it was a bubble ?

Because it's very hard to figure out where the top of a bubble is, and if you short a bubble asset too long before the peak, you go broke, even if you are correct.

Don't short hopium.

Well, now we are talking semantics. You don't get to claim you are correct if your forecast turns out to be wrong. So, if you identify a bubble, part of the requirement to say that you succeeded is that you can identify the top. Otherwise, your "knowledge" that it's a bubble is useless

I think people agree that a price rise was a bubble after it pops, and I don't believe that prediction is a necessary condition.

It is, otherwise how do you distinguish a bubble from a rise justified by fundamentals ?

I actually think eth has a lot of potential, but I don't think he's saying crypto is a bubble. He's probably talking about the ICO "bubble", which isn't a controversial thing to claim. Eth has already halved in value in the last month which is mostly put down to the crazy value being pumped into ICO's slowing down.

I would argue ICO phenomenon is not a bubble Rather, some ICOs are scams But many are legitimate business ventures. Buying into an ICO is similar to buying deep out of the money options

Someone's loss is anothers gain. That money didn't disappear, just got reallocated. And if spent ,will generate economic activity. It's certainly a hit in the trust of the core dev though.

This gets awfully close to the broken window fallacy https://en.wikipedia.org/wiki/Parable_of_the_broken_window

I agree, if they did not address the concerns it would become unworkable.

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

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.

Do you have examples of this, or just hearsay?

the story you are commenting on is a good example

it should not be this easy to lose sixteen million dollars

Yes. If a similar scale thing were to happen in the U.S. banking system, 1% would be 160 billion dollars, not 16.

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



I feel like we shouldn't be expressed in dollars, but in percentage of total funds. In this case 16 million is about 1% of the total. This would be a $16 billion case if the US banking system was the target and used this technology.

That... doesn't make a difference in my mind. Losing 1% of people's money is _very_ unacceptable and worth being laughed at for.

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

Especially when the odds are that it will happen again soon.

You should ask yourself what the Bitcoin developers are doing while Ether takes their market share. The answer is the exact same thing, at https://elementsproject.org

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.

You sound very biased on this.

I am very biased because I know the people at Blockstream have been thinking about this problem longer than the developers of Ethereum.

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


Beyond the one we're already discussing?

I've been writing some smart contracts over the last couple weeks and have learned a lot from OpenZeppelin's solidity repo–you can either use them directly (importing and extending off of them) or use them as a good resource for building tokens, crowdsales, etc–can't recommend them enough.


Agreed, it's definitely the way to go. Hope the project will continue to evolve. Both Aragon [0] and Storj [1] are making active use of them, if you look for example usage.

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

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

The 20 cases for underflow and overflow [0] show how difficult it is to develop error-free contracts. Would have been great if the VM would detect such cases and thus make the contract code less polluted with boundary and overflow checks.

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

I can literally feel how Ethereum changes the law. I mean, seriously, no need for lawyers anymore. On ethereum it's is simple: You got fucked, live with it. "Bad faith? It's the code, didn't you read it?"

I realize that was probably satire or sarcasm or both, but since I've seen people actually seriously take that position I'm going to go ahead and respond as if it was serious.

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.

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

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.

>So yes you need human intervention, but only for those parts that cannot be automated.

This is tautological and therefore means nothing.

The subtext here is that some parts can be automated, and a smart contract lets you automate those parts.

Didn't you just describe an example where the ambiguity of human language is a problem and a smart contract may actually have a better chance of performing as expected?

Why do you asssume smart contracts can't be ambiguous? A lot of people read the DAO contract, and yet it took a hacker a while to find a small error -- if I recall correctly it was a capitalization error -- that triggered an unexpected exit path.

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.

I think the main problem is that it's very hard to preemptively defend against all abuses of a law or contract. It's the whole "letter vs. spirit of the law" divide: https://en.wikipedia.org/wiki/Letter_and_spirit_of_the_law

If tomorrow I sign a contract with my mobile phone carrier and it turns out that through some loophole in the contract they get entitled to the kidneys of my first born daughter then clearly I have a case to go to a tribunal and get it overturned as it's obviously not a reasonable clause.

I think people arguing that "code is law" (which is simply a modern form of "letter-ism") don't really know what they wish for. I guess is many are going to change their minds when those attacks get more and more common and they lose a ton of money because of an unforeseen and obviously unintended flaw in the contract code.

I feel like anything humans can use to communicate to each other could be considered a human language.

More relevantly, creating a synthetic language that's a subset of natural languages will mean that multiple natural concepts will map onto the same synthetic one.

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

I've not worked with smart contracts personally, so take it with a grain of salt, but...

This problem seems to be mostly solved by the information available in shipping manifests; the locations of loading and unloading, the consignee (buyer), container ids, description of goods... all there in a publicly available (at cost) record.

The real difficulty has more to do with verifying the quality - I'll admit I'm at a loss to how that's done today and I can't imagine quality assessors are at the port to verify that container #123 contains the shipment of Grade B+ cotton or map that to an API. As well, what happens when you disagree and your own independent assessor says its Grade B-? This seems like something that would remain up to legal debate; probably denoted in the contract but not verified by it such that lawyers and assessors can handle it should problems arise.

Just my two cents.

This comment? This is why I keep coming back to hn. A special interest in cotton.

Have you ever been to some old manor or library with hundreds of weathered ancient leather bound books...I always wonder about their contents... (usually they are under lock and key)...Cotton case law now seems a perfectly reasonable assumption.

Contents may have been unimportant. Apparently books could be ordered by the yard for decorating manor libraries.

> neither deserving the name Peerless

Sir that is a prejudicial statement and I want it stricken from the record.

"It's all there black and white, clear as crystal. [...] You get nothing. You lose. Good day, sir."

You skipped the juiciest part of one of my favorite scenes of that movie. [scared the bejeezus out of me when I was little, I didn't realise for some time it was pure satire and no adult would be expected to understand him].

So I feel obligated to post the full bit (from wikiquote)

>Wonka: [angrily] Wrong, sir! Wrong! Under section 37B of the contract signed by him, it states quite clearly that all offers shall become null and void if - and you can read it for yourself in this photostatic copy - "I, the undersigned, shall forfeit all rights, privileges, and licenses herein and herein contained," et cetera, et cetera... "Fax mentis, incendium gloria cultum," et cetera, et cetera... Memo bis punitor delicatum! It's all there! Black and white, clear as crystal! You stole Fizzy-Lifting Drinks! You bumped into the ceiling, which now has to be washed and sterilized, so you get... NOTHING!!! You lose! GOOD DAY, SIR! [returns to work]

>[scared the bejeezus out of me when I was little, I didn't realise for some time it was pure satire and no adult would be expected to understand him].

Yeah, as a kid, I too thought Wonka was serious. It took viewing it as a much older person to see the satire there.

I thought the most ironic part of applying it to this situation is that, just like in the story, the rules were then changed to suit the whim of the enforcer. Meaning, of course, that the rules never meant anything anyway, except to the disadvantage of one party.

Furthermore, I suggest you do what your parents did, and get a job, sir! The bums lost, Lebowski!

Won't happen. People need to believe that the justice system will hear their pleas and consider factors on-balance, and then proceed in fairness. In real law, there are several potential overrides available to stop egregiously unfair outcomes that would otherwise be legally valid (estoppel, unconscionability, etc.). People will not accept a system that does not have the appearance of fairness (regardless of its actual fairness).

One of the things that cyberpunks fail to grasp is that people don't want a perfectly immutable, fixed system. They want to feel that their sense of justice and moral righteousness can be satisfied. Stuff that drops people off right at "sucks to be you" doesn't really work; there must be some type of recourse available even if it doesn't have a 100% success rate.

Agreed! It really won't happen, and isn't happening, even in Ethereum: when people find the result distasteful enough, they go via political means to rewrite the ownership so it feels right.

Specifically, in the DAO hack, the affected people had enough political influence to get the entire network to undo the ownership transfer that was the result of their own oversights:


If anything, Ethereum is worse because you have to get the entire network to fork (analogous to a revolution or constitutional convention) to fix a mistake, instead of just getting a judge to rule "okay, that's obviously not what anyone meant".

Furthermore, it's far more unequal, where mistakes only get fixed when they affect the most influential users. Seems like a step in the wrong direction.

Not sure why you're being downvoted because you're exactly right. The crypto-anarchists love to say "the code is the law", but the reality is that losing your retirement savings because somebody forgot to mark a method private is a pretty shitty outcome.

For all its warts, a legal system backed by a jury of your peers is still the best way of sorting out the actual intent of a contract when the shit hits the fan.

Ignoring the fact that he was responding to a post that was sarcasm, if we really stop to think about it, how many people are judged by their peers and how many are judged by people who are the furthest from it?

This is a very US-centric perspective: in most common law countries, jury trials have been all but abolished for contractual interpretation cases.

Well then ethereum is not for THOSE people.

It is fine if you don't like those features. But it turns out that a lot of people DO want them.

The people who want to court system can already use the court system. Now we just have more options and choices.

Why do you think that the court system somehow doesn't apply to what happens on ethereum ?

The courts can certainly make an attempt to apply themselves to what happens on ethereum.

But if someone wants to, they can make it extremely for that to happen.

Good luck finding the anonymous contract creator that set up their contract by sending money through Monero.

Also, empirically, your claim that courts will get involved with ethereum smart contracts just isn't true.

It is not true, because gigantic scandals and contract theft have ALREADY happened on ethereum, and the courts haven't been able to do shit.

He's being downvoted because he's replying to obvious sarcasm as if it was serious. You also appear to have taken the joke seriously.

Sarcastic or not, "contract by code" and "lawyers are obsolete" are, in reality, major selling points used by Ethereum evangelists. The OP's post gives an opportunity to discuss this.

I did not assign any assertion or position to the OP, only followed up on his thread about the potential ramifications that ETH backers seriously advocate.

Poe's law: Sufficiently advanced satire is indistinguishable from fanatical confusion.

And many people do promote the "code is law, and nothing else" idea -- at least Ethereum Classic stuck to it!

Except the "code is law" meme is a view that many crypto anarchists actually espouse.

Perhaps they were simply elaborating on the sarcasm on account of the fact that sarcasm does a shit job of justifying or explaining anything.

You're right on the facts, although I don't quite get why you ridicule this idea as a "sense of justice and moral righteousness" with only the "appearance of fairness".

A system of laws devoid of all ambiguity and emotion isn't even possible, let alone desirable, because at some point these contracts have to come into contact reality, and the humans in it. And these humans happen to be, well: human.

I guess there's an ideology at play that would love to change humans to fit within their neatly arranged algorithms. And if that means some grandmother loses her house because she signed the wrong smart contract when buying cat-food, there'd be a lot expressions of sympathy on Twitter, but she really needs to understand that it's just not possible to do anything about, because principles etc etc.

Here and there, some of these people may, very privately, consider it a feature of the system that others less intelligent than them sometimes happen to die on the streets because of that one Saturday morning where they didn't audit all 500k lines of brainfuck in that contract for chinese takeout.

With less snark: the idea of ambiguity or emotions as being something negative is a somewhat naive view of reality, somewhere on the spectrum between Star Trek's ideal of Spock and the social darwinism of Ayn Rand. It's most often seen in the currently popular misunderstanding of how judges should behave, and how journalism supposedly used to work.

For an example that maybe is a bit less inflammatory than anything about journalism, check any recent threat about the Google vs Uber lawsuit: the presiding judge is almost a legend for his diligence in learning the technology in the Oracle vs. Google lawsuit a few years back. Yet people criticise him for a lack of decorum whenever he uses language that doesn't pretend to be a robot following an algorithm: "This judge is clearly biased! The contract clearly only says $50,000, and there's no law that gives him the authority to say those are USD. When the defendant says it means Canadian Dollars, it's he-said-she-said and undecidable"

I don't ridicule the need to have senses of justice and moral righteousness fulfilled. I think they should be accommodated by legal systems. My point is that systems must at least pretend to do so if they want public credibility.

Ethereum, as well as things like IPFS that say "Your content is permanent and irrevocable, don't publish if you don't like that", are non-starters because they overlook this core desire to operate under forgiving systems.

Many unfair or distorted legal regimes exist (including, to some degree, the American one), but they all make overtures toward these principles in some form or another. Ethereum et al must correct this if they want widespread adoption.

> One of the things that cyberpunks fail to grasp is that people don't want a perfectly immutable, fixed system.

Some people do.

Source: I am a person who wants this.

And the inverse also applies. People (groups and individuals) want to be able to throw their power around and leave people they don't like at "sucks to be you". This behavior has been the status quo for millennia.

Eh, dictatorships and oppressive systems still work hard to appear fair and even-handed. That's why they have such elaborate propaganda machines.

Anyone who wants to maintain power in virtually any setting (communal, corporate, governmental) must create an impression of fairness and equity, at least to the extent that a good portion of the people are not willing to risk their [reputations/jobs/lives] to throw off the "oppressors".

It's not an accident that virtually all powerful corporate bosses and politicians are so image-conscious and superficial; it's a matter of survival for powerful people.

Matt Levine has some thoughts [1] on that matter.

[1] https://www.bloomberg.com/view/articles/2016-06-17/blockchai...

That's a good article, and the point about him reading a lot of DFW is hilarious and accurate.

But I think of this issue in slightly different terms that are more simple.

There's a ton of case law about what constitutes a contract that pretty much all countries have. Clearly understanding the contract you are getting into is a prerequisite for the contract being enforceable in most places.

The simple fact is that this is never going to hold up in court when people start suing.

No one gets into a contract with the understanding that they can be robbed, and that's just okay. No rational person would do that. And I think it's a fair case to say that no rational person did clearly understand the contract as presented and agree to it.

The courts are going to to shut this down, in my opinion.

You can't just write into a contract that you might get stolen from or murdered or whatever bad thing and then that bad thing is suddenly okay.

"Okay, this guy didn't read the fine print on that used car loan. Let's go rape his wife and kids now. He said it was okay!"

That's not how it works. Etherium deserves to get hammered for this.

That dude's read a lot of DFW.

There's a little bit more information here [1].

[1] https://www.reddit.com/r/badeconomics/comments/6cnzs8/matt_l...

Excuse my ignorance, but what is DFW?

Not positive, but guessing David Foster Wallace

What makes you say that?

Great article!

Except for that DAO of last summer, in that case the law changed...

Ethereum's original sin

The DAO hit every objection from smart contract skeptics, bang bang bang - legal code doesn't work at all like computer code, immutability means you can't fix mistakes, immutability means you can't deal with changes in circumstance, immutability means you must code with 0 bugs - but even we were surprised when they went "lol immutability guarantee" the second the big boys were in danger of losing money.

It's almost as if software technology can't magically solve problems inherent in the flawed nature of humanity.

That's a strawman of what GP said. Of course technology can't solve humanity's flaws. The point was that smart contracts caused many problems they weren't meant to, which was exemplified by the DAO hack. Smart contracts failed to deliver on their promise and the fallout proved that when it came down to brass tax, nobody with skin in the game would respect a smart contract's execution anyway.

FYI the term is "brass tacks" not "brass tax"

Hold on to your hats boys, we might be getting another hard fork!

Unless you're the lead developers and lost money. Then we'll just hard fork the entire protocol.

In that future, ironically, Gold acquires even more value as a hedge

Not just the code but hopefully the compiler and processors (at large i.e. Intel) have no bugs that causes unintuitive behaviour.

Good thing that isn't the case! WHOOPS that already happened in Solidity didn't it https://medium.com/@muneeb/solar-storm-a-serious-security-ex...

it creates such a bad alternative to the current system it's certain not to come about.

Yeah! Well, uh... except that one time.... mumblemumble

Well, you know, except for the whole "we, the central governors, will hard-fork if we get scared that there's an existential threat to the blockchain" thing.

Odds etherium does another hard fork to fix this bug?

The DAO held nearly 14% of all ethereum in existence, 153,000ETH is less than .2%.

153,000 / 93,405,120[0] = 0.001638025838

[0] https://etherscan.io/stat/supply

And there's more Ethereum now. The DAO was a ~$50 million fraud. This was a ~$30 million fraud. Obviously this is totally different and there's nothing we can do about it and it's just fine. People should have known better than to use parity with this bug in it.

Reminds me of the Winston Churchill story:

“Churchill: "Madam, would you sleep with me for five million pounds?" Socialite: "My goodness, Mr. Churchill... Well, I suppose... we would have to discuss terms, of course... "

Churchill: "Would you sleep with me for five pounds?"

Socialite: "Mr. Churchill, what kind of woman do you think I am?!"

Churchill: "Madam, we've already established that. Now we are haggling about the price.”

We've already established that they will fork. Now we are haggling about the price.

[1] http://www.goodreads.com/quotes/300099-churchill-madam-would...

Considering how powerful, famous and charismatic he was, I think, makes one consider that maybe it was Churchill who was being insulted, not the socialite.

"Would you sleep with me?" "Maybe for a million dollars..."

> People should have known better than to use parity with this bug in it.

Says it all, I think, whether sarcastic or not.

> Unmarked functions default to public in Solidity


Wasn't this lesson learned long ago? C# defaults to private on unmarked members. Why would you ever want to default public?

It was designed to be like Javascript. Of all languages...

Wouldn't it make more sense to design it like Haskell? or something even more strict? A little bit of extra work seems like a small price to pay to prevent millions being stolen from your wallet because of a silly mistake like this...

In Haskell everything is public by default unless you specify exports for the module.

But it also has a statically checked type system.

I think if done in Haskell how good or bad it is depends on the chosen abstraction for effects not Haskell itself.

Haskell is a good basis but the developers need to make the API fool proof. E.g. expose limited effects rather than a big fat "IO" type.

Good catch! It is indeed that the constructor could be called by anyone. Here's a couple txns showing it:

Calling initwallet: https://etherscan.io/tx/0xff261a49c61861884d0509dac46ed67577...

Executing: https://etherscan.io/tx/0x0e0d16475d2ac6a4802437a35a21776e5c...

> Unmarked functions default to public in Solidity

What kind of brain-dead apes designed this language? This would be a stupid decision in any language, never mind one specifically intended for high-value transactions.

My favorite critique of Solidity is this guy on hacker news from a few days back https://news.ycombinator.com/item?id=14691212

This is why I keep saying that "smart contracts" should be expressed in some declarative notation like decision tables. Byte-coded programs as contracts were a really bad idea. Contracts need to be readable, not just executable.

I'm kind of curious on what you think about Tezos and its Michelson language (https://www.tezos.com/static/papers/language.pdf) which offers provability of contracts.

Just looking at this language, it makes me feel like we are going back in time in regards to readability and ease of use. I understand that security and provability of contracts is more important in these cases, but one can dream!

Michelson is a VM bytecode, not a programming language, although it happens to be readable enough to write simple contracts in it directly.

IIRC, the old Camllight VM was pretty similar (I might misremember, that was literally decades ago); an ML-like language to Michelson compiler is fairly straightforward to write and to prove sound.

I'm happy that they do things the sane way, i.e. focusing on sound foundations rather than on how Javascripty the syntax looks; but I'm afraid the communication isn't as clear as it could/should be. Blessing a compiler for some subset of ML, as a first high level language, would have cleared things up IMO.

I find it perfectly readable. Precise and intentful. Perhaps you're just not accustomed to formal writing?

Byteball (https://byteball.org/ has declarative smart contracts!

That looks interesting. I just skimmed the white paper. It's not clear what their contracts can do, though. They need more examples.

The underlying DAG idea has potential. You could have two half-transactions happening on separate subtrees, where A is buying X from B and B is paying Y to A. So A broadcasts "A will buy X from B when B pays Y to A", and B broadcasts "B will pay Y to A when A buys X from B". When the matching half-transactions acquire a common child, the transaction commits. It's a true "meeting of the minds".

Yes they do have that what you are describing, "smart conditional payments".

You can for example trade user-defined (possible private) assets (tokens) in that way - "Ill send you my bytes for your blackbytes, I send bytes to this address and me can sweep them back after 4 hours, or you can sweep them if payment of X amount of blackbytes is made to my address". It has oracles as well.

Time to revive Prolog, perhaps?

Yes! Prolog is a great language for such use cases in my opinion.

The problem is that decision tables usually end up really big for anything but the most trivial smart contracts.

Design... before Solidarity I had never seen such an abuse of the word.

I think the capitalization of a method making the difference between two very different outcomes might be my favorite example. It's that kind of stuff that makes me happy I have to go through api reviews at work - although seriously how does anyone sign off on these designs?

> sign off on these designs

I only wish people had to do that. Shit like this are why professional and civil engineers roll their eyes at the mention of software "engineering". There are best practices and available tools but people employ them far less often than they probably should. In the space, take a look at Kadena's Pact smart contract language. It's not perfect by any means (lisp-religious syntax and its tight integration with Kadena internal constructions, for example) but it is at the least, working on formal verification support.

This is the design of most high-level scripting languages (e.g. Javascript, PHP, Python, Ruby)...

These aren't called "Solidity" and more importantly weren't built specifically to write a financial infrastructure of multiple hundreds of million dollars (though some of these languages are definitely used to manage money now)

I was responding to this statement from the parent...

> This would be a stupid decision in any language

Python is a bit different still: it doesn't have visibility specifiers to begin with, everything is public.

Javascript is the same, AFAIK.

Seems like something a code review would have caught. Then again, code reviews and other slow processes are probably not the par for startups.

About half my day job is auditing Solidity code for startups. And yes this should have been caught.

Auditing Solidity? Sounds sexy and infernal at the same time. Congratudolences I guess?

Can you share where you work? I'm looking for someone to audit some Solidity code.

Or just dumb fuzzing. Or a testnet. Or whatever the fancy word for static verification is nowadays.

code reviews are prone to human errors, even if you have the best engineers.

Precisely. Code reviews and software quality assurance aren't just corporate redtape, they can save your rear.

Especially for this; it should be enterprise, bank-tier code, covered by as much red tape as possible.

The problem with cryptocurrency is that they try to be better than the system, but have to relearn all the lessons the hard way. It probably won't take too long before all of it becomes exactly like what banks are now - heavily regulated, etc.

Meanwhile, the people who fleeced the old system know all the tricks and they get a chance at doing it again before the regulations kick in.

Hmmm... That's similar to, but not covered by this submitted fix https://github.com/paritytech/parity/commit/e06a1e8dd9cfd8bf...

That is correct! Here's their proposed fix https://github.com/paritytech/parity/commit/e06a1e8dd9cfd8bf...

Why doesn't the only_uninitialized modifier cause a throw since m_numOwners should have already been > 0, no?

It got patched after he posted this. Before that there was no only_uninitialized.

That's correct. Here is a more detailed explanation: https://blog.zeppelin.solutions/on-the-parity-wallet-multisi...

"Solidity" is a pretty sarcastic name for the language at this point :)

Did you mean "ironic"?

Perhaps both :)

For an uttering to be sarcastic it needs to have been intended to be so.

But also, a quick fix to this is to add a modifier that throws if m_owners[1] is already initialized

This seems like a compiler bug, not a systemic issue with Ethereum. No?

It's a bug in a smart contract, but the root cause is the bug-prone design of Solidity. It's hard to write bug-free code in Solidity (or anything targetting EVM actually), and nearly impossible to be confident that a given contract is bug-free.

parity.io, the company author of the bug, is a top-notch Ethereum actor. If they can neither get a wallet contract right, nor realise that it's faulty, then who can write and trust any non-trivial Ethereum contract?

How many DAO or Parity trainwrecks before people admit that Ethereum isn't a dependable platform?

Does this mean ETC is compromised too?

This is not a problem in ETH [1]. It's a bug in one of the contracts written by Parity. Anyone that has (had) money in these specific contracts is in trouble. If you are not using these specific contracts, you are safe (for now).

ETH and ETC have the same underlying technology and language to write the contracts. So if someone writes a contract it can be used in both variants. The contract may check that it is in ETH or ETC (probably looking for the contract that was added during the fork) but I think very few contracts check this, so almost all contracts are usable in both chains.

So if it was possible to use the Parity contract in ETH, then it's very probable that it was also possible to use it in ETC.

To answer your question: Probably the same bug that was used to steal ETH can be exploited to steal ETC, if someone is using these contracts in the ETC chain. But it's not a problem in ETH or ETC [1].

[1] As other commenters noted, it's a very bad design flaw to make all function public by default. It's not an error, but it makes much easier to write buggy code.

The vulnerability being discussed is for a particular multi-sig wallet, not the Ethereum blockchain itself.

Not directly, but Parity multi-signagure wallets on Ethereum Classic, Expanse, Musicoin, and other public chains are affected as well.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact