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

581–590 of 754 posts

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

#581

Post by Cakez0r »

cookiecaper wrote: post #125
dna_polymerase wrote: post #46

Earlier quoted context omitted.

I can literally feel how Ethereum changes the law. I mean, seriously, no need for lawyers anymore. On ethereum it's is simple: You got fucked, live with it. "Bad faith? It's the code, didn't you read it?"

Won't happen. People need to believe that the justice system will hear their pleas and consider factors on-balance, and then proceed in fairness. In real law, there are several potential overrides available to stop egregiously unfair outcomes that would otherwise be legally valid (estoppel, unconscionability, etc.). People will not accept a system that does not have the appearance of fairness (regardless of its actua…

> One of the things that cyberpunks fail to grasp is that people don't want a perfectly immutable, fixed system.

Some people do.

Source: I am a person who wants this.

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

#582

Post by Cakez0r »

finnh wrote: 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…

(d) Participants in a contract understand and accept the risks of losing their investment to bugs.

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

#583

Post by DennisP »

pdkl95 wrote: post #170
grandalf wrote: post #93

Earlier quoted context omitted.

> do things that are technically allowed, but have unexpected downsides Unexpected downsides for whom? Smart contracts cease to be smart if we have to rely not on the VM but on a small group of human overlords. If a smart contract exists and you don't know clearly how many times it has been used and what percentage of the parties who used it are pleased with its functioning, you really should not use it unless you fe…

> personally reviewing the code. With the insane decision to use a Turing-complete language, the contract's behavior undecidable . You don't even know if the contract will halt . Limited "gas" (execution time) isn't the solution, because the lesson of the Halting Problem isn't that a program might not terminate. Even if the program halts within a finite time (or "gas"), the behavior of the program on the current inpu…

Using a Turing-complete language does not mean that all possible programs written in that language are undecidable. As a trivial example, if a particular program doesn't have loops or recursion, or if it loops for a fixed number of times, it quite obviously will halt. More generally, it's possible to write simple code with clear and obvious effects.

If were really that bad to use Turing-complete code, then smart contracts would be the least of our problems, because Turing-complete code runs our airplanes, medical equipment, and nuclear reactors.

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

#584

Post by cvsh »

vog wrote: post #458
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…

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

But not the kind of people you want to focus on to get traction for your venture-backed startup if you want a relatively quick and profitable exit

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

#585

Post by ojr »

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…

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 not need a complete language like F# and C++ to write contracts, The hacked contract should have had a simple modifier describing only the owner can run this command.

Once again the type system doesn't need to be perfect, if your code on the blockchain is broken you pay a transaction fee and the contract doesn't execute it.

For a language that was made less than 3 years ago, it amazing to see the progression. It will be a language that people hire for in the near future (already happening). Companies are notorious looking for 5 years experience.

Its hard to read the "I told you so replies", when the price of ETH has remained relatively stable during the news

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

#586

Post by [deleted] »

vog wrote: post #520
avaer wrote: 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)

[deleted]

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

#587

Post by pmarreck »

mifeng wrote: post #564
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…

Thank you for succinctly summarizing all my frustrations with Solidity. I am developing a fairly complex smart contract (i.e. not a crowdsale) and it's fucking painful. Trivial computations that would take less than an hour to do in any other language take days to implement correctly. Debugging is also a nightmare. There's no way to step through function calls or set break points, even though it's basically just Java…

How do you create unit tests for Solidity code? This would eliminate much of the need for a debugger while also leading to safer code

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

#588

Post by sah2ed »

flashmob wrote: post #351
davidgerard wrote: post #261

Earlier quoted context omitted.

Actually, I think Solidity being designed to turn bad node.js coders into bad smart contract coders was key to Ethereum's success. I've written a book on this (hit upload five minutes ago! release Monday!) which hammers on this point (and all the stuff surrounding this issue). I think Solidity is actually designed with worse is better in mind, because Ethereum is the first smart contract platform that anyone actually…

You've wet my appetite. Got a link to your book?

This should save anyone else a few clicks: https://www.amazon.com/dp/B073CPP581

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

#589

Post by pmarreck »

lmm wrote: post #549
arjo1 wrote: post #521

Earlier quoted context omitted.

Fixing the language is one step. It will still not prevent hax0rs from targeting the bytecode of the VM itself.

Perfect is the enemy of good.

If that BS was true, we should all just switch to PHP right now

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

#590

Post by knocte »

ojr wrote: post #585
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…

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 going to be addressed very soon because of the difficulty of the redeployment (as naturally backwards compatibility must be the first concern).

> Its hard to read the "I told you so replies", when the price of ETH has remained relatively stable during the news

Haha, so if the price is stable, this means that Solidity is not embarrassing? I'm sorry but this just means that people only care about security when their funds are the ones affected. Not about "potential" security problems or "design flaws" which sound too technical to them.

Post reply on HN