Options in the hard fork
Thank you for all the constructive feedback regarding our last post about a proposed hard fork specification. Remember, the following are just suggestions, it’s up to the organizations developing the Ethereum software clients to implement these suggestions, and ultimately up to you, the ethereum users, to decide whether or not to run these clients.
Most of the critique on our last post was centered around the fact that some groups wouldn’t get a 100% refund, the existence of a 4 week delay for the childDAOs, and the fact that the majority of DTHs would get a slightly better rate than at the creation time.
In this post, we want to introduce some further options which have stemmed from long discussions with ethereum developers and feedback from the community. Of course, they all have their own pro’s and con’s. The challenge is for the refund contract to remain fair and to keep it simple enough so it can be implemented and tested within the next weeks/days.
We will try to avoid going into too much detail on the implementations but instead we will just give an overview of the hard fork options. There are three decisions to be made:
- Is the ether collected from all DAOs (mainDAO, attackDAOs and all childDAOs) or only from the attackDAOs and the mainDAO.
- What should happen to the ether in the extraBalance.
- Whether or not to delay the more detailed parts of the refund mechanism by putting all the ether into a multisig then solve it through a second hard fork later
1. What to collect?
a) Collect the innocent childDAO’s ether
In the initial proposed hard fork specification all ether from all DAOs would be collected and put into a refund contract. As a security precaution, this contract would need to be kept simple and could not solve all edge cases (when did the childDAO’s split, is there a legit splitter in an attackDAO, etc…).
Since the childDAO withdraw code is far more complex than the mainDAO withdraw code, a 4 week delay was introduced before childDAOs could get refunded, as an added protection for the mainDAO’s withdraw. So in the case there was any exploit regarding the childDAO withdraw, only ~1.4% of the ether would be affected, and not 100%. This is of course unfair for those who innocently split. The 4 week period could be replaced by a more complex contract, which can be seen here: https://github.com/slockit/DAO/pull/270
b) Ignore the innocent childDAO’s ether
Another solution would be to ignore the childDAOs and only collect the ether from the attackDAOs and do a refund only for the mainDAO token holders. This is much simpler, and it provides another 5 days for testing, since the first withdraw from a childDAO can be done on the 16th of July, and the first split of the attacker can be done on the 21st of July.
The childDAOs could then withdraw their ether through a regular split. There is a risk that some childDAOs could be infiltrated by an attacker that could run the same recursive split attack to rob the childDAO. We believe that this is only likely to be possible for childDAOs created after the beginning of the attack. Currently about 34,000 ether are held in those childDAOs, which would be at risk.
2. What to do with the extraBalance?
The extraBalance contains all the ether that was paid above the initial price of 1 ETH : 100 DAO tokens (344,907.73 ETH).
Unfortunately, DAO tokens were heavily traded and are fungible, so it is difficult and time consuming to distinguish which tokens were bought at what price.
a) One solution would be to pay out the extraBalance proportionally to the token holders. This is simple, but results in a slightly better refund rate than 1 ETH : 100 DAO token (about 3% more). People who bought later at a higher rate would get less than they put in, and early token creators would get more than they put in.
b) Another option would be to allow token holders to donate their share of the extraBalance to … ‘something’. Of course they could donate it to themselves, or to a “childDAO compensation fund” in order to give a fair refund to attacked childDAOs, or those who split after the attack, the dogecoin sidechain bounty DAO, or any other group they feel deserves their portion of the extraBalance.
c) A third option would be to put the extraBalance in a multisig to be dealt with later, but some group would need to take responsibility of these funds and no one has stepped up to offer their services.
d) Yet another option would be to place the extraBalance in an inaccessible contract to be dealt with later, in order to get time to do a proper refund analysis through another hard fork.
Note that both c) and d) make it possible for the extraBalance to be refunded to the DAO token purchasers who contributed to the extraBalance, so that a purchaser who bought 100 DAO for 1.5 ETH could prove that they control the purchasing key, claiming 0.5 ETH from the extraBalance.
3. To Delay the decision or not?
In order to get every person that created DAO tokens their fair amount of ether back, more time is clearly needed. The options are:
a) For the HF code to place everything in a trusted multisig, which would then manage the refund. The big question again is: who would own the keys?
b) Putting everything in an inaccessible contract (as suggested for the extraBalance in 2d). This will require another hard fork later.
c) Solve everything now, without any delay.
Simplified HF spec (sample)
There is no ‘perfect’ solution without a third party holding the ether and taking the time to process the refunds later, but currently no third party has come forward to offer this.
Therefore it is my personal opinion that the community and developers need to find a purely decentralized solution without any third party involved. Here is my suggestion for a simplified hard fork specification implementing 1b) 2b) and 3c):
All accounts that used the recursive call exploit in their childDAO (all attackDAOs, white hat and black hat) as well as the main DAO account (0xbb9bc244d798123fde783fcc1c72d3bb8c189413) and its extraBalance account (0x807640A13483f8AC783c557fcDF27Be11ea4AC7A), but NOT “innocent” childDAOs, are enumerated into a list L.
At the beginning of some block X (to be determined), all ether throughout all accounts in L will be transferred to a contract account (to be determined).
Potential code (rough untested sketch only):
Conclusion
While the community ultimately has control over which software runs on the network, it is up to the client developers to choose which specification to implement, whether it is an immediate refund of everything, a freeze with an option to hard-fork again to refund later, putting the funds under a trusted multisig or something else entirely. We have laid out several options in this post and gave our personal recommendation for a simple hard fork specification. Now the community can give feedback for the developers to digest.
Ultimately, it is not up to me, Slock.it or to anyone else to make this decision for the Ethereum community. All we can do is make a recommendation, so as to advance the discussion and help the Ethereum community quickly achieve consensus: the faster the community can achieve consensus on a single proposal, the more time the Ethereum developers and community have to focus their efforts on testing the implementation in order to make sure that it is secure.