Live data from Hacker News

153k Ether Stolen in Parity Multi-Sig Attack

etherscan.io

501–510 of 754 posts

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

#501
post #299

Earlier quoted context omitted.

I agree that it was a key to the success; but it will also be a key to it's failure. Because it's a financial system, and normal sane people don't want money that is demonstrably worse for nearly all the things that normal sane people do with money. Ethereum is a great political statement, and a fun toy... but when you recast the worse is better story into this context, you're just demonstrating that you don't really…

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

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.

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

#502

Earlier quoted context omitted.

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

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

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

#503

Earlier quoted context omitted.

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.

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

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

#504
post #276

As Charlie Lee said: If the creator of Solidity, Gavin Wood, cannot write a secure multisig wallet in Solidity, pretty much confirms Ethereum is hacker paradise. https://twitter.com/SatoshiLite/status/887781929726038016

I'm confused. Did Gavin Wood write the code for the Parity wallet, forgetting that he had created a language where function visibility defaults to "public"?

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

#505

Earlier quoted context omitted.

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

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

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

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

#506

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…

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

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

#507
post #323

Earlier quoted context omitted.

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

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

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.

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

#508
post #233

Earlier quoted context omitted.

Tax forms don't have a place to declare assets, iirc, only income.

Right, so I guess I was asking: If you cash out everything as quickly as possible, no one from the government will ask where your millions came from?

The IRS has this interesting FAQ on their webpage

> https://www.irs.gov/publications/p17/ch12.html#en_US_2016_pu...

Illegal activities. Income from illegal activities, such as money from dealing illegal drugs, must be included in your income on Form 1040, line 21, or on Schedule C or Schedule C-EZ (Form 1040) if from your self-employment activity.

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

#509
post #444

Earlier quoted context omitted.

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.

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

#510
post #11

I've posted this before [0], but it's still apropos regarding the foolishness that is Ethereum. [Ethereum] only makes sense if all of the following obtain: (a) the code is 100% bug-free (b/c accidents cannot be rewound) (b) all code-writers are 100% honest (their code does what they say) (c) all contract participants are 100% perfect code readers (so as to not enter into fraudulent contracts) (Strictly speaking, only…

Not really true. Nothing has to be perfect if there is insurance infrastructure. People should not use contracts they have no reason to trust. As a contract becomes more important it should be viewed/vetted/trusted by as many entities as possible. Users of the contract should pay an insurance fee that goes to the vetters, who promise to reimburse in case of unpredictable behavior. Yes, this means applying some meatsp…

There are a few problems with this.

1) moral hazard/information assymetry - If I insure you against fraud I have removed most of your financial incentive to protect yourself, so I need to have some other reason to think that you will. I also need protection against the fact that you have more information than I have about the risk of fraud (how do I know you won't collude with the fraudster, in effect defraud yourself and collect on the insurance?) In the normal world this category of concerns prevents lots of types of risks from being insurable, and we have criminal law to protect against collusion 2) Capital commitment - It's not sufficient to just get a promise from the vetters, the capital has to be committed (ie escrowed in some way) otherwise how do I (as an insured party) know they will make good on their payment when I need them to? As an insured party I have to be able to verify that you have done this. In the normal world, this is handled by regulatory capital guidelines for insurers and counterparty collateral posting in the world of OTC contracts. 3) Network effects - If I have capital in escrow, the contracts protecting that escrow would presumably themselves become extremely high-value targets for fraud. Can they be insured? How would you know that the capital is committed to pay out on these insurance contracts? Escrow again? This is a very significant bootstrapping problem - how do I as a participant somewhere in this chain know that in the last resort my insurance will be able to pay out so that if need by I can make good on my commitments. In the normal world this is handled by central counterparties demanding collateral posting against open contracts.

It's very tempting for engineering/technical people to assume that even though they don't really understand all the details, everything has an engineering/technical solution that would be so much better than what has been developed by their predecessors. This disruptor's hubris is necessary for progress to be made against very hard problems otherwise they would probably be to daunting to tackle.

Trust in the existing contract law system has grown organically over a very long period of time. Some of the smartest people going are lawyers and they've had a significant head start on these problems. It would be pretty difficult for trust to evolve organically given some of the poor decisions and scale of subsequent fraud that has already happened in the "smart" contract world.

Post reply on HN