153k Ether Stolen in Parity Multi-Sig Attack • Hacker News Board

Re: 153k Ether Stolen in Parity Multi-Sig Attack

#751

Post by ojr » Mon, Jul 24, 2017, 4:49 PM UTC

int_19h wrote: post #692

ojr wrote: post #599

Earlier quoted context omitted.

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 wa…

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

Re: 153k Ether Stolen in Parity Multi-Sig Attack

#752

Post by naasking » Tue, Jul 25, 2017, 4:50 PM UTC

arjo1 wrote: post #521

int_19h wrote: post #448

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 fun…

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

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

Re: 153k Ether Stolen in Parity Multi-Sig Attack

#753

Post by int_19h » Tue, Jul 25, 2017, 8:37 PM UTC

z3t4 wrote: post #743

int_19h wrote: post #718

Earlier quoted context omitted.

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, a…

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 The enlightenment: for(var i=0; i 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.…

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.

Re: 153k Ether Stolen in Parity Multi-Sig Attack

#754

Post by federicobond » Fri, Jul 28, 2017, 9:09 PM UTC

naasking wrote: post #749

federicobond wrote: post #732

Earlier quoted context omitted.

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

> 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 resear…

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.