Live data from Hacker News

153k Ether Stolen in Parity Multi-Sig Attack

etherscan.io

591–600 of 754 posts

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

#591

Earlier quoted context omitted.

So you use the Bitcoin Core wallet do you? You've veered away from your original statement towards one that I don't disagree with. Of course you shouldn't just trust any software you find on the internet. That's not the same as "only trust Ethereum core". Slandering "third party" as if that has any meaning is silly. You should treat everything on its individual merits, including the Ethereum reference wallet.

My argument has remained the same. The Ethereum reference wallet is by far the most vetted wallet. Use that. (And yes, I use the Bitcoin Core wallet.) If you used Parity because it has 1,700 stars on Github and was written in Rust, you're doing it wrong . Stop. You can't assess merit based on what everyone else is doing. The only hope in a situation where you don't know what you don't know is to stick with fundamenta…

Parity is one of the core Ethereum clients, it is vetted just as much as geth is. The code that has this mistake was written by Ethereum co-founder Gavin Wood, in Ethereum's programming language called Solidity which was made by Gavin Wood as well.

I know you got burned in MtGox, but this has nothing to do with third parties or storing assets in some insecure manner. This is a fundamental issue with Ethereum and its community.

If you want to be safe, don't buy an asset that's being protected by a couple of young and naieve idealists that just care about putting their ideas on the market.

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

#592

Earlier quoted context omitted.

> but pretty clearly trying to use insurance on the platform to insure against risk that are in some sense endemic to the platform seems quite misguided Absolutely, the risk posed by a malfunctioning VM is a systemic risk that applies to the entire platform. So there is a chance that contracts impacted by a VM bug could be unreliable across the pre and post bugfix VM. The insurance contract could be one of these. How…

> The meatspace system seems very stable until you realize that it's highly brittle. It's impossible to meaningfully measure firm solvency risk, because the behavior of the "VM" is so unpredictable. Actually, it's not. Regulators and ratings companies do a pretty good job of it, and in extraordinary Great Recession type events there is usually concerted response to keep consumers from incurring any losses. Insured no…

Regulators and ratings companies did a terrible job leading up to the 2008 crash, and people did have real losses. Some pensions got hit hard, for example. The loss doesn't have to come directly out of your bank account to have a real effect on you.

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

#593
post #520
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…

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

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

#594
post #449

Earlier quoted context omitted.

The analogy is if you accidentally leave the door of your house unlocked, it doesn't make it legal fir someone to walk in and steal your piano

This comment fails to address the point of the comment it is replying to... you simply repeated the original point, but the person you responded to worked within that analogy and then modified it to try to address the statements by Ethereum.

Right, I am saying the analogy I responded to is flawed. Ethereum doesn't invite people to violate the intended use of the contract. It's like claiming that if a corporation got hacked due to lax security, then those hacking are in the clear because that corporation invited them in

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

#595
post #541

Earlier quoted context omitted.

This wasn't a third party wallet actually. It is the local Parity wallet and node. What this was, was a bug in the multisig contract that Parity would give you to deploy. So it is a contract you personally deploy onto the ethereum network and then interact with. You do own it, you own the private keys for the address, etc. But the bug allowed any other address to add themselves as owners and withdraw from it. Luckily…

Exactly, you are deploying code to the cloud that you didn't write and trusting it with your money. So many things wrong about that, it's the cryptocurrency equivalent of installing random software packages on your critical servers.

actually the best practice is not writing your own code and using thoroughly audited industry standards. Writing your own smart contracts for things that other people have already done and secured is akin to rolling out your own cryptography. Obviously, just like it's happened with openssl in the cryptography equivalency, this can also go wrong, but it's less likely.

If you write your own you should get your code audited by a specialist, or many, before deploying.

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

#596
post #108
post #63

Earlier quoted context omitted.

IANAL but if someone leaves their front door open, it's still illegal to walk in and take their possessions. I would imagine this falls under a similar ruling.

In most cases yes, but isn't ethereum all about "the code _is_ the contract"? If you as the owner of a house put an ad in the paper saying "if you can manage to enter my house feel free to take whatever you want", should you complain if someone did exactly that?

Yes because that would still be a crime. Expanding on your analogy - if I declare right now that it's ok to murder me, it's still not ok to come and murder me. Same principle applies to EULAs and Terms of Service, you're not bound to it just because it's in there.

If the hacker was entitled to those funds based on the agreement between the concerned parties (implicit OR explicit in the contract) it would not be theft. But it clearly isn't their Ether and the implicit agreement behind the contract stands.

Basically human ethics, morals and the legal system will always trump code.

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

#597
post #388

Earlier quoted context omitted.

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

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

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 ?

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

#598

Earlier quoted context omitted.

> 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

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

#599
post #590
post #585

Earlier quoted context omitted.

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

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

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

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

#600
post #524

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?

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.

Post reply on HN