How the Ethereum Hard Fork Can Fail

The Ethereum fork will take place in a matter of days. I recently skimmed through it, so here are the kinds of issues that I worry about with regard to the hard fork to come, as well as half-baked ideas related to the decentralized administration of the hard fork. This is a brain dump of sorts, so treat it as such. Not every potential problem turns into a real problem. I will scientifically lay everything I worry about on the table. If we can methodically prove to ourselves that they are not worth worrying about, then we are done. However, if you have a large open ETH position and cannot handle dispassionate discussion about possible problems.

Ok, so let's delve into possible problems:

• At the very highest level, the hard fork comprises the hard fork policy (which determines how people get remunerated), the client code (which implements the ethereum protocol in multiple different languages for different clients), and the refund contract (which takes over the ether balance of the old DAO, but leaves the old DAO intact).
• The community itself determined the hard fork policy via a discussion process. I will take this as a given.
  The intent of the hard fork policy sounds quite reasonable to me. I will regard all discussion of mechanisms in a policy document as suggestions -- the masses care about the outcome, not the means.
• The hard fork policy leaves unaddressed the issue of what happens to the coins that are lost, abandoned or left unallocated in the trustee multisig contract. Laying out the charter of the trustees, so the expectations from them are specified down to every wei, is necessary.
• The client code changes (geth and parity) seem very straightforward. This is one of the big advantages of a clean hard fork. The core implementation is easy to check, and the geth code I skimmed seems to have the right general shape.
  That brings us to the new refund contract. It has three components that I want to treat separately: the refund engine, the token mechanism, and the enumeration and classification of affected child DAOs.
• I have not looked into the code for enumerating and classifying the child DAOs at all. This work involves a modest amount of blockchain forensics, and some manual verification of tools for parsing the ethereum blockchain. I assume, based on second-hand reports of people who have checked its output, that this code works as intended.
• The refund engine, in isolation from the token mechanism used to keep track of account balances, looks generally OK to me, but it is not written in a manner that I would consider best practice or defense in depth.