-
Notifications
You must be signed in to change notification settings - Fork 279
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Money Supply] Try to audit the airdrop, and find duplicate addresses and keys in airdrop trees #786
Comments
Wow really fantastic research, especially for a new user! I can maybe explain a few of these observations. The faucet tree for example may contain user addresses in more than one "category." I am willing to risk my own privacy to acknowledge that my own faucet address appears twice. That's because I qualified for the GitHub OSS dev airdrop AND as a project creator, having worked for Purse.io and contributed to HNS code during testnet. However, my GitHub OSS airdrop being included in the faucet removed my airdrop from the big tree (I have tried to claim it, its not there). A similar mechanism may explain the tree/faucet duplicates. For example the first address: In both of these examples so far, users only received ONE OSS dev airdrop. So, the duplicate exposed keys is certainly the most interesting observation, and I can't explain it right away. Are you totally certain that github does not allow multiple users to set the same PGP or SSH key? One final note: We observed in mid-2021 that some pgp keys must have been stolen and used by hackers to claim HNS. I don't think this explains any of your observations, but may help understand at least why some addresses seem to claim multiple airdrops. |
From what I can tell, yes. The GitHub forbids me to add the key However, I can not find any GitHub documents specifiying this behavior :( |
If it is acceptable to appear in multiple categories, such deduplication could potentially rejects some valid faucet airdrops :( For example, if both
It would be rejected by the deduplication because of hash-collision. However, it is possible to include an address multiple times in
Moreover, both addresses are still eligible for the key-based OSS airdrop, because they are not in
Maybe not... as stated above.
Yeah, that makes sense. I admit that the address-based observation is limited and inaccurate.
Thanks for this note. Not explain my observation, but very interesting :) |
Hi, I am new to the Handshake, and attracted by its interesting airdrop mechanism.
As #549 mentioned, the airdrop tree is impossible to audit. However, with the help of claim witnesses on the chain, it is still possible to audit this airdrop, at least to some extent.
I explore the airdrop claims for the first 150,000 blocks (until Dec. 10, 2022), and find multiple duplicates in the airdrop trees.
Duplicates in the faucet tree
The faucet tree is published in the plain text. so it is possible to audit each airdrop.
As discussed in handshake-org/hs-airdrop#20, seems like the faucet tree is designed to include each address only once. However, there are still 17 duplicate addresses in the final tree.
An explanation is that the implementation is problematic: The deduplicate is based on the hash of airdrop keys (codes), which related to more fields such as airdrop value (codes). In the end, two airdrops for the same recipient address would not be viewed as identical so long as their values differ, such as
hs1qu2zqenh8jdxvaqz7nwun4r3k32klmuf6ss2y9s
at L348 and L1273.Duplicates in the airdrop tree
The airdrop tree includes the hashes of airdrop keys (code). Each airdrop key is derived from a public key by applying a nonce, or generating a new identity.
It is insufficient to audit the tree by comparing these hashes, as a single public key could produce multiple different hashes by simply changing the nonce. However, the witnesses of airdrop claims may reveal the underlying public keys, which enables us to audit those claimed parts.
According to those witnesses, there are 6522 airdrops claimed as of height 149,999, and thousands of them revealed publicly (all RSA keys, some ED25519 and some P256 keys).
From these keys, we could identify at least 5 keys appeared twice:
Therefore, some public keys are used multiple times when building the airdrop tree. Since only 3% airdrops have been claimed so far, there could be more duplicates in the actual tree.
Luckily, the Goosig was disabled (#305), so all RSA claims must reveal their real key. To prevent this duplication, the miner could check whether the public key appears in the previous claims.
As for the code, the problem is that the public keys are NEVER deduplicated when building the airdrop tree. Although GitHub does not allow two users share the same public key at the same time, it is still possible to delete the key and add it to another account. Since the crawl takes about a week, such rebind may cause duplication in the crawled data. Moreover, the airdrop tree includes public keys from three sources. The duplication may occur among or within the lists. However, we may never know what happened when the tree was built, since the crawled raw data were destroyed.
Duplicates between the faucet tree and the airdrop tree
Although the keys of faucet recipients are removed from the airdrop key, there are still 4 addresses that claimed both faucet and airdrop:
Seems that the faucet recipients are not fully removed from the airdrop. For example, the deduplicate of GitHub users is performed only based on the username. It does not consider the emails of GitHub accounts as other lists do.
Summary
Based on the published faucet tree and the claim witnesses of the airdrop, we could audit the airdrop to some extent. Results show that some addresses and public keys may be added multiple times when the tree was built. Such duplication may be introduced by problematic implementations.
To eliminate possible sybil attacks, a soft fork could be deployed to reject duplicate public keys in the claim witness. Or take further actions as discussed in #549.
The text was updated successfully, but these errors were encountered: