Using limits of Token Granularity to escape a stalker

Content

Introduction

Lately there has been a lot of talk about the stalker attack. It’s a very high-risk attack for the person conducting it. The "victime" 1. Ends up losing 0.01*N ETH + gas, where K is the number of tokens you transfer, and the attacker transfers K + N tokens. 2. The attacker loses all reward tokens. 3. The attacker loses alot of time and gas.

Description

The scenario is as follows. A malicious DAO Token Holder (DTH) will make bots that will vote in all split proposals where the the attacker will have 51% of the tokens and be able to prevent to victim from withdrawing the tokens until a ransom is paid.

Here we will show that this attack will be seen coming, and that even if you are the victim of it you can still withdraw the majority of your tokens. Losing 0.01*N ETH + gas, where K is the number of tokens you transfer, and the attacker transfers K + N tokens. Finally the attacker loses all his reward tokens.

Analysis

In order to split there is a two step process. First you must vote for a new Curator. In this case we will set ourselves as the new Curator. After the debate period you can see who voted yes on your proposal only these people can join your new DAO. If no one did you are safe from the stalker attack.

If not and you call splitDAO() anyway, an attacker may also call it and essentially you will both end up in the same childDAO with the victim being the curator but not having the majority.

From this point on both the victim and the attacker are locked. The attacker will need the victim to add him to the whitelist so he can be the recipient of anything, and the victim will need the attacker to not out vote him on any proposal. Also the attackers rewards are totally under the victims control.

The attacker will try blackmail the victim promising them to allow them to get 70% (for example) of their money out while the other 30% would be the profit the attacker makes. The victim will say no and do the following.

Prevention

The prevention of the attack is quite straightforward. Before calling splitDAO() make sure that no one else apart from you has voted in this proposal. If someone else did, then don’t call splitDAO(). The UI that will be offered by us for voting will actually include a warning for that, by checking if you are trying to split and if other people can follow you.

Solution

There are two main ways to address this attack. We will detail them here one by one.

Split at the last minute

One way to make sure that nobody will follow you to the new DAO is to wait until the very last minute to split. Say that both you and the attacker have voted for the split proposal. The attacker’s bot would be waiting until you call splitDAO() so that after that he can't call it himself and join you.

There is a period after which you can no longer call this function. That period is splitDebatePeriod + splitExecutionPeriod. With the average block time being 15 seconds that gives you about that much time to make the splitDAO() and make sure it goes in the very last block before the splitExecutionPeriod expires.

The attacker would need to wait for this block to be mined in order to see that you actually called splitDAO() and then he will try to do the same to join you. Only he won’t be allowed to do so, since we would be after the period where calling this function would be allowed.

So as a result you would safely be split alone in your own solo DAO.

Robbing The Attacker

Lets say you find yourself in a DAO with an attacker. You have 100 (K) tokens and the attacker has 101 (K + 1, N = 1 ). So lets firstly split our tokens in two separate accounts. Each with 50. Now lets make two new proposals to split into two new DAOs. The attacker is in trouble because he needs to split his tokens in order to be able to stalk you to both of these DAOs. But the problem is that he will only have the majority in one of them. 50 in the first DAO and 51 in the second.

You can see here that one account can follow you and have the majority. But the other cannot. Because the way tokens get blocked the attacker cannot use both accounts to follow you. The most he can do is follow you to a new account where you have 50/50 split.

Then you can repeat and withdraw your ETHER plus some of the attackers if he is dumb enough to stalk you to a DAO you have the majority in and are curator. You can then even use halveMinQuorum to take all the stalkers ETH in one proposal.

My favorite part of this attack is that even if the attacker has the majority in the first childDAO they cannot withdraw any rewards to MotherDAO has unless it passes through your account. You have already withdrawn your ETH using the method discribed above. So you should charge the attacker a 10% for giving him the rewards ;-)

The final result of this would be: 1. The attacker’s money is stuck alone in a DAO where he is not the curator. All his money is lost. 2. The attacker can no longer get rewards from the parent DAO. 3. The “victim” has most of his/her money out safely in a 3rd DAO from where he/she can forward them wherever he/she wants. 4. The "victim" can use splitting of his tokens and the granular limits to token to escape from the stalker.

To counterattack the scenario above the attacker could also start splitting his tokens accordingly to keep enough unblocked to be able to still block you. However there is a limit to the granularity of these tokens and as such an attacker would not need to have N +1 tokens but 2N + 1.

This makes the stalker attack even more a waste of time for the attacker since he can never get anything out due to not being the curator, he can only lose the money he has there because the victim has control of the white list.

Conclusion

The stalker attack, though sounds terrifying is a non-issue since it makes zero-sense for the attacker as we have shown above. That point aside, the very conversation around the topic proves that one of the first features a DAO 2.0 should have is a “solo split” option.

The DAO