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

451–460 of 754 posts

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

#451

Post by camel_Snake »

git-pull wrote: post #434
shurcooL wrote: post #350

Earlier quoted context omitted.

Please be aware that you can press Y before sharing a link to make it a permalink. The link you shared points to master branch, which will change over time, so the line number you pointed to will have something else. Based on the time of your post, I suspect you meant to link to: https://github.com/paritytech/parity/blob/4c32177ef3f4521c66...

Some explanation of what's happening here: The initial poster posted this link: https://github.com/paritytech/parity/blob/master/js/src/cont... Where "master" is the branch which normally has the latest code. And #L216 automatically scrolls down to the 216th line. The issue is that line isn't permanent since the code in the master branch is subject to change. So in order to make a reliable link, you can link to the r…

Thank you for that thorough explanation!

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

#453

Post by runeks »

sniffles wrote: post #418
tzs wrote: post #333

Earlier quoted context omitted.

I realize that was probably satire or sarcasm or both, but since I've seen people actually seriously take that position I'm going to go ahead and respond as if it was serious. How do these smart contract deal with the real world? I can see how they can work for things that entirely involve activities that take place on the block chain (e.g., a smart contract that automatically pays a crowd funded project if and only…

Didn't you just describe an example where the ambiguity of human language is a problem and a smart contract may actually have a better chance of performing as expected?

Why do you asssume smart contracts can't be ambiguous? A lot of people read the DAO contract, and yet it took a hacker a while to find a small error -- if I recall correctly it was a capitalization error -- that triggered an unexpected exit path.

At some point you have to ask yourself whether we really prefer that code be law, with the quality of code that's so common these days, or whether we actually like being able to specify something to a lawyer -- rather than a computer -- simply because the lawyer will return the contract and ask for clarification if something is ambiguous/unclear.

The human-to-lawyer interface is the best contract interface that exists, the only reason we use computers is because they're so cheap and fast. When we dream of AI we dream of having a computerized lawyer, who can ask clarifying questions and resolve ambiguity before it becomes a problem.

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

#454

Post by defined »

slackingoff2017 wrote: post #442
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

"Solidity" is a pretty sarcastic name for the language at this point :)

Did you mean "ironic"?

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

#455

Post by abalone »

notahacker wrote: post #316
grandalf wrote: post #247

Earlier quoted context omitted.

> Chargebacks are a blessing when you need them and a curse when you receive them, but something that the economy has deemed a necessary evil mostly because there are a lot of fraudsters in the world This is an excellent point, and I think it's an example of how an institutional mechanism evolved to help address fraud. There's absolutely no reason to think chargebacks would not come to exist if commerce were dominate…

I don't think anyone doubts that smart contracts can be written that allow for a trusted third party to effectively reverse a payment, especially not in Turing-complete languages. I think the point is that if mutability and trusted third party oversight is actually usually a necessary and desired fraud prevention feature in a payments system, there's probably not huge demand to replicate all that using blockchains wh…

> if mutability and trusted third party oversight is actually usually a necessary and desired fraud prevention feature in a payments system, there's probably not huge demand to replicate all that using blockchains whose most-touted virtue is immutability and trustlessness

This is exactly right. Once you empower trusted intermediaries to police and reverse transactions, you lose cryptocurrency's primary raison d'être.

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

#456

Post by vazhifarer »

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…

> 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

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

#457

Post by matt_wulfeck »

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…

This is an amazing write up. How long did you spend in the code before jotting this down?

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

#458

Post by vog »

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…

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, programmers valuing languages like Haskell/OCaml/F#/Kotlin/Rust, who would only ever touch C with verified compilers and 5 different static analysis tools?

Well, that's exactly kind of people you to attract to write your security-sensitive code.

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

#459

Post by kensai »

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…

Seriously, these observations should be submitted to the Solidity team for consideration.

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

#460

Post by joncampbelldev »

kensai wrote: post #459
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…

Seriously, these observations should be submitted to the Solidity team for consideration.

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.
Post reply on HN