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

681–690 of 754 posts

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

#681

Post by d21d3q »

git-pull wrote: post #434
shurcooL wrote: post #350

Earlier quoted context omitted.

Please be aware that you can press Y before sharing a link to make it a permalink. The link you shared points to master branch, which will change over time, so the line number you pointed to will have something else. Based on the time of your post, I suspect you meant to link to: https://github.com/paritytech/parity/blob/4c32177ef3f4521c66...

Some explanation of what's happening here: The initial poster posted this link: https://github.com/paritytech/parity/blob/master/js/src/cont... Where "master" is the branch which normally has the latest code. And #L216 automatically scrolls down to the 216th line. The issue is that line isn't permanent since the code in the master branch is subject to change. So in order to make a reliable link, you can link to the r…

BTW, how does y shortcut works? With what is bonded? What effects brings on other sites?

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

#683

Post by MockObject »

vasilipupkin wrote: post #422
Taek wrote: post #388

Earlier quoted context omitted.

Crypto has had at least 3 distinct bubbles. There's the current one, marked by Eth's absurd rise to $300. The previous one was when Bitcoin made an absurd rise to $1200 in 2014. There was a bubble before that where Bitcoin rose to $266 in 2011. And one before that I believe where Bitcoin rose to $32 in 2010. Though crypto has risen past the high point of each of these bubbles, each price point can be definitively cla…

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.

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

#684

Post by albertgoeswoof »

philh wrote: post #620
albertgoeswoof wrote: post #596

Earlier quoted context omitted.

Yes because that would still be a crime. Expanding on your analogy - if I declare right now that it's ok to murder me, it's still not ok to come and murder me. Same principle applies to EULAs and Terms of Service, you're not bound to it just because it's in there. If the hacker was entitled to those funds based on the agreement between the concerned parties (implicit OR explicit in the contract) it would not be theft…

> Yes because that would still be a crime. Expanding on your analogy - if I declare right now that it's ok to murder me, it's still not ok to come and murder me. The comparison to murder doesn't work because you can't consent to murder, but you can consent to theft. It's not clear to me whether that situation would be taken as consent, but unless you know something I don't, it probably shouldn't be clear to you eithe…

How do you consent to theft?

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

#685

Post by antocv »

Animats wrote: post #226
antocv wrote: post #203

Earlier quoted context omitted.

Byteball ( https://byteball.org/ has declarative smart contracts!

That looks interesting. I just skimmed the white paper. It's not clear what their contracts can do, though. They need more examples. The underlying DAG idea has potential. You could have two half-transactions happening on separate subtrees, where A is buying X from B and B is paying Y to A. So A broadcasts "A will buy X from B when B pays Y to A", and B broadcasts "B will pay Y to A when A buys X from B". When the ma…

Yes they do have that what you are describing, "smart conditional payments".

You can for example trade user-defined (possible private) assets (tokens) in that way - "Ill send you my bytes for your blackbytes, I send bytes to this address and me can sweep them back after 4 hours, or you can sweep them if payment of X amount of blackbytes is made to my address". It has oracles as well.

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

#686

Post by splintercell »

abrkn wrote: post #644
ericb wrote: post #281

Things like this are why I think Tezos, when/if it comes out, has a bright future. I want a formal proof for any contract I use with real-money.

Can you provide any reading material into formally proven contracts?

What kind of reading material are you looking for? Formally proven Smart Contracts would be the same as formally proven non-smart contract computer programs.

There is a paper[1] written by some researchers on how using a more powerful language (Such as Idris) could prevent a whole category of errors in smart contracts development, but it doesn't necessary talk about formal verification of smart contracts.

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

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

#687

Post by splintercell »

davidgerard wrote: post #303
kensey wrote: post #300

The great thing about reading this comment thread is that I basically already read it a couple of weeks ago, because a friend of mine (David Gerard, of Wikipedia, RationalWiki and Rocknerd Internet fame) let me preview his forthcoming e-book _Attack of the 50-Foot Blockchain_. There's a whole section in there about smart contracts, Ethereum, and The DAO that goes over much of what commenters here have mentioned ("non…

:-D Ask me anything ;-) I have, like, a whole chapter about smart contracts which answers everything about this latest disaster. The idea is that it will be a handy rhetorical ammo dump for when someone asks you about those blockchain things and why the business needs them ...

I hope you are mentally prepared for the sheer amount of negative reviews you're going to get on Amazon.

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

#688

Post by int_19h »

nicksdjohnson wrote: post #672
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…

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 safety in its design (even if it's called Solidity 2.0 or whatever... clearly it would have to significantly break backwards compatibility).

Now, I know that most feedback that you hear is to just take an existing functional language. But after looking at Solidity and EVM specs, I also see why this is not necessarily feasible. And, as one of your contributors has pointed out in this thread, functional style can often be too high-level to keep track of the underlying opcodes and their gas cost.

But even sticking with the imperative approach, I think it's clear that there's a lot that could be changed, starting with adopting some key principles like "explicit is better than implicit", "don't pick a default unless it's absolutely safe" etc. Looking at the design of Solidity, it's clear to me that the primary inspiration was JS with a dash of C++. The one thing that's common to both is that they allow and encourage "clever" code. Perhaps looking at Ada, Eiffel, and even COBOL for inspiration would be more appropriate for this niche.

In any case, if you're interested in specific suggestions on how to redesign, I do have some thoughts, and would be happy to share them.

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

#689

Post by int_19h »

simias wrote: post #600
ikken wrote: post #524

Earlier quoted context omitted.

This is because running code on Ethereum VM and storing data is hugely expensive (rightly so, as it's being done on all nodes in the world). Therefore Solidity will try to compile into a VM code that uses the least numbers of cheapest instructions and pack data into as small memory package as possible.

Most of the issues pointed out by int_19h would be handled at compile time during static analysis and wouldn't change much to the generated bytecode. I'm talking about strong typing, immutability by default, less error-prone syntax, tail calls, evaluation order etc... Even replacing 256bit ints with arbitrary precision "bigints" wouldn't add too much of a cost if it's a native type of the underlying VM (as it should…

It's about costing the operations reliably.

But I would still expect arithmetic to be overflow-checked by default, as in e.g. VB.NET. This would mean that careless arithmetic on unvalidated inputs could still cause the contract to fail - but at least it would be a controllable failure, with all state changes being reversed, and hence not exploitable.

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

#690

Post by int_19h »

wslh wrote: post #611
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…

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.
Post reply on HN