Live data from Hacker News

153k Ether Stolen in Parity Multi-Sig Attack

etherscan.io

721–730 of 754 posts

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

#721
post #611

Earlier quoted context omitted.

And you are not saying anything about the VM itself which behaves differently in certain cases... Look at our last article on this specific topic: https://blog.coinfabrik.com/smart-contract-short-address-att...

The devs really need to understand that in the niche that they're targeting, unless they can be absolutely sure that some default is safe, there should be no default. Most of these issues stem from this same fundamental problem - they pick some default, or some implicit behavior, ostensibly for convenience, but with unanticipated undesirable side effects.

I don't agree, you cannot expect to handle millions of dollars with those tools in the same way you don't write mission critical software in bash.

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

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

None of the languages that you mention target the EVM, and the changes required to do so would turn them into restricted versions that look kind of like the original ones but have several differences that you need to keep in mind while programming in them. It makes quite a lot of sense to create a new language that takes advantage of the particular features provided by the EVM. It's also quite hard for programmers to…

> should strive to use the most economical bytecode available to perform each task.

This is why I criticized the VM design as well as the language.

Yes, much effort went into making "cycle counting" as simple and straight forward as possible.

But I don't see any comparable effort doing the same for safety and correctness. (Apart from providing crypto primitives by the VM, which is neat, but only the tip of the iceberg in terms of language design.)

> It's also quite hard for programmers to reason about performance or complexity in most functional languages

This is true for Haskell, but "most" other functional languages don't suffer this issue: SML, OCaml, F#, Rust, etc.

Also note that lots of effort already went into creating lambda calculus variants where performance is especially easy to reason about. However, dismissing functional langauges as a whole already demonstrates that none that the research played any role in the design of EVM and Solidity.

In case you are interested, here is a nice starting point about the state of the art of 2014: "Structure and Efficiency of Computer Programs" https://www.cs.cmu.edu/~rwh/papers/secp/secp.pdf

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

#723

Earlier quoted context omitted.

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

I think people agree that a price rise was a bubble after it pops, and I don't believe that prediction is a necessary condition.

It is, otherwise how do you distinguish a bubble from a rise justified by fundamentals ?

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

#724
post #708

Earlier quoted context omitted.

I cannot say enough good things about TDD, but YMMV. I also don't stick to it always... it's just that when I take the time to, my code clearly ends up better. I would imagine it's even MORE beneficial in code that deals with a money...

I find it hard to write tests when I'm still formulating the logic of how a problem should be solved. For money-based logic in Solidity, I now like to model it in MS Excel first, write code afterwards, and then finally tests.

> I find it hard to write tests when I'm still formulating the logic of how a problem should be solved

I think everyone does. I certainly do. But pushing through that actually helps your designing, because you start thinking of things in terms of how the API will look, how each building block leading to the final computation will look, and the need to be able to unit-test it as you go forces you to write smaller, more tightly-focused components automatically, which ends up making more maintainable code that is easier to reason about

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

#725
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

The guys who just stole $30M and $70M beg to disagree.

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

#726

Earlier quoted context omitted.

Speaking as an Ethereum core developer here - I see a lot of misdirected criticism and misunderstandings of Ethereum and the platform in the wider tech community. That said, your criticisms here are absolutely spot on; these are definite issues with Solidity as a smart contract programming language. The only small correction I would make concerns this: > Functions can mutate state by default. Both are overridable by…

Do you guys plan to address these at some point? Actually, let me rephrase this. For better or worse, Solidity is a shipping product now, so you're constrained in your ability to make breaking changes. However, its status as the "official" blessed EVM language can be changed without breaking compatibility. So I guess a better question is, are you planning to replace Solidity with a language that has more emphasis on…

There is an EIP that is slated to land in the upcoming hardfork that adds an EVM opcode for effectively "const" call that is enforced by the runtime: https://github.com/ethereum/EIPs/pull/214/files

There are also proposals out for a number of the issues you have mentioned. I believe that people _do_ want to make Solidity into a better language for safe code authoring, but some things require EVM changes which requires a hard fork, and other things simply require time (discussion and engineering). The impression I get is that at this point there _are_ some voices of reason involved in the Solidity language process, but it will take time before those voices can enact all of the changes listed here.

Also, keep in mind that when Ethereum launched it did so like any scrappy startup, with an MVP that was "good enough" to move things forward. Now that Ethereum is a leading contender in the blockchain race it is starting to have to pay for some of those early decisions.

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

#727
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

From a Hegelian perspective, the best thing for Ethereum is for it to race back and forth across dialectics as quickly as it can. There will be many money stealing events as we discover how to do cryptocomputing safely. Better to get them over with now while the market cap is small and people know not to rely on it for anything too serious.

If they were to be as safe as possible, there would be less news, and they would push the traversal of those dialectics further into the history, when more people are using Ethereum and these kinds of events can do more damage.

It's beta. Don't worry about it. Come back in 10 years when the Heroku of Ethereum is released. Buy a couple Ethers now so you'll be rich then.

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

#728

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…

How bound are people to using Solidity? How hard would it be to come up with a competing, more verifiable langauge specification? I don't know much about Ethereum, but I assume the Solidity gets compiled to some sort of bytecode to run on the VM?

This was exactly the first thought that came to mind when I first read the Solidity docs.

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

#729
post #599

Earlier quoted context omitted.

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

Do we really want to lower barrier to entry for writing code that can misdirect $30 million dollars just like that? By the way, I went and looked at the offending contract. The pull request that introduced the line with the bug added 2228 new lines of code while removing 918 lines. In fact, the diff is so large that GitHub doesn't even show parts of it by default (including the part with the bug). The pull request wa…

Can you please link to this pull request?

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

#730
post #520

Earlier quoted context omitted.

> 99 out of 100 questions. Curious question of a non-native speaker: What does this phrase mean? (in general, and in this context)

http://persuasive.net/what-is-the-answer-to-99-out-of-100-qu...

Brilliant... and so true!
Post reply on HN