[Money Supply] Airdrop tree is unverifiable and impossible to audit

## Background

Handshake was launched with a [massive airdrop](https://github.com/handshake-org/hs-airdrop) for open-source developers. It "supposedly" includes public keys of [216,199 GitHub users](https://github.com/handshake-org/hs-airdrop/blob/cf02a611df7562f91edc859dbdd69378404ff7bb/etc/tree.json#L4) that met certain qualifications at the time that the project founders [computed a snapshot from GitHub's public API](https://github.com/handshake-org/hs-airdrop/issues/35#issuecomment-586699876). The airdrop was pre-allocated [952,000,000 HNS](https://github.com/handshake-org/hsd/blob/4c901f482fc21c71e1cd71d6861be8bdeceeb7af/lib/protocol/consensus.js#L78) from the total maximum money supply of HNS, around 46.6% of the total [2,040,000,000 HNS `MAX_MONEY`](https://github.com/handshake-org/hsd/blob/4c901f482fc21c71e1cd71d6861be8bdeceeb7af/lib/protocol/consensus.js#L111)

## The Problem

There is no way to verify that the Handshake airdrop tree actually contains all of the keys the project founders claim it does. Even if the massive amount of scraped GitHub data was presented to the community for review, the airdrop also employs [a novel cryptographic blinding factor](https://github.com/handshake-org/goosig) which would still prevent auditors from verifying the final [merkle tree root](https://github.com/handshake-org/hsd/blob/4c901f482fc21c71e1cd71d6861be8bdeceeb7af/lib/primitives/airdropproof.js#L28), which is a hard-coded mainnet consensus parameter. It's also worth noting that downloading this data from GitHub takes several days and anyone ambitious enough to repeat and verify the process would probably have had to have done so at the exact same time as the project founders, in case any GitHub users updated their profile during the process.

**If you are a Handshake user, you implicitly accept that almost 50% of the total money supply was essentially trusted to the project founders, and you trust them to have distributed these funds to 216,199 individual open-source developers without adding in any "extra" keys for themselves or any other non-qualifying recipients.**

This assumption of trust is a really big, hard, jagged pill to swallow for many experienced cryptocurrency users who are accustomed to hard-money systems like Bitcoin.

## Current Data

As of block height `51407`, 4,671 airdrop proofs have been confirmed on the blockchain, generating a total of around 19,833,066 HNS. Almost all of these proofs were confirmed before block height 10,000. These days, airdrop proofs are just barely trickling in.


## The Faucet

The airdrop also included an opt-in faucet where users registered on handshake.org. Their keys were removed from the GitHub airdrop to prevent duplicate rewards. There were [1,149 faucet airdrop recipients](https://github.com/handshake-org/hs-airdrop/blob/cf02a611df7562f91edc859dbdd69378404ff7bb/etc/tree.json#L9). But unfortunately these rewards were mixed in with the project sponsor rewards.

[The combined list](https://github.com/handshake-org/hs-tree-data/blob/master/proof.json) of recipients contains 1,358 addresses, distributing a total of about 237,412,586 HNS. 100% of the faucet proofs were mined already because they paid miner fees but required no signature. So they are already on the blockchain. But have their recipients actually "claimed" these rewards yet? I ran a script over this list and found that as of block height `51407`, only 270 of these outputs have been spent (moved / claimed) which corresponds to about 72,198,479 HNS. This data could be improved by checking each recipient's value but for current purposes, we can include the sponsors in the mysterious pre-allocated coin supply.

## Reserved Name Claims

This is related to the airdrop in that we can apply the actions below to reserved names. However, the reserved name claim system *IS* completely verifiable and there is no mystery about it. If the community wants to change how claims work that can be discussed as well but it is a different problem than the un-verifiable airdrop. It's been a while since I checked but so far there have been around 1,500 reserved names claimed on the blockchain, generating around 5,000,000 HNS. The [complete reserved name list](https://github.com/handshake-org/hsd/blob/master/lib/covenants/names.json) has about 90,000 names and is allocated [204,000,000 HNS](https://github.com/handshake-org/hsd/blob/4c901f482fc21c71e1cd71d6861be8bdeceeb7af/lib/protocol/consensus.js#L48-L70)

## Actions

Most importantly, I just want all HNS users to realize this is a property of the current system. There are some things we can do with enough community consensus. The community may even change over time and revisit this issue in the future if more "hard money people" come on board.

1. _Do nothing._ The community accepts this property of the system, and trusts the founders. Users looking for "hard money" have plenty of options (like Bitcoin) and maybe Handshake just serves a different enough purpose and this is OK.

2. _Deploy a soft fork and freeze the airdrop._ This means airdrop proofs submitted past a certain block height will be invalid in the mempool and in blocks. If this were enforced today, the total maximum HNS supply would be almost cut in half immediately. Anyone who claimed their airdrop before this height would be unaffected. We will have to assume all the airdrop proofs already confirmed on the blockchain were from honest, qualifying recipients. A soft fork is deployed by releasing a new version of hsd with the new rules programmed to trigger at a certain time. If a majority of miners run the new software, they will effectively "censor" all future airdrops. Older versions of hsd will still function completely normally and can even attempt to submit airdrop proofs, but they will never be confirmed.

3. _Deploy a hard fork._ A hard fork means 100% of all hsd nodes MUST upgrade to enforce new rules. All relay nodes, all miners, all public resolvers, all exchanges, every single Bob Wallet user. If the new rules are contentious at all and the old rule set still has some hashpower behind it, there will be a chain split and we'll end up with two Handshakes (like Bitcoin / Bitcoin Cash and Ethereum / Ethereum Classic) -- and two HNS root zones! A hard fork can do all kinds of crazy new things though, for example:

1. Redistribute the value from the airdrop into a fund (for developers, marketing, whatever...)

2. Replace the current airdrop with some other distribution mechanism that can be publicly verified

## Further Reading

[Understanding the Handshake Airdrop and Reserved Names](https://medium.com/coinmonks/understanding-the-handshake-airdrop-and-reserved-names-428d9e90b560)

[FAQ: What is the coin emission schedule for HNS?](https://www.reddit.com/r/handshake/comments/j9g3y8/faq_what_is_the_coin_emission_schedule_for_hns/)