Another slip-up: “accidental” kill command freezes $285 million in Ethereum multi-sig wallets

Getting your Trinity Audio player ready...

Ethereum smart contracts suffer one expensive bug after another, raising the question as to whether they should be deploying at industry-wide scale at all.

Well, this is embarrassing.

Two days ago, a user who goes by the name devops199 submitted an issue to Ethereum client Parity’s Github repository, saying “anyone can kill your contract” and that he/she “accidentally killed it.”

The result was that Parity multi-signature wallets froze. The company issued a critical security alert on their blog, saying all wallets created after July 20 have been wiped of their code and are now unusable.

“Following the fix for the original multi-sig issue that had been exploited on 19th of July (function visibility), a new version of the Parity Wallet library contract was deployed on 20th of July. However that code still contained another issue – it was possible to turn the Parity Wallet library contract into a regular multi-sig wallet and become an owner of it by calling the initWallet function. It would seem that issue was triggered accidentally 6th Nov 2017 02:33:47 PM +UTC and subsequently a user suicided the library-turned-into-wallet, wiping out the library code which in turn rendered all multi-sig contracts unusable since their logic (any state-modifying function) was inside the library.”

The locked funds are those that are in multi-signature wallets (or multi-sig wallets), which enable corporations to require multiple signatures before allowing transactions to push through. And as it is a client that caters primarily to corporate accounts, the amounts are in corporate-fund levels, too. Latest reports say the frozen accounts sum up to $285 million, contradicting previous reports estimating the locked amount at $150 million.

According to Parity, the funds are locked and not stolen—as far as they know.

Update: To the best of our knowledge the funds are frozen & can’t be moved anywhere. The total ETH circulating social media is speculative.

— Parity Technologies (@ParityTech) November 7, 2017

Should we keep bailing out erring developers?

While it is the user that triggered the freeze, the accidental discovery of the bug has fingers pointing at Parity devs, especially as this follows yet another mess back in July this year which they mention in the statement above—$30 million worth of Ether (ETH) were stolen due to another bug in their multi-signature contract. Fortunately, white hat hackers were able to recover the funds.

But with this last blunder, it looks like even the white hat hackers are powerless—as the freeze was not a theft but a wipe-out of the code that dictates the libraries how to respond to commands.

The only viable solution being proposed at the moment is a hard fork that will reverse the timeline back to the blocks where the libraries have not been wiped out yet. This will undoubtedly raise a huge division in the community again as this is sort of like the blockchain version of a “bailout.” And since this is a faulty code that was to blame, users may not see a hard fork as the right direction but rather a violation of Ethereum’s pledge of immutability and resistance to control.

This is the exact same predicament that brought Ethereum down to its knees last year—from then over $20, Ether went down to $11 throughout the rest of the year.

This slip-up undoubtedly dethrones that infamous DAO “hack”—which would have cost users around $80 million worth of Ether, and was in fact, not a hack. The attacker exploited a loophole in the DAO’s code, taking advantage of it to siphon out funds from investor accounts into its own account, referred to as the Dark DAO.

The Ethereum community then arranged and urged the community to support a hard fork that would “run time backwards” to a point where the theft had not happened. Some in the community did not agree with this. It was the DAO that chose to proceed with a token sale where they raised over $50 million worth of ETH despite being told beforehand that there were security flaws in their code. Some users felt therefore that the DAO did not deserve to be bailed out of their own mess but rather be taught a lesson. Some were even firm that the attacker should get to keep the stolen funds, since it was acquired with technical legitimacy—the attacker only played by the DAO’s rules, which had a self-destruct backdoor.

The hard fork proceeded anyway to help out affected investors, but this pushed the birth of the alternate chain Ethereum Classic (ETC) as a form of resistance against what users saw as a manipulation—and therefore a violation, of Ethereum’s motto: CODE IS LAW.

Ethereum is not enterprise-ready, despite Enterprise Alliance.

As more and more companies try to build on Ethereum, it’s becoming harder and harder to monitor each and every one of them for bugs and potential risks—that is, considering you even know how to find them. Unless you are a programmer yourself, it’s hard to pinpoint such attack vectors in a smart contract. And there aren’t enough programmers with high enough levels of expertise in the sphere at the moment to fool-proof smart contracts as they arise.

Bugs on Ethereum smart contracts have been consistent and severely costly. The fact that something like this could happen in a snap—in seemingly one “accidental” hand-slip, is absolutely disturbing. It brings to question whether Ethereum’s hasty entry into enterprise scale adoption is premature, as it is lethally expensive.

Obviously, companies and developers are still figuring their way around these things—and that is okay. But is it okay for them to be groping their way around whilst carrying the entire load of investors’ funds which would all go down in flames with them everytime they make a wrong turn?

Accountability in the blockchain era

In the traditional financial system, this is the kind of thing that gets you sued.

But with legislation still lagging behind on covering such scenarios in the blockchain industry, investors are left with no course of action other than pulling their hairs out when f*ck-ups do happen. Some are insisting that we do, indeed, have to start pointing fingers.

“My thoughts are we should seriously consider as a community what the limit of our forgiveness is. At what point do we have to start ostracizing people for security failures? – Vulcanize engineer Rick Dudley to CoinDesk.”