So here's what happened: Parity used to have a normal multisig wallet, where every user deploys their own contract and each one is a full copy of the code.
They decided it'd be nice if people could have a lower transaction fee when they deployed a new wallet. So they made one master contract that has all the code. Now when you deploy a new wallet, what you actually deploy is a stub that forwards function calls to the master contract, using a "delegatecall" which lets the master execute its functions in the context of the stub contract.
However, they didn't think through how they might want to change the master contract code in this new situation. In particular, they didn't remove the selfdestruct function. Self destruct is perfectly sensible when it's your own contract that you're not using anymore, but it's not so great when it's shared code used by lots of people.
They also forgot to initialize a function setting contract ownership. Someone came along and made themselves the owner, then called the selfdestruct. They posted about it on github, apparently unaware of the full impact of what they'd just done, which was to destroy the code used by all the stub contracts deployed since July 20. Now those stubs no longer have access to functions for withdrawing the ETH they contain.
This master/stub design was also the root cause of Parity's previous multisig hack. Apparently they didn't get a clue and pay for a fresh round of external audits, which I think would have easily caught this problem. In fact, at the end of a post-mortem of the previous hack, published on July 20, they complained that they lacked funds for such things:
In an enterprise or company, when it is growing from startup to market gorilla, there are often tales of screw ups like this that happened to some poor sysadmin or programmer. And the company develops a sort of genetic memory of what not to do. Like children, companies that learn the 'dangerous' things early before they can do real harm, grow up to be less likely to do something really stupid later in their existence.
But I don't know what vector could be used to pass this sort of cultural knowledge between ethereum contract writers from generation to generation. It needs a 'book of sins' that everyone can read and contribute to in order to insure that new contracts won't suffer the problems of the early ones.
In the "Known Attacks" section, they advocate using a mutex to prevent reentrant situations, but they're using a boolean, setting it to true before the operation and setting it to false afterwards. This is not secure -- it's possible for two threads to set it to true at the same time! You need to use an atomic concurrency operation like compare-and-swap [1] to implement a mutex.
That looks like it is headed in the right direction. I observe that in companies there are stories (often with particpant's names) which exemplify bad practices. Part of the motivation to do better seems to come from not wanting to be the person in one of these stories.
Back in the dual floppy drive days, I vividly remember getting the diskcopy a: b: right but accidentally placed the blank in a:.
I vividly remember doing it a second time some months later. But never again.
In my defense I was an idiot and was 8 or 9 years old, so fortunately it was just some shareware game disk that I was trying to copy for a friend only to lose my only copy.
The error made here is in an enormously more complex domain, but kind feels like they just accidentally low-level formatted an important diskette.
Yeah, I guess we all learned to write-protect the floppies the hard way... When you lose data you become a bit more paranoid about making mistakes. Fortunatelly floppies could be protected with a bit of tape.
I never understood why you would ever write-protect a floppy. Then again, I had a Mac 512k with a single floppy drive. (Insert Disk A; CRANK WHIRR GRIND SPIT; Insert Disk B; WHIRR WHIRR CRANK GRIND SPIT; Insert Disk A...)
I don't do ethereum audits but isn't the right thing to do here is to write your own wallet contract and have someone audit it? geeezzz people storing 10M$ ethers.. This is the analogous to the case of storing 1 million dollars in a vault with a 1$ lock.
I'd rather use a contract that has been around for a while storing major funds, which has several public, current audits. The Ethereum Foundation has a multisig which has been holding their funds for years, that's probably a good choice. Parity's audit was done before they made a major architectural change.
I do think there's a need for a much simpler standard multisig than the ones being used now.
That requires getting an ed25519 implementation in there with the ability to multisig into contracts. That's what a standard would be if there was to be one.
By "simpler multisig" I just meant a normal multisig contract with less functionality, where the keys still separately call contract functions and update state.
True multisig transactions like you're talking about are supposed to become possible with the next Ethereum upgrade.
Thank you for that.
Just to make one thing clear, the person who destroyed the contract was after people's money.
He posted a list of contract addresses in the github issue, most of them look like ICO wallets, with a transaction made the time before he destroyed the contract. The transaction was from him to his wallet trying to drain the wallets. After he failed to he went to the destroy function thinking it will propagate to the wallets and moving the funds to him ( this part is just a theory ) or he is just a jerk who wanted to see the world burn.
Frankly, the fact whether or not it was malicious doesn't matter. The original developers fucked up, and there is no genuine excuse for that (regardless of the fact whether or not he was able to steal those funds).
This probably could have been fixed with basic testing.
Just look at all the companies like Microsoft or Apple with millions to spare, or massive community efforts like Linux kernel, either with no shortage of means and resources to make their systems resistant to simple programming bugs.
But history clearly shows that no amount of processes, audits, static analysis or eyepairs help: bugs just keep on being found where ever security folks look for them, and the harder they look, the more they find. Upside is, these systems can be patched, which is comforting as clearly there just is no bug-free code.
Yet, people keep on pouring millions of dollars worth of virtual tokens to these experimental blockchain systems that are fundamentally designed so that any bug of certain class means the money is forever, irreversibly lost - as if these crypto contracts were some mythical new breed of software written by infallible Gods.
The saving grace of Ethereum contracts is that they're very short. Many are under a thousand lines of code, so it's not crazy expensive to pay expert auditors to review every line. It also looks like an ideal use of formal verification techniques, and there's a lot of work going into making that practical. Plus you can keep things a lot safer by writing your contracts in the simplest, most obviously-correct way possible.
The fact that you can do these things doesn't save you from people who don't. Parity's last audit happened before they made a major architectural change; if they'd gotten new audits this probably would have been caught. They also have the most complex wallet code I've seen, often dipping into assembly.
It's true that you can't be completely sure of avoiding bugs, but with decent practices I think it's less of a problem on Ethereum that it is in medical equipment, airliners, and nuclear reactors.
It's kind of like, do you think it's humanly possible to correctly encode the rules of chess in, say, 6502 assembly?
You probably won't do it on the first try. And you wouldn't immediately bet a million dollar on it. But is it possible?
Yes.
A multisig wallet shouldn't be more complicated.
Could you prove the correctness of the 6502 chess? Sure. Formal methods are not black magic. You need a semantics of the machine and a formalization of the rules.
Can you make mistakes in specifying? Yeah, duh. So combine it with peer review and throw in a bug bounty and fuzzing.
Chess is a nice example in this analogy because there are rules that people are less familiar with and might well forget about or implement incorrectly. For example, the complete castling rules are not trivial, like with the king not passing through a square currently attacked by an opposing piece
(Implementing the threefold repetition rule requires maintaining historical state of a different kind than any other chess rule!)
I've seen impressive hyperminimalist chess implementations that were missing these things, but that totally felt like real chess almost all of the time.
There are also some really obscure rules that came about to prevent what you might call exploits. For example, it had to be clarified that you’re not allowed to castle vertically (this could happen if you promoted the king’s pawn to a rook) and that you’re not allowed to promote pawns to a piece of your opponent’s color.
A perfect chess implementation from before those rule changes would no longer be correct!
It’s possible to prove that code perfectly implements a formal spec. It’s tough to prove that the formal spec perfectly describes what you want it to describe.
Actually easy. With any automated theorem prover you will get requests for additional proofs if any ambiguity or missing info is detected.
This is a very strong if. It means the rule cannot be reduced in plain logic.
The example of forward castling rule is a good one.
A missing definition of some en passant situations is caught too. (E.g. situations of check.)
Completely missing rule cannot be caught with these techniques.
You also need to ask the prover right questions.
Say: when does a chess game end. Proof requires proving the existence of a halting Oracle for any game state. Not quite easy but possible. To actually verify, you will have to provide reduction rules unless you happen to own a supercluster.
There is a way, reforming everything as an automatic math proof. Because even security is driven by capitalism sort term gains almost nobody does this.
This is why Rust is so promising. The problem at Apple / MS / Linux / etc is they are massive houses built on bare foundations. Everything traces its roots back to C, and back to exploitative vulnerabilities in the code. Rust itself is not close to safe since it depends on LLVM which itself can be a source of myriad bugs related to C++.
But its proving in my experience to be a much more practical foundation, and going forward there is a lot of value in that.
this isn't a code error -- it's a logic error. No amount of "safeness" in the language will save you from telling the language, without breaking the rules, from doing something that is "wrong".
For instance:
sudo rm -rf /
Every part of that is completely sound and correct. There are no buffer overflows, emory corruption, or anything. You wrote a completely correct command to do something (probably) really wrong.
>This is preventable if you specify fully what you actually want to do.
In this case it was fully specified that sudo should run rm with all privileges, which in turn will recursively deleted the root filesystem.
The entire execution is fully specified and will execute without fault. There is no mistake in `sudo rm -rf /`.
Logical faults may not be preventable with provers, such as when underlying assumptions are wrong.
For example, a prover could have verified the parity library as fully okay because it assumes that the initialization function will not be called without delegation. This underlying assumption X -!> Y (X cannot lead to Y) is wrong and X -> Y is the case but the prover only verified that Y -!> X.
Provers essentially duplicate your code, forcing you to express the solution and/or problem twice such that if you basically typo on the way, one of the pieces will complain about the other.
But it cannot and is incapable of preventing higher level mistakes.
Better languages can help to avoid certain classes of errors, but won't prevent bugs in the business logic of your code, so I'm not sure how this is relevant to contracts.
We do occasionally run into bugs between Rust and C++ semantics with LLVM, but they’ve been pretty minor, and LLVM has largely fixed them, to the point of adding instrinsincs to fix these issues.
Bugs happen no matter the language, even if LLVM was in Rust it would have them.
Has there ever once been a critical llvm vulnerability? I've seen the occasional bugs related to it, but they tend to crash the compiler rather than produce bad binaries, no?
Security-related compiler bugs very rare, but they do exist, at least in graphics shader compilers: http://www.doc.ic.ac.uk/~afd/homepages/papers/pdfs/2017/OOPS... . My impression is that many of these shader compilers are based on LLVM, but this is mostly conjecture. (I do recall a video game crashing on me with internal LLVM errors from the graphics driver.)
He claimed he tried it, thinking it can't go through. And it seems plausible, since you he was researching similar attacks from the past.
He had no reason to make the github issue afterwards, if he was a blackhat who knew what he was doing. His entire presentation doesn't seem like that. (Or even like "someone who is trying for no real reason to try to look innocent". He didn't have to be public at all.)
Just to make one thing clear, you're just assuming. The guy clearly stated that he just tried out different things and never really intended to steal something. If you give out an API make sure that I can't break it by calling it, otherwise it's your fault not mine. The guy seemed also pretty nervous in the gitter channel, he asked if he really broke something and if he gets arrested.
It's pretty bad when the type of wallet that is supposed to be more secure has bugs like this multiple times. For reference, this only affects multi-signature wallets, not normal wallets. Very few normal users use multi-signature wallets.
The previous bug with these was very trivial and could have been caught by a unit test or a simple code review, and it resulted in around 9 figures (USD) of Ether being stolen.
This bug looks like it's exactly the same. A very simple bug that could have been caught by a simple test or manual audit, and has resulted in 9 figures USD being locked instead of stolen this time.
As mentioned by others it's possible at some point (not any time soon) that this frozen ETH can be recovered (https://github.com/ethereum/EIPs/issues/156) by adding rules to recover it in the next Ethereum hard fork. Not creating a specific hard fork just for this, but adding it to one that is planned in the future. That might come across as controversial, and cannot be guaranteed though.
For safely storing Ethereum I would advise to keep it out of smart contracts, period. Cold storage and hardware wallets exist, and they are much less likely to have critical bugs related to them than a smart contract is.
There will probably be a hardfork and increased moral hazard for auditing contract code. Why spend money finding bugs if the "immutable" blockchain can be rolled back?
Well, "traditional" law can be changed as well, so I'm not sure why a blockchain should not be able to. Some changes are more controversial than others, but in the end the majority (more or less) decides. Either by vote in congress/senate, or by users picking a particular client/chain.
Ethereum has had one particularly controversial fork, and so did Bitcoin. In both cases, both chains survived, with one significantly more popular than the other (in both hash rate, transactions, and market cap). (Un)fortunately, traditional law in real life does not permit two realities to coexist, so there the analogy falls apart somewhat.
Well, national currencies do get "forked"[1], but this would be like if they did extremely narrow forks to fix problems of someone's own stupidity, and only the stupidity of the most important people.
Like, imagine if twenty members of congress kept their life savings in cash in uninsured briefcases and surprise, those briefcases were stolen. And they responded by passing emergency legislation invalidating the specific serial numbers stolen, and requiring every merchant and bank to screen for those serial numbers (and not those from any other e.g. bank robbery).
I would consider that kind of action to be very delegitimizing to the currency.
[1] I would consider it to be analogous to a fork when they e.g. deprecate an old design or migrate to the Euro.
Well blockchains work by consensus is the difference: the rules can only be changed if enough people agree. This sounds better in principle but breaks down using proof of work when a small number of parties control most of the computing power.
Once again, this is supposed to be better than, and different from, "traditional" law! It has no purpose if the contracts don't actually do what they say. The whole point is that computers evaluate the contracts and do what they say.
As seanwilson says above, blockchains work by consensus. Leaving aside the "better", that does mean it is different. The instructions are still executed by computers as it was programmed as you say, but if enough users/miners agree this was not the intention of the contract/code, they can fork.
I do think that calling blockchains "immutable" can be confusing to users not familiar with the concept and its nuances. And I personally hold no opinion on whether the currently locked up funds need to be returned to their owner with a fork. There is something to be said for both options, specifically in this case where there the "rightful owner" is clear (like the other cases mentioned in https://github.com/ethereum/EIPs/issues/156 ).
I don’t know if probably is the right word. There might be a hard fork there might not. The DAO hack was only three months after the Homestead release. You could credibly say Ethereum was in beta. I think over a year later that’s no longer true.
At the time of the DAO hack there also hadn’t been a public demonstration of the scale and danger of contract hacking. That’s also no longer true.
That said, ETH is an anarchist federation in the end, and the market will decide which reality is most valuable: the one in which the parity hack happened or the one in which it didn’t.
Pact (http://github.com/kadena-io/pact) is a turing-incomplete LISP (no recursion, no lambdas, no unbounded loops ... no macros either ;) ) and built in Haskell. Also has formal verification by directly compiling to SMT-LIB2 (not released yet, but watch a demo! https://youtu.be/l7XuSuEe-Yg?t=22m23s).
Does this move the bugs from the implementation language to the language of the verification spec? Or is there a way to express some generic requirements such as "don't strand assets"?
Presumably one would have to first formalize that constraint (taking care, for example, that 'not stranded' is not being satisfied by someone stealing the assets), and then, unless the language makes it impossible, prove that it is not violated anywhere. In Solidity, it is a long deductive chain from the specific bug here to the realization that it could lead to stranding.
Https://cardanohub.org looks promising. Haskell, peer reviewed, formally verified. They're working on the compute layer though, so no smart contracts yet but Philip Wadler (one of the godfathers of haskell) is working on that. It's is promising because they actually hire programming language academics to work on the technology
Parity appears to have a bug bounty program, but the bounty is only $100. Given that they've now had two bugs that caused 9-figure losses in the past year, this is clearly too low. They need real auditing, and they need to pay the market price for real auditing.
You are right, but unfortunately, the de-facto bug bounty for unethical hackers is way beyond anything that could be offered to well-intentioned researchers. This makes your suggestion of professional auditing the highest priority.
bug bounties don't compete with crime. crime always will pay more.
bug bounties compete among themselves. Honest researchers will be busy finding some mobile game bugs for $700 a pop or improving security at google or yahoo for up to $10k instead of helping your company save from a 9 figure bug because you only offer $100
I wondered why you didn't mention the maximum, and after checking their website found no other figures besides the $100 minimum.
They do state "Rewards over the minimum are at our discretion, but we will pay significantly more for particularly serious issues, i.e. that the identified issue could put a significant number of users at risk of severe damage, monetary or otherwise."
What they consider significant is anyone's guess. Given the stakes, even a 10000% increase would still be underwhelming for a high impact bug.
Being coy about what they will pay is not going to have the desired effect of attracting bug hunters - it's kind of like Dr. Strangelove: "The whole point of the doomsday machine is lost...if you keep it a secret!"
It's mind boggling that a company like this "doesn't have the funds" for proper security auditing, and treats code updates like they were changing CSS for their blog, yet at the same time can affect $200m+ in funds. Why are they not making money, and in that case, why on earth is so much cash entrusted to an underfunded entity?
EDIT: apparently one of the wallets affected holds $90 million raised for the Polkadot project [1,2], which is their own. A quote from the previous incident[3]:
> Unfortunately, since Parity is a small, minimally-funded start-up, we have not the resources to do this alone. Outside of a few tips to the shoe fund, Parity has received no funding whatsoever from any organisations within the Ethereum ecosystem.
A few months ago as a newcomer to Ethereum, I looked into Solidity and concluded that due to the poor design of the language, large-scale problems like this would be inevitable. I decided not to invest in ETH. In my opinion, smart contracts are a good idea, but smart contracts written in Solidity are a bad idea.
The issue in this case isn't so much Solidity, as Parity getting too fancy with their code. If you look at the wallet stub contract it's half assembly.
They did a good job optimizing the contract to use minimal gas upon deployment, but maybe that's not the best thing to optimize for contracts that will hold millions of dollars. They also don't appear to have gotten fresh external audits when they made changes.
Incidentally, there are other Ethereum languages in development that are better suited for formal verification, including Viper and Bamboo.
If I do a git clone of the parity github and deploy the multisig wallet, how much will it cost versus just using the stub/delegatecall architecture that's being used by everyone?
I haven't checked but these contracts aren't huge and gas prices are low if you don't mind waiting a couple minutes. I think you could post it for a couple bucks.
(I also think you'd be better off using a different wallet entirely; Parity's isn't the most popular anyway, especially lately.)
Some of those points are good, others are nonsense. In particular:
1) There's no need for a garbage collector, because there's very limited computation within each transaction, and complete cleanup of non-permanent storage after each one.
2) The author doesn't appear to realize that the list of mis-compilation bugs is a list of fixed bugs. The list is only available in json because its purpose is just to let tools display warnings for obsolete compilers.
3) I have a hard time dreaming up an application that would need a string library in Solidity, because storage on chain is very expensive, and you only need to compute things on chain that require global consensus. Strings on chain are usually very short and static; for longer stuff we just store their hashes on chain and use client code to manipulate the strings.
That seems like it'd work, but I'm not sure what is gained by replacing Kickstarter with a smart contract (as opposed to replacing Kickstarter with a centralized alternative)
The advantage would be avoiding the 5% Kickstarter fee + (according to Wikipedia) 3% to 9% payment processor fees. The computation fees charged by the blockchain are presumably well below that. [On the other hand, maybe they aren't. Calling this suicide function on the Parity multi-sig wallet apparently cost 27 cents. If the crowdfunding contract is more complex, and submitting a payment costs, say, a dollar, then the average contribution would have to be on the order of 10 dollars to break even vs. Kickstarter.]
You can save the cost of Kickstarter by removing the value Kick-start adds. You get a smart contract that can't be executed because no one decides if the project delivered properly. How is that an improvement?
> no one decides if the project delivered properly
Same as Kickstarter. They release the funds to the creator after a certain deadline, after which they do not get involved in deciding whether the project delivered. Which is what I wrote above.
EDIT: I should add that I do very much agree with the general point you're not making: Smart contracts are only smart inside the closed world of the computer system running them; they don't magically know things about the "real world", and they cannot affect the "real world". I agree that many smart contract aficionados act as if they didn't understand this basic point. That's why I deliberately chose the Kickstarter example, which is also a system that does not make guarantees about the real world once payments have been made.
In this case, the smart contract aspect seems more like effective marketing rather than a technical advantage. This business could be operated identically with a centralized system.
Yeah it's definitely been done more for marketing but Axa's CEO is on record as saying he thinks the blockchain and smart contracts will have a lot of valid use cases in the insurance industry.
I suppose in this case the nice thing with the smart contract (assuming it works as advertised) is it's simple and verifiable. You know you'll get an instant payout if publicly available data shows your flight was delayed > 2 hours (regardless of reason). There's no human in the loop and no signed contract with weasel words that gets AXA off the hook from paying.
Sounds like a very roundabout way of doing things. I guess AXA feeds flight data onto the blockchain, you need to trust their data, and somehow pre-register the flights you are going to take with the contract?
I haven't used it but according to their FAQ, the smart contract uses publicly available flight data from multiple government sources to determine if a flight is delayed. The payout is based solely on that and the decision is out of Axa's hands (their website specifically says: payout regardless of reason for delay, including alien attack).
You can sign-up for the cover up to 15 days before departure. Apparently you input your flight number and credit card details. If the flight ends up being delayed more than 2 hours, their smart contract triggers an automatic payout to your card, no questions asked.
Me too. That was back when Ether was at $2-3. Either the market is very irrational, or it just doesn't matter that much, and people are willing to take the risk of stuff like this happening again and again.
> I looked into Solidity and concluded that due to the poor design of the language, large-scale problems like this would be inevitable.... In my opinion, smart contracts are a good idea, but smart contracts written in Solidity are a bad idea.
Yes, and it's sad that they continue to try to patch around and nibble at the problem. The foundation is borked, start over.
So I see this as a growing pain. But this is something that has already been thought of as something that could happen, and there is work looking into how to solve it going back a ways: https://github.com/ethereum/EIPs/issues/156
It looks like if this EIP is implemented in the future, the address that created the original multi-sig wallet contract created after July 20th, would just be sent the ether balance in the wallet. I'm not sure on this, but it seems like, if implemented in the future, an owner of a multi sig wallet that is frozen can call this contract from the same address they created the wallet with and it will retrieve the ether from the address where the contract is now blown away?
Another option would be during the next planned fork (upgrade), to just say, any contract that matches the byte code of the frozen wallet one, just replace the code with this code and move on. Although the first option is MUCH nicer and future proof.
People will write bad code and things like this will happen. I think the more often and earlier on we find these types of flaws and can fix them, the better for the whole ecosystem. It's $300 million today... in 10 years, a mistake like this that hasn't been worked out could cause a shock to the entire world economy. (run on the banks, but there are no banks and everyone's funds are frozen...panic!)
So better now than later!
Solidity needs to get rid of features like library and inheritance. If you write an unstoppable contract that is responsible for holding hundreds of millions of dollars, you alone should be responsible for it, and not some library you used.
Better yet, people who have the mindset that it's ok to have these hipster "modular" features that spread out the responsibility (for whose benefit?) should really not be working on such fundamental pieces of technology. If you write software that holds people's money and you fuck up, you and only you are responsible for it.
This is a recurring theme with the Ethereum community where people complain about how there was a bug in the system which resulted in a huge hack and people losing tons of money, and developers say "hey don't blame me I just used some library, it's the library's fault".
In this case the library was also written by Parity. They were trying to minimize the gas cost of deploying a new wallet, which imho doesn't seem like the best thing to worry about optimizing, for a contract that may hold millions of dollars.
Since contracts are immutable, you need modularity to be able to fix bugs like what happened with Parity. The problem is that Solidity libraries are also immutable, which means you can't fix them. The solution is easy: just use contract modules, not libraries.
Having modularity in these things only amplifies the damage when something DOES happen.
I'm not saying it is bad to have a centralized auditing of contracts, but I am saying it's not a good thing to simply import libraries and inherit some other abstract contract you don't fully understand when it comes to irreversible contracts.
This is a new type of problem we as a humanity have never faced before, so we need a different type of solution.
> This is a new type of problem we as a humanity have never faced before, so we need a different type of solution.
Could you elaborate on that? How is it a new problem? I would think it's similar to problems with hardware components or FPGA libraries, but maybe I'm missing something?
Crypto used to be a purely technological problem, which means if you have a secure cryptographic lock in your bank account and someone steals it from the bank, the bank is responsible to get it back to you.
But with cryptocurrencies, it's not just about technology but ties into other issues that normally have been tackled on a social level. So in this case there is no "bank" you can complain to or no one to sue.
Of course, you could say Ethereum as a whole can do a hard fork just for this, but that's another discussion altogether.
When people blamed Ethereum for being the cause of the DAO, the devs said it's not Ethereum's fault but the ones who wrote the DAO, which is technically true, which is why I'm making this point. It's not about technology, it's about responsibility.
Also, a while ago some guy complained about how he lost his money using myetherwallet, and the problem was NOT because of myetherwallet but a library they used. So the guy from myetherwallet told reddit that it's not their fault, which is again technically true, but again fits into what I'm talking about.
Dependency spreads out responsibility, which works out fine for traditional finance because everything is reversible, but not in this new economy.
The whole point of Ethereum is for people to be able to use custom contracts. People would be using Bitcoin if they only wanted to be able to use contracts by the Ethereum -- er, cryptocurrency developers.
Contracts in the real world are written with the understanding that they rest on the shoulders of millions of pages of legislature and legal precedents.
If they don't fork, everyone affected by this will lose all of their ETH.
Many would argue the correct thing to do is to not fork and say that people knew the risks beforehand, etc. But that's what people said last time and they still forked, with no (apparent) severe consequences other than complaining about integrity. Two forks may be harder to justify.
If they used a library instead of a contract, this wouldn't have been possible. I hope they had a reason to use a contract otherwise they clearly have noone else to blame this time.
>If they used a library instead of a contract, this wouldn't have been possible.
It's actually the opposite, using a library allowed this to break all the wallets using it. However, an Ethereum "library" isn't what you'd expect a software "library" to be - it's an executable contract that just is never supposed to be executed directly. But oops, nothing prevented that from happening.
The concept of everyone using a common, well-audited contract makes sense though. Virtually all Bitcoin multisignature transactions use the same script construction and it has never been hacked, despite being much older.
For something as important as contract code, there should still have been more failsafes. Even just having a kill() on the main contract that doesn't delegate out to the library would have protected against this.
> The concept of everyone using a common, well-audited contract makes sense though.
Just Parity's contract was neither common nor well audited.
> Virtually all Bitcoin multisignature transactions use the same script construction and it has never been hacked, despite being much older.
The only multi-sig issue that I'm aware of in Bitcoin was the Bitfinex hack but I don't know in what relation BitGo's multi-sig implementation is to the standard multi-sig.
The EF multi-sig implementation has been audited and AFAIK there has also never been an issue with it.
The Bitfinex hack was due to getting enough parties of the multiparty signature to sign it (e.g. by stealing 2 out of 3 keys, or taking advantage of insufficiently secure automatic signing systems), not an issue with the contract itself.
Not to mention that he wrote the buggy contract...ehm, both buggy contracts, to be precise, the one that let funds be stolen and the one that now freezes funds...
FYI this is not the reason Ethereum failed as a blockchain. Security bugs are bad, but what's worse is 9GB/week bandwidth requirement = 3 hours sync on average world connection, if you're lucky.
No idea why everyone ignores this metric. And that's why Bitcoin is still somewhat blockchain (also poor sync, but doable)
It is not 9GB/week. The 9 GB is the tx data plus the state at every block. You don't need the copy of the state at every block. The latest state is perfectly sufficient. More indepth explanation:
You seem to be right! That doesn't dramatically change the problem, but with avg blocksize 13Kb https://etherscan.io/chart/blocksize multiply 6000 blocks per day the data to download per week is just 700Mb, am I right? I wonder why the wallet syncs so slowly then.
Eventually other solutions will be needed, like sharding. One solution for the never ending growth of spent transaction and block header data is snapshots. Practically, you can safely not validate tx data older than X, if X is a sufficient length of time.
A solution for neverending state size growth is storage rent with pruning of entries that default on rent payment.
Isn't sharding major compromise on security? I thought snapshots mean you just download the exact state at block X and never bother about tx older than X. And you do that not because of time, but because at the point of installing of blockchains you already trust _someone_ with node software, so you should also trust with latest state (and treat it just like genesis block).
Speaking of storage tax, Ethereum should have implemented one like yesterday.
Apologies, I misread what you wrote. I thought it was 6,000 blocks a week. I also misread that as 13 KB per block header, though that mistake didn't change the calculation.
If the average block size is 13 KB, then there should be 546 MB added per week (13 KB / block * 6000 blocks / day * 7 days / week).
I don't know enough about sharding to offer an informed opinion on it, though I imagine the security compromises are tolerable.
With regard to a snapshot, yes that is one way they're used. I was suggesting that archival nodes could even rely on snapshots to cap their storage requirements.
It would be perfect to make a snapshot whenever a blockchain to last state is taking over 20% of state size. I.e. with 10 GB state do it every 2Gb (monthly). And IMO it's safe to discard any chain older than 3-6 months because only people who were offline for that long would ever need them (unrealistic)
That's like counting a mentions in Google Trends. Number of non-mining nodes is quite irrelevant to security or usability of the network. People install it to play around somewhere in the cloud.
3 hours of sync per week is not as bad as you might think. A week has 168 hours, which means you'll spend a minute per hour syncing on average.
Additionally, Ethereum, unlike Bitcoin, does not want everyone to run a full node, you can certainly run Archival nodes, but most people should be using light clients or nodes which do not store the full history of the chain (only recent history)
> A week has 168 hours, which means you'll spend a minute per hour syncing on average.
Assuming, the user wants to have a daemon running full time. They just downloaded your thing and you're imposing your rules? Deleted.
> Additionally, Ethereum, unlike Bitcoin, does not want everyone to run a full node
To me a full node is the one that verified every single block since the install point. (Not from genesis, a snapshot is fine). I'm strongly against archiving the blocks for normal users, only the state should be stored.
Certificate validation don't involve UX friction. I need this friction to be justified, and it the sync is very slow new comers will never bother to be a full node. Give people instant sync, and they won't consider light wallets anymore = greater overall security, ready for any censorship.
9GB/week is not huge at all, and ethereum nodes are not designed to be run on "average world connection". The only people running full nodes realistically should be on extremely fast connections.
Bandwidth and storage are only getting cheaper
Also "Ethereum failed as a blockchain"? They're the 2nd largest coin after bitcoin, it can hardly be called failed
You may have a point about the space but don't resort to insults like the last sentence. I think you also have a lot to prove when saying Ethereum has failed v Bitcoin.
It means it's gone, if the contract is followed. But a hardfork of Ethereum could change the rules to recover the coins.
A similar recovery already happened once, after somebody exploited a bug in The DAO, resulting in a fork into Ethereum and Ethereum Classic, which rejected changing the rules to bail out bugged but too-big-to-fail smart contracts.
> In May of 2016, a venture capital fund called The DAO built on Ethereum raised around $168 million, with the intention of investing in projects using smart contracts. In the same month a paper was released detailing security vulnerabilities with The DAO that could allow ether to be stolen. In June, 3.6 million Ether (approximately $50 million USD) was taken from accounts in The DAO and moved to another account without the owners' consent, exploiting one of the vulnerabilities that had been raised in May. Members of The DAO and the Ethereum community debated what actions, if any, should occur to resolve the situation. A vote occurred and in July 2016 it was decided to implement a hard fork in the Ethereum code and to move the Ether taken in the exploit to a new smart contract through which it would be restored to the owners from whom it had been taken.
> Ethereum Classic came into existence when some members of the Ethereum community rejected the hard fork on the grounds of "immutability", the principle that the blockchain cannot be changed, and decided to keep using the unforked version of Ethereum.
Can someone break down how funds have been frozen and what the bug that's being exploited is for those less familiar with Ethereum?
From what I've read about Ethereum's contract language, it doesn't make itself easy to statically verify properties you want to check so I don't see how problems like this are going to go away until another language is used.
The parity wallet uses a "shared library" in which the actual logic is implemented. All individual wallets have their own data storages and coin balances, but contain just a little bit of logic code that redirects calls to this shared codebase.
This shared library itself is also just a contract, except that it's intended to be called internally by other contracts (the different wallets). Though it typically doesn't happen, it can be called directly by humans. This is what the makers of this "shared library" apparently forgot to consider, until somebody called the "initialization function" of the shared library directly.
By doing this, the shared library initialized itself as if it was one of the individual wallets that normally call the library. It therefore used its own (previously unused) data store, in which it correctly entered the caller of the init function as owner.
This wasn't of use for anything, as there are no ethers at all on the shared library, so the owner could not steal any funds. But being the owner, he was able to trigger the kill switch! Since this particular "multisig wallet" was actually not a wallet, but the shared library, killing it not only killed the (empty) wallet, but also the core functionality of all the real wallets that contain real money out there! And of course that functionality is mandatory to work with the funds of these wallets. Without it, the money cannot be moved anywhere.
Now comes the fun part: suiciding a contract normally transfers all ethers on that contract to the caller of the suicide function. Knowing this, you could expect that the individual wallet owners could just as easily suicide their now "brain-dead" multisig wallets as well, thereby recovering their funds...but that doesn't work, as performing the suicide requires a call to the shared library to check whether the callers' signatures qualify the caller to perform that suicide ;-)
Awesome, thanks for the breakdown! So this is like a function being "public" when it should have been "private"? Would this be helped by making all functions more restrictive by default? What else would help? You'd think code that could change the owner would be heavily audited as well.
This sounds really similar to the big Ethereum wallet hack from earlier this year.
Everything in the "library" was "OK" the problem was that the person who deployed the contract to the main network forgot to call the constructor function.
The guy who killed the contract was the first one to initiate the contract.
My wife once left the car running and went to buy gum in a drug store, the car wasn't their when she got back.
Shit happens I guess.
No, this function (the init function) was public for a reason - it must be callable by anyone, since it's the thing you call when you want to create a new wallet! And the kill functionality has been non-public, it required the caller to be the wallet owner - which the guy who triggered all of this unfortunately was, due to him being the first who initialized the "shared library" as a wallet.
I would say there are many ways to look at this with regard of "what went wrong":
- You could say that it's a very, very bad idea to share ANY code between individual wallets which - from a functional standpoint - should not have any intersections between them whatsoever (except of using the same blockchain of course). Individual wallets are DESIGNED to fully isolate the contained tokens and state from each other, so why not also fully isolate their code by duplicating it? Is saving a bit of gas on wallet creation actually worth the additional complexity that comes with code sharing? Seems like someone took the "DRY" principle to a very unhealthy extreme here.
- Apparently the explicit construct of libraries described here (http://solidity.readthedocs.io/en/develop/contracts.html#lib...) is not very well-known in the Ethereum community. I did not know about it (someone here on HN pointed me to it), and while this is understandable considering that I have just a tiny stake in ETH and don't write Ethereum contracts for a living, the fact that Gavin Wood - co-creator of Ethereum - did apparently also not know about it (or for some reason decided not to use it for this library, which would be equally concerning, because if it's not usable for a textbook example like this, it must be seriously flawed) should cause a bit of head-shrugging. Because according to the docs, this construct delivers a crucial limitation with which this entire drama would have been impossible: libraries don't need their own state! So it's just consequential to not allow them to have any state (like an owner, or ETH funds), which apparently is exactly what the library construct does.
- Maybe this incident is just another bit of proof to the theory that the combination of immutability, handling of huge monetary values without any human oversight at all, and the idea of a Turing-complete language just don't mingle together very well. If you're not able to manually interfere in case stuff goes wrong in a way you didn't anticipate, you need to be able to basically anticipate absolutely all ways in which stuff can go wrong beforehand. A Turing-complete language seriously complicates doing this, possibly to an extent that kicks the entire concept beyond the realm of practicability. If this turns out to be true, the entire value proposition of Ethereum would be void right from the beginning.
Didn't they fuck it up by creating a real contract instead of a library (where you can only do delegatecalls)? And having an init function that was not the constructor as well?
Solidity is, I think, the fourth high-level language created for Ethereum. This is not a problem that it is going to be fixed with just yet another language: if Ethereum is going to live up to the expectations for it, it will require formal verification at a scale never before done, both in terms of the languages and other tools needed, and in terms of the skills needed to produce verified contract code.
I don't think it will require formal verification per se.
Rather, formal verification is just one piece in the puzzle. The software responsible for contracts in Ethereum needs to be equally well and thoroughly developed as if it was sending people to the Moon in the 60s or to Mars in the current Decade.
It'll probably take blood, sweat, money and mistakes just like in many other disciplines but we'll get there.
Depending on who you read, the expectations for Ethereum go all the way up to replacing banking systems, if not beyond, so there does not need to be any problem specific to Ethereum for there to be concerns about the practicality of its verification, though the fact that it is not a well-defined problem domain is itself an issue. Do you have a more restricted expectation of Ethereum's usefulness that implies no more difficulty than the largest formally-verified project that you are aware of? Update: the lower reasonable bound on Ethereum's complexity / usefulness is that it should enable something useful beyond what can be done with Bitcoin, or any other blockchain-based system lacking Turing-complete contracts.
Why would how useful Ethereum is or could be make a difference? Formal verification has been researched for decades and applied to complex domains like operating systems, hardware, smartcards and huge mathematical proofs already. I don't see why applying it to Ethereum would be a giant leap.
We may have a misunderstanding about formality here. While the mere use of defined software development processes has sometimes informally (and confusingly) been called formal, it really isn't. True formal methods involve developing proofs of correctness along with programs, or at least proofs of the absence of certain types of error.
Work on this has indeed been going on for decades, and its very limited adoption so far is a testament to its difficulty. Only a tiny fraction of the code in the domains you mention is formally verified, and I notice that banking and finance are not on your list. The answer to "why would how useful Ethereum is or could be make a difference?" is that if Ethereum becomes as useful and important as intended, the size and scope of the problem will be well beyond anything that has been achieved so far. Arguably, given the value at risk, it has already crossed that threshold by a wide margin.
There are, however, people working on it, such as at Cardano [1], which is an exciting development. Ultimately, I think it will be more successful than trying to fix Ethereum.
If you don't have experience writing formally-verified code, I suggest the F* tutorial [2].
Solidity is garbage. There is a ton of space for improvement between Solidity and even a solid programming language, let alone a formally verified system.
This might sound mean, but I laugh every time I see Ethereum bugs in the headlines. The developers intentionally made their platform analytically intractable, despite knowing the dangers this presents given our long history of vulnerable software.
They then compounded this poor choice with an Ethereum programming language with poor and insecure semantics.
I applaud the ambition behind Ethereum, but not it's technical choices.
This. It reminds me of PHP in many aspects - Solidity is just awful. Like the way the multi-dim arrays' sizes are written in opposite order to the one used when accessing values? Pure genius. </s>
It's probably safe to assume that the title of "most expensive software bug in history" will be held by a cryptocurrency glitch within the next couple years. It's nearing the couple-hundred-million mark of things like Knight Capital or Ariane 5's Flight 501.
> This means that currently no funds can be moved out of the multi-sig wallets.
Wait, am I reading this right? All multi-sig wallets are frozen due to this? This is surely concerning, as I've seen others recommend multi-sig wallets as a security best practice.
Can anyone comment on the method in which they might revert this? Would it require a hard fork.. again?
All multi-sig Ethereum wallets created by Parity (or using the Parity contract code).
> Can anyone comment on the method in which they might revert this? Would it require a hard fork.. again?
So far, it doesn't look like you can do anything about it. Of course you can change everything with a hard fork but as this time it doesn't compromise the move to PoS, I don't think a hard fork will be the favored solution.
But this time, there is no deadline, so it can be discussed thoroughly.
Holy shit, I just moved my ether off of coinbase on sunday so that it could be more secure and almost chose parity, but went with MyEtherWallet instead. This makes me feel like there is no safe way to store my ether now.
To be clear, neither the regular Parity wallet nor MyEtherWallet are affected here. Also, they don't store your coins, all they can ever do is sign and publish transactions when given access to your private key.
Parity multi-sig wallets are an entirely different beast.
Bit of a confusing naming issue:
Parity wallet: light client software that accesses the blockchain.
Parity multi-sig wallet: a smart contract deployed on the blockchain, with the coins stored within this contract.
Ah okay, thanks for the explanation. I've heard of multi-sig wallets, but wasn't quite sure what they actually do. From what I can tell they are supposed to be more secure, so it is a bit ironic that this is the second time multi-sig wallets have had issues.
IF there is a hard fork to resolve this I hope some very hard questions are asked regarding why there was a hard fork for this, and not one for the earlier Parity bug given that the amount of funds lost in both were roughly equivalent.
Unless I am recalling incorrectly, the bug during the summer did not impact anyone on the Ethereum team, while this one did.
Which would make the motivation behind a hard fork in this specific case ... questionable.
I think that would be the time I divest myself of the ETH I hold.
Disclaimer: (If it wasn't obvious from the above :) ) I hold a decent amount of ETH (thankfully not in a parity multi-sig wallet!)
From what I understand, this can be fixed with a generalized fix for this class of contract bugs, which makes it different than the previous bug. More importantly, this can wait until the next planned hard fork, since the funds are locked and not going anywhere, so wouldn't need its own dedicated hard fork.
It's like if you have a bunch of cash, and then you see an ad on TV:
Get your Amazing Super Safe Cash Box today! With loads of advanced features that may or may not be useful in the future! Made by some of the cleverest people in the world!
You decide to store your cash in this amazing device, so of course you do a bit of due diligence on the construction and find that well, while there was a huge catastrophic construction failure causing millions of dollars of loss a few months ago, the new version was quickly released fixing the specific issue... so it should be fine, right? It definitely probably won't set all my cash on fire...
Never mind the lack of independent audits, and the fact that the whole thing is way too complicated for its purpose...
Ethereum's biggest problem, is that it has way too many moving parts, leaving too many points of failure. Even Bitcoin has a lot of moving parts, but Ethereum is a circus in comparison.
The moving parts is kind of the whole point, but yeah.
I hope and predict that these disasters become million dollar lessons on what kinds of autonomous functions you can trust with money, and what "security auditing" actually means, so that in a couple of years, given that the notion of a smart contract is actually useful, people won't put funds into bad, faulty logic.
Mind you, these digital currencies aren't much like a safety-deposit box (i.e. the actual Super Safe Cash Box.) They're more like a bank.
Safety-deposit boxes are dumb stores for objects. They've never been marketed on features; in fact the opposite, they're marketed partially on the idea that nobody can open them but you. Therefore, no services (e.g. automatic transfers) can be built that depend on someone being able to automatically do things to your safety deposit box without you there to watch.
Banks (specifically, checking and savings accounts) are not dumb stores of money. They don't even hold onto your money; they leverage it into investments. Banks have always been built on "loads of advanced features" like compound interest, wire transfers, cheques, etc.—things the bank can do to your money because it is not, in fact, a Super Safe Cash Box. It's a convenient, maybe-safe money-management agent.
Bank accounts are only really trustworthy because of 1. a long track-record, and 2. being insured against losses (in banks' case, by the government.) Those are the same requirements I would put on any digital-currency+contracts system before I considered it trustworthy. Digital-currency+contracts is trying to do banking with banking features, so hold it to the expectations of a bank.
There is an equivalent with Ethereum. When millions were stollen from the DAO they hard forked the currency to take it back. That's why there is Ethereum and Ethereum Classic. Some people didn't approve of forking to correct a bug in a high profile crypto contract. I've been wary of Ethereum ever since.
There are bound to be many more incidents such as this in various cryptocurrencies. There are now thousands of them. But it would be ignorant to dismiss the technology for a lack of understanding it.
That accomplishes the same thing, but that doesn't make it equivalent in the important senses. That requires everyone to change their core interface with the currency. It's not a trivial thing!
The analog in national currencies would be if everyone had to immediately stop using the old notes and replace them with new ones that a new anti-counterfeit feature. Or migration to the Euro.
When banks are hacked or whatever, they have some kind of insurance that just replaces the money. They don't have to get the rest of the system to update anything.
Suddenly lots of people with guns to go get your money back is a very useful feature compared to some cryptographic guarantees that people with guns can't get your money back.
Oh please, consider the freedom of people to lock up their money and not get it back! These men{!} with guns first send a letter to an ETH autonomous corporation, then when it doesn't respond, they threaten it with guns. That's the State.
{!} Thanks to today's progressive reforms the State now also employs women with guns. We should just say people with guns to not be sexist.
A given "ETH autonomous corporation" might not have any controlling entities that are accessible to the wronged State.
Foreign shell companies are already hard enough for most governments to deal with—and that's with trade agreements that enable them to compel disclosure of ownership. DACs are foreign shell companies without a governing state to point guns at.
Sure, if the DAC does business in the US, the US government can shut that business down—much like the US government can shut down a domain name associated with foreign illegal activity. But that doesn't stop the business from operating anywhere else. Nobody has the ability to shut down the whole business.
I am wondering what exactly has been the point of having this code separated in this "library" in the first place, instead of just duplicating the code for each owner of a multisig wallet. It can't be to ease the update process of the core multisig code (since the library is just as non-updatable as any other contract), which otherwise is a typical reason for separating stuff into shared libraries.
Has this extra layer of complexity really been injected just to save some bytes on the blockchain?
it is a way to save on gas. Imagine all those functionality being deployed everytime someone creates a multisig. I read somewhere that the savings are in 90%? In absolute terms though I think it is very minimal and people just got way too cute with shared libraries. Again, I wouldn't trust >1M on a couple of lines of code.
The code is immutable, but Ethereum has a functionality called "suicide" by which a contract can, well, commit suicide. It is kind of like a deletion, in that the code can't be executed anymore afterwards, but of course the blockchain still contains the contract in its original, unmodified form.
AFAIK this feature was introduced to make owners capable of deactivating contracts which contain known security bugs (so at least nobody can accidentially send any more money to those contracts). And because that's the intended purpose, a suicide is non-revokable, so a dead contract remains dead forever.
A library apparently can be nuked because Ethereum does not explicitly have a concept of "libraries". They are after all just contracts, with the only difference being that they are intended to be called by other contracts instead of humans.
I see the next controversial, but eventually Vitalik-blessed hard fork incoming...
> A library apparently can be nuked because Ethereum does not explicitly have a concept of "libraries". They are after all just contracts, with the only difference being that they are intended to be called by other contracts instead of humans.
That's not correct. There is a construct "library" that is different from a normal contract. But the code in question didn't use that (for whatever reason).
> I see the next controversial, but eventually Vitalik-blessed hard fork incoming...
I wouldn't be so sure.
It's only about 1% of all ETH and the funds are frozen. The DAO hack was ~15% and would have put those funds into the hand of a single entity which would endangered the eventual move to PoS.
> That's not correct. There is a construct "library" that is different from a normal contract. But the code in question didn't use that (for whatever reason).
Thanks for pointing me to this! Didn't know that yet...but in that case I'm really wondering why this strange "library" from Parity even worked the way it did...? If it's necessary to use the library construct in order to have the code not access its own contracts' data storage and funds, but those of the calling contract (this is at least how I understand the description you linked to), how could the Parity library even work the way it did without this construct?
You can always call public methods from other contracts regardless what construct you use. The library construct is a Solidity implementation detail but you can also use normal contracts, like they did in this case.
So far, it really looks like almost a criminal sloppy refactoring of the official multi sig contract from the EF that has been extensively audited.
As far as I know, Solidity "library" is practically just syntax-sugar for exactly what Parity's wallet was doing already. It wouldn't have prevented the library-contract from suiciding.
I can't help it... the fact that it was a person named 'devops199' that did this is too delicious. In true devops style, breaking things in production.
Isn't it possible to generate a new token that has the same amount of ether lost, and airdrop it to those addresses? That token can be assumed to replace ETH (call it ETH1), and should have the same dollar value in trading markets.
You're right that it's not a vulnerability of Ethereum. It's representative of a weakness of Ethereum and it's language which makes mistakes like this bug a lot more prevalent.
It's sort of how like a "use after free" bug in a program written in a non-GC'd language isn't a vulnerability of the language itself.
Languages encourage or discourage (or even eliminate) lasses of bugs based on their design. Etherum's is particularly bad in this regard.
Is there a way you can do fuzz testing on wallets before deploying to catch similar bugs to this? I'm guessing it would cost a lot of Ether if an attacker wanted to automatically fuzz test many high value wallets looking for exploits?
Because this bug was predicated on both a specific large number (the address of the wallet that happened to serve as the repository of the library code), and a specific sequence of actions, you would likely have to fuzz-test for a very long time before finding it.
Not in terms of gas, because one can test on a separate blockchain. But it takes a lot of expertize and time, which means money - and it appears that for all the money that was saved in their wallets they received very little (if any) funds. I find it hard to blame them...
I mean, for a currency replacement that will solve all the worlds problems; it sure seems to be a lot of news about large thefts and issues leaving people unable to spend their money..
Can anyone explain why one would want to do multisig in a smart contract? Can't you split your keys offline? (This is how one would do multisig in Bitcoin, for example).
Multisig can be a nice compromise between security and convenience. There is a service that allows you to store Bitcoins in a 2 of 3 multisig address where you control two keys (one in offline wallet one in hot wallet) and the service has one key. When you do a transaction they send you one time code (SMS or something like that) if you respond they sign the transaction. So to spend you need to receive their code and your own key. This is kind of 2FA. If the service disappears you can take your offline wallet key together with your hot wallet key to unlock funds.
You don't need a smart contract to achieve this. I suppose it's more convenient since your co-signers can just submit their M signatures onto the blockchain, instead of having to collaborate offline to generate a valid signed block.
But putting the multisig logic into a smart contract is quite obviously not fail-safe, as these vulnerabilities show.
AFAIK hardforks are hard to detect by a contract, the contracts don't know anything outside the chain, if you split the chain, you can't tell there is another.
Of course I've briefly entertained the idea but on the other hand, a bet between two mostly-honest individuals doesn't need a blockchain contract, similar to how I don't need a blockchain contract to borrow money from my sister and pay it back later.
In any case, if there would be a hardfork, it would include the replay protection, so a simple but working solution would be to prepare a transaction for the fork chain and one for the non-fork chain, the participants can then publish the transactions once either chain becomes available and claim the reward.
It wouldn't be that hard in this case. You just have to watch for an address holding stuck ethers because of the bug, if the ethers move, it is a proof that a fork has happened.
This is why I didn't invest in ETH when it was 60 cents. I thought the whole thing had an enormous attack surface and wouldn't scale. Just goes to show that flawed things can be extremely lucrative.
They decided it'd be nice if people could have a lower transaction fee when they deployed a new wallet. So they made one master contract that has all the code. Now when you deploy a new wallet, what you actually deploy is a stub that forwards function calls to the master contract, using a "delegatecall" which lets the master execute its functions in the context of the stub contract.
However, they didn't think through how they might want to change the master contract code in this new situation. In particular, they didn't remove the selfdestruct function. Self destruct is perfectly sensible when it's your own contract that you're not using anymore, but it's not so great when it's shared code used by lots of people.
They also forgot to initialize a function setting contract ownership. Someone came along and made themselves the owner, then called the selfdestruct. They posted about it on github, apparently unaware of the full impact of what they'd just done, which was to destroy the code used by all the stub contracts deployed since July 20. Now those stubs no longer have access to functions for withdrawing the ETH they contain.
This master/stub design was also the root cause of Parity's previous multisig hack. Apparently they didn't get a clue and pay for a fresh round of external audits, which I think would have easily caught this problem. In fact, at the end of a post-mortem of the previous hack, published on July 20, they complained that they lacked funds for such things:
https://paritytech.io/blog/the-multi-sig-hack-a-postmortem.h...