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

571–580 of 754 posts

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

#571

Post by mannykannot »

trevor-e wrote: post #466
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?

When I took a look at it, two or three years ago, I think there were three different guys in the organization each busy with his own idea of a high-level language to put on top of the VM, each inspired by a different GP language. That signaled a certain lack of focus.

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

#572

Post by DennisP »

tomp wrote: post #540
trevor-e wrote: post #466

Earlier quoted context omitted.

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

What language would you choose? AFAIK there are almost no _actually_ secure languages. The ones that exist (e.g. Idris, Agda) are notoriously hard to use (although their Turing "incompleteness" is arguably a feature for smart contracts/distributed computations). Daily LoL: Googling "secure language" brings up mostly results about Java.

Here's a master's thesis by a couple guys who made Idris compile to Ethereum bytecode.

https://publications.lib.chalmers.se/records/fulltext/234939...

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

#573

Post by smoyer »

mbrock wrote: post #523
gst wrote: post #503

Earlier quoted context omitted.

There are lots of different languages targeting EVM. The (IMO) most promising so far is https://github.com/ethereum/viper

You can also just write bytecode directly. It's a simple stack machine, and contracts should be as simple as possible.

For a stack machine, Forth might be a great choice.

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

#574

Post by fab13n »

sna1l wrote: post #218
dvcc wrote: post #178

Earlier quoted context omitted.

I'm kind of curious on what you think about Tezos and its Michelson language ( https://www.tezos.com/static/papers/language.pdf ) which offers provability of contracts.

Just looking at this language, it makes me feel like we are going back in time in regards to readability and ease of use. I understand that security and provability of contracts is more important in these cases, but one can dream!

Michelson is a VM bytecode, not a programming language, although it happens to be readable enough to write simple contracts in it directly.

IIRC, the old Camllight VM was pretty similar (I might misremember, that was literally decades ago); an ML-like language to Michelson compiler is fairly straightforward to write and to prove sound.

I'm happy that they do things the sane way, i.e. focusing on sound foundations rather than on how Javascripty the syntax looks; but I'm afraid the communication isn't as clear as it could/should be. Blessing a compiler for some subset of ML, as a first high level language, would have cleared things up IMO.

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

#575

Post by ericb »

heliumcraft wrote: post #568
ceejayoz wrote: post #425

Earlier quoted context omitted.

https://twitter.com/SatoshiLite/status/887781929726038016 "If the creator of Solidity, Gavin Wood, cannot write a secure multisig wallet in Solidity, pretty much confirms Ethereum is hacker paradise."

Gavin Wood didn't not make the code change that caused this...

I can't edit my post above to add this now, but looks like Charlie retracted this as Gavin was the original author, but not the one who made the mistake.

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

#576

Post by fab13n »

xrd wrote: post #420
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

This seems like a compiler bug, not a systemic issue with Ethereum. No?

It's a bug in a smart contract, but the root cause is the bug-prone design of Solidity. It's hard to write bug-free code in Solidity (or anything targetting EVM actually), and nearly impossible to be confident that a given contract is bug-free.

parity.io, the company author of the bug, is a top-notch Ethereum actor. If they can neither get a wallet contract right, nor realise that it's faulty, then who can write and trust any non-trivial Ethereum contract?

How many DAO or Parity trainwrecks before people admit that Ethereum isn't a dependable platform?

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

#577

Post by richardknop »

sleepychu wrote: post #539
hohenheim wrote: post #500

I wonder, why the black hat didn't drain all the money and left it for the white hat group?

Maybe they estimated that this was the proportion that would protect their gains from a hard fork

I agree. Probably game theory reasons. Don't steal so much it will cause the community to unite and hard fork. 30 million is enough to retire and probably not enough to cause hard fork and rollback of txs. They played it safe.

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

#578

Post by inimino »

Grue3 wrote: post #567
dragonwriter wrote: post #182

Earlier quoted context omitted.

> With the insane decision to use a Turing-complete language, the contract's behavior undecidable. OTOH, if the language isn't Turing-complete, there will almost certainly be things you'll want a contract to do that it can't. You can have generality or decidability, but not both.

If the language is Turing-complete there are definitely things you'll want in contract (such as the execution of it halting in finite time) that you won't be able to enforce. When code is the literal definition the contract, non-Turing complete is the way to go, because you can't reason about your code otherwise.

Turing-complete means you cannot write an algorithm to prove termination in every terminating case, but it doesn't mean you can't prove termination in particular cases, and it certainly doesn't mean you can't reason about your code.

Based on other comments here there certainly may be questionable decisions in the design of Solidity but that doesn't mean Turing-completeness is one of them.

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

#579

Post by inimino »

Blackthorn wrote: post #403
grandalf wrote: post #270

Earlier quoted context omitted.

> It is possible to have trusted contracts, iff their logic is (mathematically) proven. Suppose a non-Turing-complete language were used instead. Now, imagine a contract that is highly complex. If a layperson decides to trust that contract without reading the code, does it matter whether the language used to implement the contract was Turing-complete or not? I'd argue that trust of contracts is pragmatically more of…

> If a layperson decides to trust that contract without reading the code, does it matter whether the language used to implement the contract was Turing-complete or not? Um, yes? Literally the point of weaker languages in this context is that they can be statically provable.

As would the same program written in a Turing-complete language. The Turing-completeness here is a total red herring.
Post reply on HN