Earlier quoted context omitted.
Matt Levine has some thoughts [1] on that matter. [1] https://www.bloomberg.com/view/articles/2016-06-17/blockchai...
That dude's read a lot of DFW.
Excuse my ignorance, but what is DFW?
153k Ether Stolen in Parity Multi-Sig Attack
621–630 of 754 posts
Re: 153k Ether Stolen in Parity Multi-Sig Attack
#622Earlier 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…
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…
Being a good, secure language for writing smart contracts is absolutely one of the most important goals for Solidity. I can say so because I have been involved as a regular contributor to the compiler for more than a year. If onboarding a lot of people to the platform quickly were the goal instead, they would have ported some crippled version of Java or JS and called it a day.
The problem is that it's just not easy to get all those details right from day 1, and interest in Ethereum has grown way faster than its capacity to produce a reliable, mature set of tools around it.
Re: 153k Ether Stolen in Parity Multi-Sig Attack
#623Earlier 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.
Most of these observations are well-known to the Solidity devs. I know because I participate in many of the conversations around it. While it's not easy to evolve a language (the API surface is pretty wide compared to many other programs), Solidity is indeed changing and improving regularly, only limited by the available time of their contributors.
Re: 153k Ether Stolen in Parity Multi-Sig Attack
#624I believe from looking at the fix [0] I was able to trace back the origin of the bug. This is my (unverified) theory. Can anybody familiar with serpent confirm?
There is a catch-all [1] function in the public API (why???) of the wallet contract which uses delegatecall to delegate to the library class.
"In a similar way, the function delegatecall can be used: the difference is that only the code of the given address is used, all other aspects (storage, balance, ...) are taken from the current contract." [2] (again, WHY???)
So calling through this catch-all function the "internal" modifier on "initMultiowned" does apparently not prevent it from being called, since the delegation happens from a function inside Wallet.
So the "attack" is to just tell the wallet to reset its owners to myself. This would be so embarrassingly trivial, that it's more like picking the money up from the floor, than a "heist".
This wallet contract is insane and the programming language too. Why would a language for such a critical application have such super unsafe constructs? This can't be true. Please, serpent community, talk to your local PL people!
[0] https://github.com/paritytech/parity/pull/6103/files [1] https://github.com/paritytech/parity/blob/02d462e2636f1898df... [2] https://solidity.readthedocs.io/en/develop/types.html#addres... [3] https://github.com/paritytech/parity/blob/02d462e2636f1898df...
Re: 153k Ether Stolen in Parity Multi-Sig Attack
#625I 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
My guess is that they didn't expect it to be so easy, and were surprised by the success, and started to party on, and forget (or were too drunk) to take the rest of the money that was on the table.
Anyway, your theory is much better than mine.
Re: 153k Ether Stolen in Parity Multi-Sig Attack
#626Is this even illegal? Or just frowned upon? It seems this is just one big game, you find the weakness and you profit.
Re: 153k Ether Stolen in Parity Multi-Sig Attack
#627I'm not sure why everyone is piling on Solidity. At the end of the day, bugs happen in all languages, to all programmers eventually, and if you want to point the finger, it has to be at Parity. If anything, it shows there needs to be a better process for peer review and some defaults in Solidity should be changed for security.
It's because even creating Solidity was a choice; why not use a more established language with a well understood vm?
Re: 153k Ether Stolen in Parity Multi-Sig Attack
#628Earlier quoted context omitted.
This is somehow the top comment, but doesn't deal with the issue at hand. In fact it entirely ignores it. The theft wasn't due to an issue in the core protocol of Ethereum, it's due to faulty code in a single piece of software (as you can see throughout the rest of the thread). It's a matter of poor engineering practices, not a flaw in the fundamentals of the protocol. If an engineer designed a bridge, and it failed…
I have zero domain expertise in cryptocurrencies or Ethereum, but much experience with unexpected failures of "guaranteed" things and processes. To use your analogy - I'd view the bridge design engineer as having guaranteed that the design process could not possibly result in construction of a bridge that fails. That seems closer to what Ethereum would have us believe. A bridge design domain expert presumably underst…
In your description I still take away that the root problem isn't in the technology, but in the engineer's implementation. Even a calculation that is guaranteed to produce the correct results [if implemented poorly or with errors or with exclusions] can fail.
The engineer who wrote the contract appears to have made a critical logical error.
That does bring me to your conclusion, though. I've paid less attention to the marketing and promises and have assessed the technology as-is (within the confines of my knowledge) -- as such I see what's possible instead of seeing it as a product that under-delivers.
I wonder if a lot of people (especially on HN) would view it differently if it weren't for such bold claims on the developers' part. I mean, I think you're probably right in it being naive in its guarantee of predictability. I think any actors on the platform should assume its supposedly perfectly predictable behaviour is not quite so when they take to designing software or a contract. But that's part of what I meant when I've said it comes down to engineering practice -- when it comes to critical systems assumptions just shouldn't be made in young technology no matter what anybody tries to sell you.
Re: 153k Ether Stolen in Parity Multi-Sig Attack
#629Earlier 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.
Things are not always simpler at a lower level of abstraction.
Re: 153k Ether Stolen in Parity Multi-Sig Attack
#630Earlier 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.
You might be interested in W7, an object-capability Scheme variant: http://mumble.net/~jar/pubs/secureos/secureos.html
Starting from something like the lambda-calculus seems more sensible than starting from something like Javascript.