For the last six days, individuals from the Slock.it team and several other Ethereum developers, many of them putting aside their personal opinions on the matter, have been collaborating to give the Ethereum community an option to hard fork the Ethereum network in order to resolve the DAO hack.

The following hard fork specification still requires testing and community review. This is an open source project and therefore depends on receiving valuable input from a multitude of sources. It can also change, of course. This post is only intended to offer an update on the progress of the Hard Fork development. We hope you find it useful.

Proposed Hard fork specification

All accounts whose ultimate CREATE ancestor is 0xbb9bc244d798123fde783fcc1c72d3bb8c189413 and their extraBalance accounts [1] as well as the DAO’s main account (0xbb9bc244d798123fde783fcc1c72d3bb8c189413) and its extraBalance account (0x807640A13483f8AC783c557fcDF27Be11ea4AC7A) are enumerated into a list L. The list L is determined at block X (block number to be determined). The current contents of the list can be seen at [2]. At the beginning of block Y (block number to be determined), all ether throughout all accounts in L will be transferred to a refund contract account with code:

Remarks:

Because the actual distribution of ether in the childDAOs is hard to determine before the actual hard fork occurs, it will be done at a specific point in time (block X). The result of this blockchain analysis will be part of the hard fork which becomes effective at a later point (block Y). This means that Token Holders should not execute splits or proposals that remove ether from the main DAO or childDAOs after block X, or they will not be able to make use of the refund contract. If they do they will lose their refund. Transferring and trading DAO tokens is in no way affected by this hard fork specification.

Links:

[1] web3.eth.contract(abi).at(newDAO).extraBalance()

[2] https://gist.github.com/CJentzsch/856b7d4b3010bf9a10ff7cbbea1876a9 (not final, to be double checked)

[3] Depending on whether the contract is ready or not, a simple zero codehash (meaning we would need another hard fork later) or a final contract will be used. The final contract would have two functions (`withdraw` and `withdrawFromChildDAO`). When called, it would return an amount of ether proportional to the DAO tokens held by the sender in either the main DAO or in all (statically enumerated) child DAOs (except of attacker DAOs).

Potential code (rough untested sketch only):

https://gist.github.com/CJentzsch/038b86ae1658c680cee3bfb1499c1297 or https://gist.github.com/CJentzsch/bc01bfe17d850331eadf0c33041071a8

Reasoning

We designed a simple hard fork specification in order to reduce the risk of errors in its implementation. This makes the vast majority of DAO token holders whole, however it does present shortcomings: some groups will not get a 100% refund.

1. Token holders who created tokens during the last 2 weeks of the creation period.

Since DAO tokens are tradeable and fungible, it is very difficult to distinguish between tokens that were created at a specific time. This results in a refund model that’s instead fixed, at slightly higher rate than 1 ETH : 100 DAO tokens, applicable to all DAO token holders.

2. Tokens holders who split after the beginning of the attack.

The amount of tokens created in a childDAO depends on the balance of the main DAO at the time of the first `splitDAO` call. For this reason, token holders who split after the attack had started will have less childDAO tokens than they had mainDAO tokens.

The primary factor as to why there can not be an extra refund for this group is that the possibility to send ETH to the mainDAO and then split exists. This gives the possibility to create childDAO tokens at a 1 ETH: 100 childDAO tokens ratio. If there would be an extra refund clause to make this group whole, attackers could potentially manipulate it to get a higher refund than intended.

3. Token holders in childDAOs that were used in a recursive split attack.

Attacker DAOs (both white and black hat) are not whitelisted in the refund contract, otherwise the attacker could claim a large refund. Unfortunately, this means that token holders who own “dark” DAO tokens, will not get a refund.

With more time and resources it could be possible to design a hard fork specification that covers every edge case, however the complexity of such solutions could lead to new errors and losses. Learning from the past and in particular keeping in mind the importance of simple smart contracts, we think this hard fork specification can be implemented and tested in a short time and is the most optimal hard fork strategy given the circumstances.

Important dates

First childDAO’s creation period ends: 01.07.2016–16:25:02 CEST

First date for ~2000ETH leaving the system: 16.07.2016–17:04:37 CEST (split proposal #8)

End of creation time for the DarkDAO: 14.07.2016–05:34:48 CEST

First date an attackerDAO can split: 21.07.2016–05:34:48 CEST

First date an attackerDAO can withdraw through proposal: 28.07.2016–05:34:48 CEST

First date an attackerDAO can withdraw through split proposal: 31.08.2106 05:34:48 CEST

This means the last date for a clean hard fork without any exceptions added to the specification is the 16th of July. This is when the owner of split #8 can legitimately withdraw ETH from their childDAO. If all the splitDAOs were to be ignored, and we were to simply deal with attackerDAO’s ETH then the 21st of July would be a sufficient deadline for the Hard Fork. After this, the ETH could be spread in several splitDAOs generated by the attacker, which would greatly increase the complexity of the hard fork specification.

Conclusion

In this post we presented a suggestion for the hard fork specification. It has been forwarded to the developers of the various clients: geth, parity, cpp-ethereum and pyeth. We also presented the reasoning behind the simple design of the Hard Fork specification, as well as the important dates which constitute just as many possible deadlines to its development.

From this point on, it is up to the developers of each Ethereum client to integrate the hardfork specifications, and ultimately for the community to adopt the hard fork if and only if consensus is reached.

We invite everyone to test and review this hard fork specification, and in particular the hard coded numbers, the accounts in list L and of course the smart contract itself.