Thawing the parity ether-freeze

As i wrote earlier today a simple logic flaw resulted in 250M+ USD in ether to become frozen.

As this event has happened and cannot un-happen, I thought it would be interesting to evaluate the options at this point in order to possibly recover the funds.

Our options

Do nothing

Do fork

Do feature

Option: Do nothing

In the do-nothing-department there actually does exist a way for the funds to be recovered.

When a contract is deployed it is given a “random” address. However the address is not random, it is dependent on the sender and the amount of transactions the sender has sent. This is then hashed with Keccak-256.

If we could send deploy a contract in a way that made the address collide with the existing address 0x863df6bfa4469f3ead0be8f9f2aae51c91a907b4 the suicided contract would be overwritten as far as I understand. EIP-684 was created by Vitalik to prevent contracts to be overwritten in this way (under other conditions in Metropolis).

The problem to this approach is that we must try something like 2^80 combinations in order to find a collision, and that is not really realistic.

Option: Do fork

When the DAO-hack was resolved by a hard-fork, many people considered it a bailout and the ethereum blockchain was split into ethereum-classic and ethereum.

The problem is (even though i did find the fork the best option at the time given the future direction of ethereum and PoS) that we CANNOT keep fixing bad code in contracts with hard forks. It becomes a slippery slope rather quickly.

How much ether must be on the line for a fork?

Do we only fork for thefts or for lost ether in general?

Is it only famous persons and/or companies that get the fork-treatment?

This is not a viable option at this point in my mind.

Option: Do feature

My suggestion for the best course of action is something that i have been philosophizing for the past year or so, and that re-surfaced during my trip to Devcon in Cancun.

Here we go:

Writing 100% correct immutable code is (nearly) impossible. Do we really need to force this upon our users at all times?

The requirement for immutable code scares away a large part of the programming community. The ones not scared are required to do dynamic calling of contracts and other workarounds. We also lack the tooling for proper formal verification, which is rather heavy as well.

The immutability aspect is brilliant in some ways but it is not always needed.

Let me choose!

So what if we give the ethereum community the choice of mutable or immutable contracts in a backwards compatible way?

Let us say that you can choose a destination when creating a contract.

The contract would be deployed at that address

if and only if the contract at that address has committed suicide

AND

if and only if the sender of the deployment-transaction is the same address as the first contract that was ever deployed at this address

In short, if you kill your contract you (and only you) can re-deploy a new contract at the same address. (It is my belief that this would be backwards compatible at least).

This would enable us to have both immutable contracts and contracts that can be changed and upgraded without workarounds.

Any contract that should be immutable can never contain a call to suicide() and this is easily validated for contracts that must remain immutable.

Still a bailout, but a bailout everyone can benefit from

As this would possibly (probably) adversely affect other contracts i would suggest that it only goes into effect for contracts created after a certain block-height with the exception of the now stone-dead parity-contract.

Yes, it would be a bailout, but a bailout through a feature-increase in ethereum, lowering the difficulty of getting into contract-programming and allowing us to (optionally) avoid mistakes like this in the future.

This feature would allow parity to re-deploy a fixed contract at the specified address, preferably one without any possible suicide() and it is my belief that fixing this issue through a feature that many can benefit from in the future is way better (and less controversial) than doing it through a parity-only-fork.