The correct posture of the airdrop: five cases tell you how to avoid being "witched"

What is a Sybil Attack?

text

Sybil Attack, translated into Chinese as "Witch Attack".

The word Sybil first came from the 1973 novel "Sybil", which tells the story of the heroine Sybil Dorsett's psychotherapy. She was diagnosed with Dissociative Identity Disorder, a combination of 16 identities.

The term Sybil Attack was proposed by John R. Douceur in 2002 to describe a specific form of attack in P2P networks. In the P2P network, nodes can join and exit at any time, so in order to maintain the stability of the network, the same data needs to be backed up to multiple distributed nodes, which is the data redundancy mechanism. If there is a malicious node in the network, then this malicious node can pretend to be multiple identities, just like the heroine in the novel can split into 16 personalities. The data that originally needs to be backed up to multiple nodes is deceptively backed up to the same malicious node, so that the malicious node may gain control of the network.

Simply put, one person becomes many, which is the essence of a witch attack.

For the project side, the behavior of witches actually undermines the decentralization process of the project, so the project side may actively screen witches during the airdrop distribution process, or the community reports them, thereby canceling their airdrop qualifications.

How does the project party check for witches?

text

First of all, we have to make it clear that it is very time-consuming and energy-consuming for the project party to search for witches, which is not an easy task. A large part of witch behaviors found in the past actually came from reports from the community.

For example, the cross-chain bridge Hop Protocol launched the community to "report to earn". The whistleblower will get 25% of the witch address and be fined the airdrop tokens. Initially, Hop had 43,058 addresses eligible for the airdrop. Later, due to the community report, 10 , 253 addresses were identified as witches and disqualified for air investment. Also in the first round of Optimism airdrops, the community also proactively reported 17,000 sybil addresses, resulting in the redistribution of the last 14 million $OP tokens.

Optimism does not disclose details of community reports, nor their criteria. So let's take a look at the specific proposals of Hop Protocol to see which behaviors have been found or reported.https://github.com/hop-protocol/hop-airdrop/issues

Hop report proposal:

https://github.com/hop-protocol/hop-airdrop/issues/3 

Case number one:

After spending Hop, the user pooled funds on the Arbitrum network, transferring all funds from 471 addresses to the same address.

https://github.com/hop-protocol/hop-airdrop/issues/163 

Case two:

The most central address distributes MATIC to the blue address, then the blue address transfers the funds to the green address, and finally the green address performs a Hop interaction to get the airdrop. (It is equivalent to the second-level connection of funds, but it is still judged as a witch)

https://github.com/hop-protocol/hop-airdrop/issues/367 

Case three:

The transfer between addresses is obviously more complicated, but it is still a fund connection and thus judged as a witch. Another point worth mentioning in this case is that the whistleblower discovered several addresses when community members were discussing interaction strategies, and then proceeded to dig deeper into this series of financial relationships. This incident tells us that we should try our best not to disclose our own addresses, and to ambush airdrops.

https://github.com/hop-protocol/hop-airdrop/issues/592 

Case 4:

These 158 addresses had exactly similar activity on Optimism and Arbitrum, and all their transactions on Fantom, Gnosis, and Polygon chains were completed within a day, and there was no transaction record after that.

https://github.com/hop-protocol/hop-airdrop/issues/9 

Case five:

There is a correlation between these 25 addresses, and these 25 addresses all minted the same NFT on Arbitrum within the same period of time, and the same all addresses minted the Uniswap V3 LP NFT within the same period of time. And in all the votes of Arbitrum Odyssey on the Snapshot, these address voting options are exactly the same. And every time, the address in the darkest middle in the figure below is the first to operate.

• Looking at the cases reported by the Hop community, the main reason for being judged as a witch is the following two behaviors👇

• A large number of wallets perform similar operations in a short period of time

How to avoid being "witched" in an ambush airdrop?

1. Do not distribute/collect funds on the chain, use exchanges instead

text

Avoiding the association between wallets is the most important point. Compared with using methods such as currency mixing to cover up the transfer relationship between wallets, exchanges are the best solution.

When withdrawing coins from the exchange, the funds are transferred from several fixed hot wallets of the exchange. And the hot wallet of the exchange has a large number of transfers every day, so no one will check the witch from here, the difficulty factor is too great.

But you have to pay attention to depositing coins into the exchange. For example, I plan to deposit the ETH of the Optimism network back to the exchange, but my Binance deposit address is a fixed one, and I have 30 wallets on the chain that need to be pooled. Here I definitely can't send all the coins of 30 wallets to this recharge address, because this will become a "many-to-one" relationship, and it will be suspected of being a Sybil attack.

So how to solve it? If I have 30 Binance accounts with 30 deposit addresses, of course. However, it is obviously more convenient to use OKX to pool funds.

Because OKX has a very useful function, each main account can generate 20 recharge addresses, if you think it is not enough, then open a sub-account, each account can open up to 20 sub-accounts. That is to say, if you open an OKX account, you can have up to 21* 20 = 420 different recharge addresses. (About the specific operation of OKX, put it at the end of the article)

2. Avoid short-term concentrated batch behavior and achieve randomization of operations

• The so-called randomization includes two aspects

• Interaction: randomization of interaction time; randomization of interaction amount; randomization of interaction route

Wallet: randomization of wallet creation time; randomization of fund transfer; randomization of ENS name

For example, like Optimism Quests (commonly known as OP Odyssey), you plan to use 50 accounts. In addition to avoiding fund associations, you can also pay attention to actual interactions: try not to transfer funds/do tasks in a short period of time , occasionally disrupting the order of tasks...

In short, if you operate purely manually, you can basically avoid these problems. Most of the batch behavior is controlled by the program.

3. Keep a low profile and do not disclose your address

Of course, "partners" are needed for the airdrop, because it is a boring thing, and it is necessary for partners to supervise and encourage each other. But this is also a private matter. Don't discuss your interaction in a high-profile manner in public, let alone expose your address.

Just like the previous case 3 of Hop, when he accidentally disclosed his address, someone would dig into his on-chain operations. As long as he was caught, he would report back.

4. Others

Other things we can do is to enrich our on-chain behaviors as much as possible, such as registering ENS domain names, participating in snapshot voting, and participating in gitcoin donations... In short, it is to make your account look like a real person.

But in the end, I still want to say that you don’t need to be too careful when interacting with multiple accounts.