jebmo’s posthaven

A DAO Counter-Attack

Friday the 17th of June was a dark day for The DAO. As many of you may have deduced, The DAO was attacked using the recursive call exploit inside the splitDAO() function. The attacker stole 3,641,694 ether which are currently located in a child DAO as can be seen here.

There is a lot of debate around this attack, what it means for Ethereum, and most importantly what the potential suggested solutions will mean for Ethereum. This post has nothing to do with any of this. This post is here to empower you, the DAO Token Holders (DTHs) to do something about this attack while we wait for a hard fork.

Plan of Action for the DAO Token Holders

What can we do from here on out? There are currently soft forks being implemented in the major Ethereum clients that would prevent any and all value transactions from going through via any contract that is either “The DAO” or a child DAO. This would prevent the attacker and any other DTH from moving any ether out of any v1.0 DAO. The choice of whether or not to implement this fork lies with the community.

But even if this fork is not implemented, the community can stop the attacker from ever withdrawing their ether, even after the 27-day period expires, by buying into the attacker’s DAO. This is not a complete solution and will probably never result in getting the stolen ether back to the original DTHs but at least it will prevent the attacker from seeing windfall profits.

Rationale and Aftermath

Why do this if there is a soft-fork?

The soft-fork is the better option, but it also depends on the wider Ethereum community to implement it. This counter-attack is something that you, the DAO Token Holders can start right now in case the soft fork is not implemented.

What do we gain by doing this?

One thing is for certain. This move can ensure that the attacker does not ever get any money out of this. From that point on, negotiations can continue with the attacker or a hard fork can happen to reimburse all the DAO Token Holders.

Timing is everything. As of now, Sunday the 19th of June we have about 25 days until the attacker’s child DAO creation phase closes. (14-Jul-2016 05:34:48). All of the steps outlined below have to be completed until then. The steps to achieve this would be the following:

Whitelist

The Curators would have to immediately whitelist the attacker’s child DAO: 0x304a554a310c7e546dfe434669c62820b7d83490.

New Proposal Creation

There is one nice detail in the DAO code which the DAO Token Holders can take advantage of. After the debating period of a split proposal is over, the original DAO is the private creation address for all child DAOs. What this means is that The DAO is the only entity that can create tokens in a child DAO without voting yes on the split proposal thanks to this line of code.

So the DAO should make a new proposal with the recipient being the attacker’s child DAO and the transaction data should be a call to createTokenProxy(), creating new tokens in the attacker’s child DAO with the beneficiary address being an address that the DAO trusts to perform the recursive split attack against the attacker.

The attacker’s child DAO has The DAO as its privateCreation address

The amount of ether that needs to be given to the child DAO can be relatively minimal since we can simply run the recursive split attack on them once we have tokens for their child DAO. We know that no one else has voted yes in the attacker’s split proposal so nobody besides the DAO can mount this attack.

Only 2 people voted yes in the attacker’s split proposal. Both smart contracts.

Voting

A large proportion of the DTHs need to vote for the proposal to reach quorum within the 2-week debating period in order to pass it and be able to execute the attack. Reminder: If DTHs vote on a proposal they can not transfer/sell tokens, this may be a challenge but is required for The DAO to do anything.

Execution

Fourteen days later we execute the proposal and The DAO will create tokens for the attacker’s child DAO. Note that in a case of a soft fork the proposal execution will fail here. At that point we can run the recursive attack on their DAO (which we have recreated) and potentially negotiate with the attacker. They can defend against our attack by joining the split. And then we can repeat this process again and again… ad infinitum. This is why this is not a “perfect” solution but just a way to prevent them from ever seeing any of the money. A hard fork is still the only clear solution.

Other Attackers?

Someone may ask the very legitimate question … what about other attackers? What if someone else tries to pull the recursive split attack on The DAO again and the soft fork is not deployed or accepted by the community? The exploit is out there and many people can probably recreate it. But what people need to remember is that such an exploit drains ether from The DAO into a child DAO. An attacker will still have to go through the 27-day creation phase to try and access the stolen ether.

A solution to prevent this attack from happening again is for as many DTHs as possible to vote yes on all open split proposals so that if someone tries to pull this again we can follow them and pull the same attack back on their child DAO making sure they can never access their ether.

Endgame

Unfortunately each child DAO is an identical copy of the original DAO containing the same attack vector. They are all vulnerable to the recursive split exploit and as such there is no real way to safely get the funds out since the attacker can and will react.

What this blog post wants to show is that there exists a way to stop the attacker from getting the money out even after the 27 days period has passed, but it relies on many moving parts and has several potential failure mechanisms.

Is this an Alternative to a Hard Fork?

Using this attack in conjunction with a soft fork 2.0 which could selectively target the attacker’s child DAO, preventing them from counter attacking when we perform our recursive split attack could allow us to successfully recover the stolen ether. However this is much easier said than done. It would be a very complicated soft fork that could have implications on the Ethereum Network if done improperly, and it would take a long time to accomplish. Specifically we would need:

• 25 days until the attack on the attacker’s child DAO could start (many things have go right during this period)
• 7 days for the split proposal debating period (during this time a soft fork 2.0 would have to be implemented and adopted by the community)
• 27 days for the creation phase of the new DAO. During this period we would recursive split attack the child DAO to drain it into our own child DAO. Thanks to the soft fork 2.0 the attacker would be unable to react.
• 14 days to pass a new contract proposal to move the ether to a refund contract.
• Assuming no setbacks, and perfect coordination with all relevant parties the refund process of the stolen ETH could begin 73 days from now.

The attacker can prevent this by draining the original DAO into any other random child DAO. We know their attack contracts have already voted in many other split proposals. Since they are not the Curator in those proposals they can have no direct financial gain. But by doing so they could render a soft fork that would specifically target their child DAO moot by draining The DAO into multiple child DAOs.

How can we defend against this? This is why the soft fork 2.0 has to be a complicated one. The DAO can pull the counter-attack described in this post to all of the drained child DAOs. A soft fork 2.0 has to be able to identify and block all such child DAOs from reacting to the DAO’s counter-attack while allowing The DAO to perform this attack.

If that can happen successfully then after a long period of time we could end up with many child DAOs under friendly control. At that point the friendly drained DAOs can push their ether into a refund contract for the DTHs to claim their portion back.

What we described above is a very lengthy process with too many points of failure. It might be a possible alternative solution to performing a hard fork of the Ethereum network, but it is a much more complicated solution. The more complicated the soft-fork solution is, the more pitfalls implementing the fork in the clients could have. Such pitfalls could lead to unintentional loss of consensus between clients due to minor mistakes in the implementation of one client. In the end the hard fork is the simple solution that will be guaranteed to solve the problem.

What is the Solution?

Soft fork, hard fork, counter-attack, doing nothing and multiple combinations of these options are all possible ways to follow from here on out. Many people have stepped up in the last few days to put their own projects and holidays on hold to discuss all of these potential scenarios and their implications. The coordination and calm discussions between seemingly competing developers, mining pools and exchanges that make up the Ethereum network has been nothing short of inspiring!

It seems evident that this community understands we are all on the same team and all want what is best for the future of the Ethereum network. I am confident that a consensus will be reached once all of the options have been fully discussed.