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

561–570 of 754 posts

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

#561

Post by mbrock »

pdkl95 wrote: post #556
mbrock wrote: post #533

Earlier quoted context omitted.

Obviously all EVM programs halt, otherwise the Ethereum network would be completely ruined immediately. You already know why they halt: there's a gas limit. Ethereum programs aren't Turing complete. They always halt. Turing complete programs don't generally halt. That's the definition. You should demonstrate your understanding by using these terms correctly! This whole argument about Turing completeness is a huge red…

> You already know why they halt: there's a gas limit. Did you actually read my post? I'm not claiming halting is a problem; it's merely an example of undecidability . The "gas limit" doesn't help in the cases where the program does halt with unexpected behavior. > Turing complete programs don't generally halt. That's the definition. Where did you get this nonsense? See [1] for the actual definition. > attack was an…

If you can't prove the correctness of your program, you shouldn't run it. Why are you concerned with proving the correctness of arbitrary programs? Can you give an example of an Ethereum-like program that can't be proven correct?

Here's how reasonable Ethereum contract development should happen. You construct the contract, either in some high level language or in bytecode. Then you prove, using some reasonable formalism (TLA+, Isabelle, paper, symbolic execution, or whatever), that the contract does what it should do. Then people who want to trust the contract look at this proof.

This is not at all hindered by the EVM being quasi Turing complete, because at no point do you have the question "How can I mechanically verify halting of an arbitrary program?"

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

#562

Post by lngnmn »

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…

Yet another homegrown PHP-sque language. The Fractal Of Bad Design is actually a pattern.

My bet they never took any PL course, and have very vague understanding of what consequences certain design decisions would produce. "20 years of PHP coding" or something like that.

Any decent PL course would emphasize the first-class-everything (procedures , obviously), lexical scooping for proper closures, strong but dynamic typing (no implicit coersions) etc. No matter which sect one belongs to - ML or Scheme - these are universal fundamentals, the well-researched foundation.

PHP/Javascript coders usually do not understand the principles and implications behind languages they use. Otherwise they would develop a healthy aversion, like to a tasteless, vulgar porn.

Sane people with PL background would use a dialect of Scheme as a DSL (the numerical tower and all the nice things) or at least Lua (because packers are afraid of parenthesis and see nothing behind of them).

Actually, Scheme (or a simplified dialect such as the one inside Julia - flisp) would be almost ideal choice for financial DSLs.

For those who are cosplaying a PL expert (with 20 years of PHP and Javascript coding under their belt) there is a good read: http://users.rcn.com/david-moon/PLOT3/

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

#563

Post by shp0ngle »

dahdum wrote: post #374
kbenson wrote: post #284

Earlier quoted context omitted.

That may be, but if so, it might be worse . What's worse, not getting a lot of uptake for this idea that's been hard going for others, or getting the uptake because of trade-offs you made that make it a ticking time-bomb that may damage the reputation of the idea for years to come and set it back?

Solidity is like PHP in the 90's, easy to learn and easy to screw up. Though Solidity just compiles to the EVM, and there is no reason new, safer languages can't be built on top. As far as I can remember, the EVM has never failed, just programmers.

I disagree, Solidity is really not easy to learn. It is easy to screw up, though.

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

#564

Post by mifeng »

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 Javascript. Multiple classes of bugs will generate the same "invalid opcode" error that is only visible at run-time with no indication of what line even triggered the error.

This is why I invested in the Tezos crowdsale. Smart contracts are a great idea but there's gotta be a better way.

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

#565

Post by shp0ngle »

wheelerwj wrote: post #212
TylerE wrote: post #140

Earlier quoted context omitted.

Because the cryptocurrency space attracts only the brightest minds .

i know that you're not really serious when you generalize against all of us crypto simpletons, but anytime theres a stupid amount of money on the table people are bound to rush to pick it up. and that means mistakes. the work being done on public blockchains is unlike anything else done before. You don't have he luxury of keeping your db behind a vpn running on a vm platform secured and maintained by the worlds large…

The thing is, cryprocurrency people usually think of themselves as smarter and better programmers than the rest of us. They even co-opted the term "crypto" to mean their toy currencies instead of actual real life, useful cryptography.

But yeah I admit, cryprocurrencies are good toy projects on which to learn real crypto, that's true. But then it's time to move on. And not to pour millions of dollars into that

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

#566

Post by pmlnr »

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.

Ada.

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

#567

Post by Grue3 »

dragonwriter wrote: post #182
pdkl95 wrote: post #170

Earlier quoted context omitted.

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

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

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

#568

Post by heliumcraft »

ceejayoz wrote: post #425
shrewduser wrote: post #424

Earlier quoted context omitted.

I wish I could see how the op is employing the no true Scotsman fallacy, but I can't.

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

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

#569

Post by heliumcraft »

ericb wrote: post #276

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

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

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

#570

Post by TeMPOraL »

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

Maybe they should have restricted their memory access model by using a stackbased language like Postscript.

> like Postscript

That would be cool. Even cooler would be if they created a code style culture around small contracts such that a contract should print out a legal-looking document with its own source code, when echoed to a printer.

Post reply on HN