Live data from Hacker News

153k Ether Stolen in Parity Multi-Sig Attack

etherscan.io

741–750 of 754 posts

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

#741
post #538

Earlier quoted context omitted.

Parity does not appear to be an online service. It's local.

It runs on a distributed cloud VM actually (Ethereum). So the rule applies: don't trust online services with your money, especially if you didn't write the code.

Parity does not run on the EVM, it's a local node processing a local copy of the blockchain. You can create normal accounts which are just private/public keypairs you have full control of without anything "being in the cloud" or "distributed". What you are referring to might be the vulnerable multi-signature wallet itself, which - once deployed - runs on the EVM. And that only affects a fraction of Parity users.

Note, I work for Parity.

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

#742

On the parity website they state the following > Every single line in our codebase is fully reviewed by at least one expert developer (and routinely two or more) before being placed in the main repository. We strive for excellence; static code checking is used on every compile to cut out bad idioms. Style is enforced before any alteration may be made to the main repository. Continuous integration guarantees our codeb…

Confirming this always was and still is the case. (Working for Parity.) However, this does not guarantee that such mistakes happen.

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

#743
post #669

Earlier quoted context omitted.

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

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

#744
post #562

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…

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

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.

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

#745
post #562

Earlier quoted context omitted.

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

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.

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

#746
post #562

Earlier quoted context omitted.

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

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

[deleted]

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

#747

Earlier quoted context omitted.

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.

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

#748
post #458

Earlier quoted context omitted.

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…

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

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

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

#749
post #722

Earlier quoted context omitted.

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

> 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 research for over 20 years. How many Ethereum and/or Solidity devs read the E research, learned the E language and played around with it?

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

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

How many of the devs have read this paper?

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

#750
post #540

Earlier quoted context omitted.

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.

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

Post reply on HN