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

271–280 of 754 posts

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

#271

Post by vocatus_gate »

csomar wrote: post #67
joshschreuder wrote: post #52

Let's play hypotheticals. If you were the attacker and you now have the ETH in your wallet, how do you cash out without anyone identifying you and maximising your profits? Also has the attacker broken a law by exploiting a bug in the contract?

There are mixers where you can get close to not being traced and then can move through monero and then to bitcoin.

Monero is the ONLY cryptocurrency where full privacy is enforced by default. No mixers, no opt-in mode, no super-nodes, no tumblers, it's all obfuscated by default. I'm very bullish on Monero long-term.

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

#272

Post by sillysaurus3 »

nebulous1 wrote: post #263
sillysaurus3 wrote: post #245

Earlier quoted context omitted.

https://github.com/paritytech/parity About Parity Parity's goal is to be the fastest, lightest, and most secure Ethereum client. We are developing Parity using the sophisticated and cutting-edge Rust programming language. Parity is licensed under the GPLv3, and can be used for all your Ethereum needs. Parity comes with a built-in wallet. How is this not a third-party wallet? They say right on the page that they're tr…

You compared it to Mt Gox, which is where the confusion is coming from. With an online service like Mt Gox you don't have control of the coins at all. I have no issue using an open source implementation of something. You haven't explained why that's an issue.

Whether it's an online service or a local wallet with an embedded buggy smart contract, your coins are just as gone. If you're perfectly happy to use it, you're perfectly happy to lose everything.

How many millions need to be lost before this lesson is learned?

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

#273

Post by ricardobeat »

lawrenceyan wrote: post #103

Silver lining: https://etherscan.io/address/0x1dba1131000664b884a1ba2384641... Looks like about +300,000 ether was able to be drained before it could be stolen thanks to a white hat group.

Only good if they can keep the group together after amassing 70+ million dollars.

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

#274

Post by theptip »

Can someone explain to me why you would want a smart contract for multi-sig? This is a feature that can be implemented easily off-chain, i.e. using split keys (Bitcoin has had this approach for some time).

Seems like having this complex logic on-chain is asking for it to be exploited.

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

#275

Post by mcbits »

finnh wrote: post #189
flamedoge wrote: post #183

Earlier quoted context omitted.

not even banks can give you guarantee of safely holding money with impeccable degree of certainty. Uncertainty cannot be avoided.

Slow down! Let's just aim for reducing uncertainty. Let's say we have an uncertainty scale scored 1-100. If 100 is "money in a bank" and 1 is "money that's already been set aflame, but there's a cup of water nearby", I'd put Ethereum in the low single digits =)

If we put "cash in a hidden safe" at 1, I'd put "money in a bank" around 10. My checking account was once drained by the state on a clerical error. Or almost - they left me 17 cents. They did have a process to get it back (which, interestingly enough, involved emailing cryptographically signed documents back and forth), but it took a few days, and it was only lucky timing that prevented it from triggering a cascade of problems.

These newfangled experiments that I don't fully understand are still well above 10 for me, but they only have to get down to around 11-15 before I'll be interested.

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

#277

Post by buckie »

lomnakkus wrote: post #238
dvcc wrote: post #34

Earlier quoted context omitted.

Why would an unmarked function get the broadest possible scope in a language designed for contracts? I'm always surprised by the decisions made around Ethereum, and just how much value people have poured into it.

It's a good indicator that these people may be experts in one area, but not necessarily in others. Language design is actually notoriously difficult in general[1], but if you're doing language design for a security-critical language[2]... well, that requires actual mechanized proof , IMO. Not just proof of "design", but proof of the implementation. Anything else is a huge gamble. (And I'm sure there are some 'investo…

> Not just proof of "design", but proof of the implementation.

Absolutely, few people really get this. Even those that do get it generally don't know what it looks like in practice because it's so rare.

In case you're curious about what it looks like in practice (at least one way), we presented direct user code compilation and verification[1] in Jan for our smart contract language Pact[2].

The idea that you can write a doc test that triggers a formal verification about some aspect of your code is, for lack of a better term, strange and yet the power to weight ratio is just off the charts. For the first few days that the system started working (I built the FV portion, Stuart the language + H-M type system) I thought it was broken... turned out we just had a bug in our demo code that we never noticed.

Usually, tests check the things you know to check so when they find something it's not a surprise what they find. Sometimes you can fuzz and randomly find something, which is cool but doesn't guarantee that there isn't a problem somewhere else. However, FV just feels uncanny (as a dev) because the test either finds a problem in the code -- and tells you how to replicate the bug -- OR proves that a problem cannot exist.

[1]: https://youtu.be/Nw1glriQYP8?t=1071

[2]: kadena.io/pact

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

#278

Post by munificent »

davidgerard wrote: post #265
theseatoms wrote: post #211

Earlier quoted context omitted.

Ethereum's original sin

The DAO hit every objection from smart contract skeptics, bang bang bang - legal code doesn't work at all like computer code, immutability means you can't fix mistakes, immutability means you can't deal with changes in circumstance, immutability means you must code with 0 bugs - but even we were surprised when they went "lol immutability guarantee" the second the big boys were in danger of losing money.

It's almost as if software technology can't magically solve problems inherent in the flawed nature of humanity.

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

#279

Post by 52-6F-62 »

AlexandrB wrote: post #135
52-6F-62 wrote: post #99

Earlier quoted context omitted.

I understand your counterpoint, but I don't think it's accurate. I mean, if it isn't verifiable, then how would it at all be exploitable, and then patchable? Even so, any product designed for the network could be tested to death on any of the available testnets. It would be foolish not to ram any project up against everything in that environment, which is why I suggest poor practice as a primary cause. It was an over…

> I mean, if it isn't verifiable, then how would it at all be exploitable, and then patchable? Let's assume you're right and smart contracts are verifiable. Verifiable by whom? I can assure you that my non-techie friends could not verify a smart contract themselves, so they will have to trust some authority that verifies the contract for them. The chain of trust now moves entirely into meatspace again and will be sub…

Well you've picked up on very difficult bit of semantics, and one that is probably worth its own discussion entirely.

The code is verifiable by a skilled engineer (in good faith) -- so there is a catch. Any body that produces a smart contract requires the trust of those who take part. Alternatively, it requires trust in one's own expert engineer to verify the content and functioning of a smart contract.

Where Ethereum is trustless is in the execution of the contract once verified. There is then no course for non-delivery if the code is designed this way.

So, it's trustless at one level, and requires trust at another. When I say it's semantics it's just this last point.

Personally I don't see the problems other see with that, because I don't see blockhain tech and tokens replacing everything all in one go, including the need for governing bodies and law. I don't see it as a choice between one or the other. For what it's worth, I'm closer to a socialist than the usual libertarian ranks that flock to these things. I think the world would benefit from the efficiency it could bring about, once the kinks are worked through.

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

#280

Post by plainOldText »

earlz wrote: post #25

Here's the root error I believe: https://github.com/paritytech/parity/blob/master/js/src/cont... The initWallet function should have been marked internal, but was instead not marked. Unmarked functions default to public in Solidity, so anyone can call that function and reinitialize the wallet to be under their control

That is correct! Here's their proposed fix https://github.com/paritytech/parity/commit/e06a1e8dd9cfd8bf...
Post reply on HN