Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

153k Ether Stolen in Parity Multi-Sig Attack

etherscan.io

Post reply on HN
Print view View original

711–720 of 754 posts

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

#711

Post by kalleboo »

geofft wrote: post #637
kalleboo wrote: post #482

Earlier quoted context omitted.

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…

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.

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

#712

Post by vog »

kaputsmack wrote: post #612
vog wrote: 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?

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.

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

#713

Post by beaconstudios »

jes5199 wrote: post #618
avaer wrote: post #461

Earlier quoted context omitted.

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…

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

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.

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

#714

Post by albertgoeswoof »

philh wrote: post #696
albertgoeswoof wrote: post #684

Earlier quoted context omitted.

How do you consent to theft?

By giving something to someone. I mean, legally, what happens is not "consenting to theft". Unlike say assault, which you can consent to, and legally speaking an assault actually happens but consent makes it okay; but with theft, if you consent what happens is not legally theft. (IANAL, but this is my recollection from law A-levels.) But that distinction is irrelevant here. The point is that there's basically no way…

and in this case the owner didn't consent, regardless of the contract's contents

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

#715

Post by tom_mellior »

seagreen wrote: post #663
RexetBlell wrote: post #647

Earlier quoted context omitted.

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

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

#716

Post by davidgerard »

splintercell wrote: post #687
davidgerard wrote: post #303

Earlier quoted context omitted.

:-D Ask me anything ;-) I have, like, a whole chapter about smart contracts which answers everything about this latest disaster. The idea is that it will be a handy rhetorical ammo dump for when someone asks you about those blockchain things and why the business needs them ...

I hope you are mentally prepared for the sheer amount of negative reviews you're going to get on Amazon.

Their money is still fiat!

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

#717

Post by philh »

albertgoeswoof wrote: post #714
philh wrote: post #696

Earlier quoted context omitted.

By giving something to someone. I mean, legally, what happens is not "consenting to theft". Unlike say assault, which you can consent to, and legally speaking an assault actually happens but consent makes it okay; but with theft, if you consent what happens is not legally theft. (IANAL, but this is my recollection from law A-levels.) But that distinction is irrelevant here. The point is that there's basically no way…

and in this case the owner didn't consent, regardless of the contract's contents

Under US law, I think that's probably true, but a) it's not what I was talking about, and b) I don't think you should be as confident as you seem to be.

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

#718

Post by int_19h »

z3t4 wrote: post #669
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…

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.

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

#719

Post by masklinn »

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…

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

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

#720

Post by masklinn »

int_19h wrote: post #417
radlad wrote: post #253

Earlier quoted context omitted.

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

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

Javascript is the same, AFAIK.
Post reply on HN