The effects also includes the inability to read the contract: https://kovan.etherscan.io/address/0x5a397993b8d2fd93d1e1edc2dd7f21167e5396d4#code As well as the side effect of any multisig wallet linked to the library now behaving like a black hole contract; contract Wallet {

function () payable {

Deposit(...)

}

} You can send ether but it won't come out (not tested).

Findings:

While this has been mostly an exercise in learning how to recreate the past and a significant event in the Ethereum blockchain, I would also like to mention some findings that might help others and myself moving forward, once again just my opinion, yours might differ mine might evolve.

1.This was a preventable event and a simple (but costly) oversight:

The root cause of this event was the oversight of not calling the initWallet method of the library contract and claiming ownership in the moments after deploying it, for whatever reason the team or developer failed to do so. Human errors of these types have always been part of business and human activities, the causes could be multiple: pressure to deploy, team structure & culture and lack of checks & balances to name a few. A simple preflight checklist could have avoided this oversight, but as mentioned the environment & culture also needs to be there.

2.MultiSig wallet & smart contracts are complex,maybe too complex for their current use.

A multisig wallet ( especially one that uses the library pattern) is a complex smart contract, in itself a complex piece of software. As such it needs to be better documented and tested, unit testing and inline comments might not be enough,3rd party audits from multiple sources could be helpful as well as a more down to earth explanation of what it does and the risks involved in using it. While anyone can read deployed smart contracts code,not everyone can be expected to know the ins and outs of the language…There is also a risk/reward benefit relationship and/or technical debt associated with both the pattern used and multisig wallets. Sure, they are safer, but at what cost, sure, they are convenient and easy to deploy, but at what cost, sure the pattern saves money, but at what cost ?

3.There are multiple chasms in between Developers,Tooling, Blockchain Clients and Consumers which contribute to these type of mistakes.

This might sound counterintuitive or preachy, but users also have a responsibility here; there is little oversight of blockchain projects and maybe there will never be since they are decentralized, so the responsability lies with users to understand the risks. I think greed and novelty could be a blinding factor to these risks.

Blockchain clients like mist,parity and metamask are works in progress and are continually changing, some parts of them like multisig wallets are a 3rd party risk, but since they are bundled together they appear to have the same security features and behavior as the underlying currency, this point needs to be explained better.

Tooling is fractioned, poorly documented and complex ( Mostly due to the economics involved and the newness of it all). While better tooling is unfortunately always a luxury, it can also allow for better tests,code and forensics.

Developers are also a contributing factor. It’s quickly being realized that coding mistakes, complex code and other minor issues in other languages have heavy consequences here since real money is at play. Rather than becoming more accountable, I think developers should acknowledge that they need to dilute this responsability, companies should also take this into account, so for instance, rather than think that the job is done when a smart contract is written and posted on a github repo, there should be considerable additional work done ( documentation, testing, multiple audits) before it’s really done.

4. Whose gonna pay for all these findings?

Perhaps more profoundly there lies the finding that blockchain companies & projects ( like most tech companies & projects) are under a lot of pressure to perform, so while resources might be scarce there is an incentive to over promise and over reach with the consequence of under delivering and making mistakes along the way, this I think is unfortunately part of the economic system in which we live…

5. What about the exploiter.

I don’t think you are legally obligated to test others code in a safe test environment and then report the findings, perhaps there is a moral obligation, but that’s harder to define. There might be responsibility for exploiting a public facing bug, but some malicious or self serving intent is probably needed, in this particular case it is not as clear cut as in previous exploits.

Remaining questions:

I would love to figure these out :

What happens now ?

Estimates for the funds frozen range between 150 – 280 million USD, or around 500k- 900k ETH. ( not confirmed ) This issue could be resolved and funds made available again via a hardfork that would somehow modify certain relevant transactions and maybe the multisig contract ( subject to miners approval and a proposal ). This could be considered a heavy handed approach by some ( the rules change when it’s convenient ) and create a split (another one). On the opposite side, not doing anything would leave folks without their funds and maybe legal action could be initiated in the form of a class action lawsuit against those involved. Whatever the outcome ( these are just speculations), a precedent is being formed.

2. How did he got the address ?

One last thing that I couldn’t quite figure out is how did the exploiter figure out the multisig library address, it has been suggested it was picked out of his own multisig wallet ( by analysis of the bytecode) although I couldn’t recreate it. Was it published by Parity ? I also couldn’t figure out how it was included in Paritys UI call. This is probably a minor detail, but would be nice to know.