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

461–470 of 754 posts

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

#461

Post by avaer »

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…

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 it's not a mystery why the language is "hacky". Perhaps being a good language is not even the driving goal.

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

#462

Post by MaxfordAndSons »

vazhifarer wrote: post #456
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

> Block scoping is default now in JS

The default best practice, you mean? Declaring with 'var' will still get you the same lexical scoping rules as always.

I believe OP meant 'inherited from pre-ES6 JS'

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

#463

Post by imron »

dvcc wrote: post #34
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

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.

Imagine the court case:

Your honour, in my defence, the contract clearly specified that anyone could reset the wallet, and if that's not what they wanted, they shouldn't have agreed to it.

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

#464

Post by qyv »

grandalf wrote: post #68
twblalock wrote: post #38

Earlier quoted context omitted.

> Ethereum offers immutability, and blockchains can foster new kinds of trust, but trust still has to grow organically in the ecosystem. If you need a source of trust outside of the blockchain, why would you need the blockchain after such trust has been obtained?

> outside of the blockchain The blockchain offers characteristics (immutability, consensus, distributed backup) that allows entities to trust each other efficiently. But when you introduce a non-trivial smart contract, there is a chance that it (a black box) has behavior that is not obvious from its source code. Since the behavior of the contract will cause immutable changes to the blockchain, and since humans can't…

> there must be some other mechanism for establishing that the behavior of the contract matches the common understanding of what the contract does.

There is, we have been using them for hundreds of years, it is called a contract.

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

#465

Post by riffraff »

joncampbelldev wrote: post #460
kensai wrote: post #459

Earlier quoted context omitted.

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.

Isn't the team also working on a new language targeting the same VM? If so, they might be useful.

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

#466

Post by trevor-e »

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…

Can someone explain to me why they chose to make their own language instead of creating a DSL inside of an existing language?

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

#467

Post by omarchowdhury »

Retra wrote: post #405
omarchowdhury wrote: post #104

Earlier quoted context omitted.

If we enter a contract that we all know is intended to be immutable, why would a judge not enforce that? I can understand buried and obfuscated immutability clauses, but if the parties know exactly what they're getting into, the parameters of justice are contained.

Every single second, mountains of new information becomes relevant. Parties cannot know what they are getting into, because they cannot see the future. They can only make assumptions. But that's basically obvious to anyone not hinging their personal identities on peddling technocratic revolution.

But history is full of successful unmodified contracts despite non-omniscient actors.

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

#469

Post by quickthrower »

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…

We need a Haskell transpiler.
Post reply on HN