On Classes of Stuck Ether and Potential Solutions
A Brief History
Since Ethereum went live two and a half years ago, users and developers have often struggled with the usability and building on this new ‘Frontier’ of development.
The issues began almost immediately as the first users of Ethereum had to grapple with a command line interface that was extremely unforgiving of mistakes. It saw thousands of Ether sent to address 0x0, as any transaction with an ill-formed “to” address was interpreted by the client as a send to 0x0.
Then a few months later a bug was discovered in a library of Javascript utilities written by the Foundation and used by many companies and individuals to generate wallets. It resulted in approximately 1 in 128 accounts, that were produced by some teams, being rendered useless. Thousands more Ether became stuck.
While the hack on the DAO and the fork that followed are well known; The problems post-fork with transactions replaying across the Ethereum and Ethereum Classic network are not recognized as widely — a failure to anticipate that Ethereum Classic would not only survive but thrive post-fork led to a large number of issues. These included deposits of Ether to contracts that were never deployed on the Ethereum network in the first place.
Most recently, the incident with the Parity multi-signature wallet, where the contract which held the code governing the behaviour of the wallets was deleted. This left anyone with Ether or tokens in Parity multi-sig wallets unable to withdraw them.
All of these funds are provably non-recoverable without a change in the blockchain’s state, opcode upgrades or consensus rules modification. It can be reasonably assumed that this was never thought to be the intention of the users or developers that sent the transactions or deployed contracts.
There have been other losses — it has proven all too easy to include a typo in an address and send your Ether to the incorrect address. These types of errors can unfortunately never be confirmed to be provably non-recoverable as the addresses where the Ether sit are valid and usable.
Similarly, while the transactions sent to 0x0 in the first weeks of Ethereum going live can be inferred to be a user error when writing transactions — since that period this address has been used as a ‘burn address’ to destroy both Ether and ERC 20 tokens. This muddies the water considerably in determining a ‘lack of intent to burn’ on transactions sent to this address.
There Is a Solution
No one should be under any illusion that unlocking these stuck funds would be anything other than a rescue operation — and would only be possible with a hard fork. In none of these cases was the protocol specifically at fault. Issues with client usability, problems with codebase maintained by both private entities and the Foundation code, the unexpected emergence of a competitor network, and plain user error have contributed to where we are today. Ethereum, as it is today, remains solid and continues to evolve.
As it stands, many millions of dollars have been lost to many different groups of people due to these issues and others. Much of this could never be recovered due to the impossibility of either proving its status as lost — or due to lack of clarity on the sender’s underlying intention (and hence ownership).
However, much of it could be recovered, and the final part of this blog post deals with some of the potential ways in which this could be done.
Any hard fork is contentious. It is a definitive change to how we all previously expected the network to behave. The discussion right now is whether these specific changes to the expected behaviour of the network could have negative repercussions when some users have based their on-chain and off-chain behaviour on the assumption that behaviour would never change. This is where we can see strong parallels to the previous debate over the change in the issuance rate and its effect on Miner behaviour and incentives.
The Solutions
With the problem having such diverse roots it is to be expected that many solutions have been suggested which range from partial coverage with strict rules on allowed cases, to solutions with a focus on addressing edge cases at the expense of strict definitions.
The first solution to these types of issue was put forward for discussion by Vitalik in EIP156. It allows private key holders affected by certain issues to withdraw their Ether. Typical cases covered by this proposal are contracts created without code, some losses due to replay attacks, as well as losses generated by the javascript library bug.
This is a partial coverage with a “strict rules solution” — all these cases have a clear owner that can be proven with relatively cheap computation on chain. Therefore, this generalized proposal provides no explicit favour to any single account, user, or application. This approach does not cover the funds locked in the Parity multi-signature wallets because the contract itself still contains code, and it would not allow the recovery of tokens other than Ether.
A second solution would be an “address specific” Ether and Tokens recovery. This is a solution that focuses on capturing as many edge cases as possible but one that is not tightly defined. It would require those that ‘hold the pen’ to define its scope. It is, however, the most straightforward solution and would not change the semantic behaviour of the EVM but could still solve all of the cases previously raised. We understand the debate that may ensue from such a strategy.
A third solution, which was suggested by Parity, is a change to the Protocol which would allow the revival of suicided contracts and fine-grained deployment of contracts for all users going forward. It would restore the Parity multi-sig and other issues where contract addresses hold funds but have not had code deployed to them. It would also safeguard future incidents of a similar nature.
This is another partial coverage with a “strict rules approach”, though it represents enough of a change in behaviour of the EVM that it could be considered a functional enhancement to the platform as it no longer makes transaction ordering the determining factor in a contracts address. We prefer this solution as it adds functionality for users though the details are currently being debated. It currently has four different designs under review.
Next Steps
Achieving good governance around hard forks and protocol upgrades on Ethereum has been an ongoing project. It has had its successes and failures with limited experiments with democracy, plutocracy, and technocracy. Good consensus has been achieved on technical enhancements while significant non-enhancement hard forks have been both failures (the Ethereum Classic split) and successes (the mining reward reduction) of consensus. This next discussion will be an important test of how contention can be turned into consensus.
Parity’s stance is this: It is our hope that the community would get behind a rescue of these funds to help all the users that we can.
Thanks for your time.
Your friends at Parity Technologies
