Earlier quoted context omitted.
"Solidity" is a pretty sarcastic name for the language at this point :)
Did you mean "ironic"?
Perhaps both :)
153k Ether Stolen in Parity Multi-Sig Attack
531–540 of 754 posts
Re: 153k Ether Stolen in Parity Multi-Sig Attack
#532Didn't they fork the project a while ago due to theft?
Re: 153k Ether Stolen in Parity Multi-Sig Attack
#533Earlier quoted context omitted.
> do things that are technically allowed, but have unexpected downsides Unexpected downsides for whom? Smart contracts cease to be smart if we have to rely not on the VM but on a small group of human overlords. If a smart contract exists and you don't know clearly how many times it has been used and what percentage of the parties who used it are pleased with its functioning, you really should not use it unless you fe…
> 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…
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 herring.
The Parity multisig attack was an extremely simple programming error that has nothing to do with Turing completeness.
That people put their trust in such a contract despite its source code being obviously wrong points to the real problem.
The real problem right now is the lack of convenient tools and established practices for formal verification. If you think formal verification is impossible for EVM, you're wrong and you fundamentally misunderstand computation.
I've seen this criticism over and over again on internet forums: "EVM is so stupid, it can't be formally verified because it's Turing complete."
It's totally wrong: EVM isn't Turing complete, and it doesn't matter.
Look at "The Art of Computer Programming." It's full of Knuth's proofs of the correctness of algorithms written in assembler and imperative code. Look at any proof of correctness of a sorting algorithm.
OBVIOUSLY you can prove the correctness of programs written in Turing complete languages. You just look at the specification of the language, formulate a specification of your program's intended behavior, and then prove that the code matches the specification. This is how formal verification works, regardless of Turing-completeness.
To clarify, what is the impact of Turing completeness on formal verification? It means that for some ARBITRARY program, you cannot ALWAYS prove that it halts.
But even with some non-Turing complete formalism, you obviously cannot automatically prove the correctness of an arbitrary program; that's just nonsense. You could be certain that the program halts, sure, but how valuable is that? Ethereum already guarantees that all programs halt using the very simple gas mechanism.
Re: 153k Ether Stolen in Parity Multi-Sig Attack
#534Just 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…
This is an amazing write up. How long did you spend in the code before jotting this down?
I was literally writing this list down as I was reading through this:
https://solidity.readthedocs.io/en/develop/solidity-in-depth...
Re: 153k Ether Stolen in Parity Multi-Sig Attack
#535Earlier quoted context omitted.
> That $10m out the window is like a Series A for a nefarious hacker with deep crypto skills [..] Where "deep crypto skills" refers to someone who bothered to read the documentation on Solidity (the Ethereum contract language), specifically the section on function visibility[1], and the Parity wallet contract itself[2]. In other words, an obscure security hole was not found by a genius hacker. An obvious, trivial, si…
because the people investing money in it provably didn't know what they're were doing. Very true – the price hasn't really moved in response to this news, which makes very little sense to me. I'd be shorting if I could figure out how.
Would you short the US dollar because one small bank got robbed due to bad security? The flaw here was not with Ethereum, it was with the wallet developer.
Re: 153k Ether Stolen in Parity Multi-Sig Attack
#536Earlier quoted context omitted.
> Basically, if 51% of the network think you have too much money, they can just take it from you with no recourse available. That's not how it works. Even if you had 99.99% of the hash rate, you still have to work within the rules of the chain, so a "give me your money" without a valid signature would still be rejected as invalid by every full node (and you just wasted your hashing power). What having 51% or more of…
It seems to me that large blockchains^ are some of the most stable social structures in existence. The rules of Bitcoin have been in place for 8 years with only minor modifications, despite huge sums of money passing through the system. This compares very favourably with other social structures, such as nation states, especially 8 year old nation states. ^ Large as in Bitcoin and Ethereum, smaller networks are much e…
> It seems to me that large blockchains^ are some of the most stable social structures in existence. The rules of Bitcoin have been in place for 8 years
Indeed. Makes the Swiss federation and the King James Bible look quaint doesn't it.
Re: 153k Ether Stolen in Parity Multi-Sig Attack
#537Just 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…
Maybe they should have restricted their memory access model by using a stackbased language like Postscript.
Re: 153k Ether Stolen in Parity Multi-Sig Attack
#538Earlier quoted context omitted.
The real lesson is: don't store your coins on a third party anything . This was a third-party wallet. Everyone used it because everyone else used it. Exactly like Mt Gox. There was no reason to store coins on Mt Gox, just like there was no reason to use this wallet. A moment's reflection would have prevented this foolish decision.
Parity does not appear to be an online service. It's local.
It runs on a distributed cloud VM actually (Ethereum).
So the rule applies: don't trust online services with your money, especially if you didn't write the code.
Re: 153k Ether Stolen in Parity Multi-Sig Attack
#539I 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
Re: 153k Ether Stolen in Parity Multi-Sig Attack
#540Just 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?
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.