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

[pinheadmz]

Background

Handshake was launched with a massive airdrop for open-source developers. It "supposedly" includes public keys of 216,199 GitHub users that met certain qualifications at the time that the project founders computed a snapshot from GitHub's public API. The airdrop was pre-allocated 952,000,000 HNS from the total maximum money supply of HNS, around 46.6% of the total 2,040,000,000 HNS MAX_MONEY

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 which would still prevent auditors from verifying the final merkle tree root, 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. But unfortunately these rewards were mixed in with the project sponsor rewards.

The combined list 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 has about 90,000 names and is allocated 204,000,000 HNS

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

FAQ: What is the coin emission schedule for HNS?

[magicstone1412]

Use as it is :)

[Anunayj]

I personally would be in support of both 2 or 3 (if we can get a majority of consensus from miners to move to it).
One of the biggest problems with Airdrop I see is, most developers don't even know about handshake to know they have a airdrop, furthermore even if they find out Most won't bother setting up a domain (with the long 15 day bidding cycle) and might just exchange HNS for hard money (~$528), and it ends up with no benefit to adoption. I think distributing domains might have been a better call than distributing HNS.

At the same time, my views here might be biased, since I am already part of the community and do not benefit from the airdrop.

[ecosysmaat]

Interesting article, thanks for the heads up to the points raised. As a new Namer i'd first like to feel the fundamental status quo that has attracted me; a reasonable and important mission with (it seems) great growth potential.

However I have not yet found a HNS website with a Namebase TLD that works without issues (an MVP). Before i can think about soft or hard forks i'd like to know if what exists works. Or rather can i get what i can see to work on a production level environment?

1. http and https websites served without the need for browser add-ons
2. Server-side resolver solutions that secures the functionality of HNS websites in a generally sovereign way.
3. Risk assessment of the future battle foreseen with ICANN regarding mutual compliance and interoperability. At this apparently experimental phase I'd like to build on the worse case scenario to keep my/projects' expectations in check.

"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."

Returning to your article, suppose the airdrop was done in an un-respectable way, with poor efficacy, does "Do nothing" break the developmental capacity of the Handshake project's mission?

"Deploy a soft fork and freeze the airdrop" sounds like a road to confusion, at least in the short run, that's a really big, hard, jagged pill to swallow for me as I have not yet found a HNS website with a Namebase TLD that works without issues.

Hard fork! Wouldn't that obviously break the whole project or at best displace its growth potential into a whole other era? I have just arrived, if i had come and found the project going through a hard fork i wouldn't have stopped to get involved.

From your article i am now wondering if the Handshake core development team have, in your opinion, left themselves short of resources for the dynamic development of the mission. Is this your concern? Or do you have concerns about the ethical integrity of the Handshake founders?

I'm new, ready to work and keen to learn more of where this has been and is (by consensus) going.

[brandondees]

It's an interesting problem. I think "removing the supply" is not dissimilar to what happens by default if the founders are trustworthy... most of the coins never get claimed anyway. However it does change perceptions of the token value and effectively multiplies the relative portion of supply each HNS holder controls. This seems like it could unfairly benefit the folks with large allocations already. The system was designed to give them a small but significant slice of the pie, and we'd be giving them the bulk of the pie instead, perhaps. I think having a re-do on the airdrop distribution somehow would probably help promote adoption and help distribute the coins in a more fair way. I don't know what the strategy would be exactly or how it could mitigate intentional exploitation or an appearance of unfairness. It could also undermine trust in the ecosystem's decentralized nature if e.g. matt and a few other people end up effectively controlling this process, especially if it ends up going into a dev fund or whatever. Another consideration is that any big boost in liquidity will likely tank the market price and alienate price speculators. All that said, I'm a little bit partial to redistributing the wealth somehow, perhaps just some sort of better-planned version of the original OSS developer airdrop, maybe aiming to be more inclusive of projects outside of github, better-announced, etc. — and the idea of distributing names instead of coins (or just coins) also appeals to me, but I suspect there'd be more room for contention over who gets what if they're based on handles or email addresses or anything like that, or else they'd have to be sort of nonsense strings which might not be viewed as useful/valuable.

[ca98am79]

Thanks for creating this issue. I vote for deploying a soft fork and freezing the airdrop.

I think the main goal of Handshake should be simple: make a decentralized and secure naming system root zone

That's the one and only mission and every decision should be based on this.

So taking unknowns out of the code supports this.

Gifting coins to a centralized foundation would be opposed to this mission.

[smcki012]

Do nothing. The wisest choice that doesn't break social contracts.

[sai7o]

I thought the code right now will not accept airdrop claims after genesis + 1 year + 1 month?

[pinheadmz]

I thought the code right now will not accept airdrop claims after genesis + 1 year + 1 month?

@sai7o no, the rule you are thinking of only disables Goosig - an optional cryptographic blinding factor available for certain types of airdrop claims (RSA specifically). Even after "goo-bye" all airdrop recipients using RSA keys will still be able to claim, it will just reveal their public key. See #305

[SomaticFanatic]

Would 100% be in favor of hard forking to end this issue. This needs to be fixed. It’s a major issue for me, and I’m a long time lover of Namecoin and all decentralized DNS blockchain projects.

[sai7o]

@pinheadmz if we do nothing then no goosig claims will be accepted in 1 month? supply is audit-able for all non-goosig claims?

Even after "goo-bye" all airdrop recipients using RSA keys will still be able to claim, it will just reveal their public key.

[ecosysmaat]

This needs to be fixed. It’s a major issue for me

What's the issue?

[Falci]

I'd say do nothing.

Handshake as a DNS works fine.
The $HNS (money) exists to be the incentive for miners, which is also works fine.
The airdrop strategy was designed to invite more developers, which worked for me.

Just the possibility of a fork (soft or hard) kind of damages the image of HNS.

you trust them to have distributed these funds to 216,199 individual open-source developers

Do you believe this is already affecting HNS' image?

[pinheadmz]

@pinheadmz if we do nothing then no goosig claims will be accepted in 1 month? supply is audit-able for all non-goosig claims?

@sai7o that just applies to RSA signatures. ECDSA keys are still blinded using a "tweak" which is not brand-new cryptography invented for this project and so it is was never scheduled for deactivation. Even if it were, the airdrop tree would still not be auditable as a whole - we would have to watch the chain and every time an exposed public key was used in a proof, we would have to check it against GitHub data which would have to be stored... on every full node I guess? I'm not even sure if the original data is still available and I think it would have to be to ensure that all airdrops are from qualifying recipients:

From https://github.com/handshake-org/hs-airdrop#privacy

To solve the privacy issue in a non-interactive way, a 32 byte nonce has been encrypted to your public key (you will have to grind a file full of many ciphertexts to find it). For EC keys, this nonce is treated as a scalar and is used to derive a new key from your old one. For RSA keys, a much more complicated setup is necessary. In either case, once your new key is derived using this nonce, you will be able to find its corresponding leaf in the merkle tree published above.

Publishing a signed airdrop proof using this method does not leak any information about your actual identity.

The full list of keys will be destroyed upon mainnet launch. Plaintext nonces are not saved at all during the generation phase. The ephemeral keys used for the ECIES key exchanges are also not saved.

[faltrum]

I'd say do nothing by now.
CAn we purpose a soft fork in, for example, 5 years in the future?. It's enough to spread the word between devs and they claim airdrop. Actually I'm trying it with a lot devs i know.
Do a hard fork or premature soft fork will decrease the HNS image a lot, in my opnion.
Thnks

[2drewlee]

Thanks Matt for raising this issue. I'd be just as excited about Handshake with any of the options outlined given sufficient community support.

Generally, I loved the idea of widely distributing HNS to individual open source developers in a private manner. It was unique, innovative and experimental. Morever, it felt fair. With claims stalling, it's not clear if/when more will claim. Further, I question whether "free money" translates to "skin in the game" the way one would think it would. e.g. people seem way more excited about $GME compared to stimulus checks.

A possible unintended consequence to expiring or hardfork-ing the airdrop is it would drastically increase the proportion of mineable coins compared to max supply. Because the airdrop is currently the vast majority of the supply, eliminating it drastically increases the proportion of mineable supply. Perhaps a simultaneous halvening of sorts might suffice is mitigating this effect, but I suspect this is only possible with a hard fork.

[pinheadmz]

Perhaps a simultaneous halvening of sorts might suffice is mitigating this effect, but I suspect this is only possible with a hard fork.

@2drewlee actually, reducing future mining subsidies is a soft fork because that is tightening the rules. Subsidy rewards are checked with a > and so an early halvening would be backwards-compatible.

[tinpatch00]

Option 2 with the addition of mining rewards reduced.

Let me start by saying this whole situation is very unfortunate and we have to make the best of it. As was mentioned above, the whole purpose of Handshake is to make a decentralized naming service. We should remove any unknowns.

While I understand there are now concerns about early recipients having a large piece of the pie, it is still the best of a bad situation and is preferable to "trusting" that the remaining supply is properly allocated.

Having any level of trust is a big no no in any blockchain. Even the most casual observer would understand this. Security, stability and predictability are 3 principles that have elevated Bitcoin to the status of respect it has. We should seek to uphold these values.

I am against Option 3 unless the community can come to a consensus on how this new distribution method can occur trustlessly and who the beneficiaries should be.. However, I predict this will introduce too many unknowns and inevitable politics around the latter question. We should leave the experiments of DAOs and on chain governance to projects like Ethereum. I am especially against it being anywhere near the root level.

[81jpayne]

First, thank you Matthew for bringing this issue to the community's attention.

Option 3 is off the table for me. What if we end up with two chains?

Option 1 is also off the table for me. I trust the founders of Handshake 1000%. I do. But I don't want any part of Handshake being entrusted to anyone, especially not the 952,000,000 HNS airdrop. Isn't the point of Handshake - isn't the point of any crypto project - to be trustless?

It has to be option 2. Yes, it sucks that we will be losing the airdrop; I thought the airdrop to FOSS developers was a brilliant idea. But look at what we gain, or rather lose: trust.

Don't trust. Verify.

[81jpayne]

Here's a good question to ask yourself. If you've been a member of the community for more than three months ask yourself this:

Which of the three options above do you think the founders of Handshake would opt for?

[evbots]

I like option 2. However, a lot of the communication about handshake on online forums like hacker news and reddit has emphasized this global airdrop to open source developers. I know at least one developer that recently claimed tokens even though they knew about this airdrop for more than a year. It takes time for news to spread and for people to act on information. If we go down the path of a soft fork, I think setting a future date, at least a year out (maybe more), would make sense.

[pinheadmz]

Here's a good question to ask yourself. If you've been a member of the community for more than three months ask yourself this:

Which of the three options above do you think the founders of Handshake would opt for?

@81jpayne you have an answer from at least one founder already

The question I hope users ask themselves (and anyone who saw an article on Hacker News) is "would you buy a fancy new cryptocurrency with a 70% premine, the majority of which probably but unverifiably went to open-source developers?" Because that's in the "fine print" of our social contract.

[turbomaze]

We should leave things as they are to preserve Handshake optics, honor the original project goals, and reaffirm trust in the airdrop tree in the face of FUD (more on this below).

On optics

• any fork hard or soft erodes would erode the trust people have in Handshake's stability
• DNS is critical internet infrastructure so it's important that Handshake is stable and not subject to sudden large changes
• it's not important that this is not a DNS related change; any kind of fork is a significant deviation and a negative signal for future stability

On the original project goals

• the home page has prominently displayed the fact that there is a developer airdrop since before the project launched
• any holder that cared about the money supply would have entered their positions fully aware of this mechanic
• speaking personally, the airdrop is actually a significant -- but not necessary -- part of the reason I like Handshake
• handshake's launch in 2018 stood in stark contrast to the ICOs of the year prior because the focus was on giving coins back to the larger community, asking nothing of them in return
• the original whitepaper extended this idea even further with an even more radical airdrop idea

With community consent, a coin distribution can occur worldwide to double the
money supply via a hard fork and give that doubling to everyone in the world (7
billion people as a goal). This is only useful with sufficient value in the
coin, with a target of $50 billion USD as a trigger. This can be triggered by
the aggregate value of Handshake, or an aggregate value of all coins committed
to worldwide distribution.

• it seems someone has modified it since then (can't be asked to dig through the git history at the moment to see who), but readers unfamiliar with the matter can refer to the wayback machine: https://web.archive.org/web/20191129070143/https://handshake.org/files/handshake.txt
• it's clear to me that "giving back" and ensuring that the FOSS community collectively owns the majority Handshake tokens is a core part of the Handshake ethos
• from the whitepaper:

By constructing a mechanism with coin distribution to FOSS developers
with no expectation of return, this creates a complimentary system whereby
individuals building FOSS software are able to build software for the
commons while also having majority ownership and economic benefit of co-creating
this system during the development phase, there is simply an incentive to
participate and create a valuable system for developers who own the coins.

On FUD

• If >50% of developer airdrops had been claimed already after just one year, we'd be done! Handshake would already have wide, sweeping market penetration
• More or less every other developer across the world would have interacted with Handshake in some way
• there's a ton of exciting stuff happening with Handshake right now that I anticipate will significantly grow usage in the near future
• as handshake gains more users, more people will claim their airdrops
• the number of airdrops claimed so far makes perfect sense given the current stage of Handshake's development
• we should not curtail this important developer incentive right before Handshake starts to soar

How to trust the airdrop tree

• Main thing I care about is that developers were not left out, and having personally helped dozens of people claim their airdrops a year ago, I know that if someone actually had 15 followers, they wouldn't have problems claiming their coins.
• I don't need to ask 200k developers to claim their airdrops to have high confidence that developers were not left out (more on this in appendix 1), a few dozen suffices. Your confidence that developers were not wrongfully excluded grows superlinearly with the number of positive samples.
• Once you convince yourself that people were not excluded, the only avenue for abuse that remains would be to add additional "sock puppet" keys to the airdrop tree
• We can't know if this happened or not, but we can estimate the number of developers with 15 or more followers in 2018 by looking at how many there are today and adjusting for Github's growth.
• I have not gone through this particular math myself, but from miscellaneous other analyses of Github data I've done I know that the airdrop tree size is in the ballpark
• Finally, if you can convince yourself that a) pretty much nobody was excluded and b) pretty much nobody was added, you can gain plenty of confidence that even if the original project creators were shady and messed with the integrity of the airdrop tree, it does not materially change the 7.5% they had already reserved for themselves
• Recap: if you particularly care about the airdrop tree, you can gain enough confidence in its integrity probabilistically such that any wiggle room for abuse is << the % of coins explicitly reserved for the project creators on day 1

Summary

• any type of fork sends a worrying message to those that expect DNS software to be stable
• a developer airdrop is part of the core Handshake ethos
• you don't need to have a github scape from 2018 to have (good enough) confidence in the airdrop tree
• conclusion: don't make any changes
• meta comment: I love all the engagement on this thread! Awesome to see so many people from the community chime in

---

Appendix 1

• this honestly isn't relevant, just gonna include it so nobody has to clarify what I meant
• Let A be the set of deserving recipients and B be the set of actual recipients.
• Then the set of undeserving recipients is C = \forall x\in B : x\not\in A.
• The set of excluded developers is D = \forall x \in A : x\not\in B
• For a randomly sampled deserving developer x\in A, they will be unable to claim with probability |D|/|A|
• We can independently sample n deserving developers, of whom m fail to claim, and estimate |D| as (m/n)\times |A|
• If you're inclined you can even determine how confident you ought to be in your estimate of |D| and see that as n grows, you very quickly get quite confident in |D|
• You can run a similar process on the current # of airdrop claims to gain confidence that |C| is small but this section is already so irrelevant I'll save you the spam

[sai7o]

Fully agree with @turbomaze.

Satoshi may have cpu gpu mined 1 million coins. Founder allocation fuzziness immaterial.

[jfmontanaro]

It seems to me that the chief concern here is the complaint that HS violates the principle of a zero-trust cryptocurrency, because a large chunk of its value comes from an unverifiable source and is therefore not properly trustless.

I wonder, though, how big of a problem this actually is. Yes, there are definitely people out there who believe so strongly in that principle that they wouldn't touch HS with a ten foot pole unless it were to get rid of it. But I think that a significant majority of the people who will end up using HS, if it takes off, won't be very worried. After all, anybody who's using DNS right now is implicitly trusting the (very few) entities who actually control the root DNS servers.

And the airdrop provides a pretty significant advantage, in that many people who stumble across HS will discover that hey, they actually have a stake in this, and maybe they should start messing around with it and see what happens.

A second advantage is that the airdrop can actually act as a stabilizing influence on the price of HNS: if the price goes up, more people are incentivized to claim their airdrops, increasing the amount of HNS in circulation and bringing it back down. I think this is a good thing, since price volatility tends to be a barrier to cryptocurrency adoption.

So, in summary:

• HS isn't trying to be an ideologically pure cryptocurrency, it's trying to be a replacement for the root DNS zone.
• The target audience isn't hard-core crypto afficionados, but average FOSS developers, sysadmins, etc. who will likely not be too disturbed by its lack of ideological purity.
• The airdrop adds some significant advantages which, to me, are worth sacrificing some trustless purity.

I've been aware of HS for less than a month, but it's the first thing I've come across that looks like it actually stands a chance of replacing the centralized architecture of DNS. In my opinion freezing or reversing the airdrop would do more to hinder the adoption of HS than it would to help. (for all the weight that my opinion carries, as someone who found out about HS less than a month ago. :P )

[SomaticFanatic]

People need to stop being scared of hard forks. Us in the Monero community have been hard forking once a year for six years. It’s not a big deal. Yes, there are a bunch of useless tiny forks of Monero still being mined but nobody uses them.

The difference between Moneros hard forks and the Bitcoin/BitcoinCash split is contention. If Handshake cuts off the dev share, will an army of users and devs go off into the distance to continue the project on their own term? Certainly not. Monero even switched its PoW to cut off GPU mining (because RandomX is ASIC resistant), and after a few weeks of grumbling everyone came together, and today 99.99% of the community has consolidated around the main project fork.

There is no social contract with a project this small. There is only the devs of the project. What do YOU feel is right? Do that. Everybody else will just accept it and move on, and if they don’t they’re free to create “Handshake Classic” et al and try their hand at that.

[pinheadmz]

@SomaticFanatic "contention" is precisely why I opened this issue.

With 18 participants in just a few days it seems like option 1 has slightly more support (although not everyone made a clear vote). A few participants sound like they would be "ok" with option 2, and a few more participants sound more strongly in favor of options 2 or 3.

I'm going to leave this issue open, maybe forever, and we'll see if community sentiment changes over time. Ideally we'd get a lot more responses and hopefully some input from non-English-speaking users as well.

At this time, I'm going to interpret the comments so far as a signal NOT to write a pull request for a soft fork that freezes the airdrop, and just prioritize everything else I'm working on and reviewing other PRs, etc.

This does not mean that I would strongly oppose someone ELSE writing such a patch for hsd, or even trying to convince the community or mining pools to run such software, I'm just not going to do that myself at this time.

[brandondees]

after catching up to the various arguments, i'm still squarely on the fence about this.

the point about trustlessness is i think a valid one, but as others mentioned, maybe not the driving force for this project that it would be for others.

the points about forking vs not forking, i'm not so clear on. i don't see anything wrong with forking especially when the community is young and small, while it's still practical to achieve with relative efficiency. some details of HNS design seem to have been intended to be forked based on how things progress with adoption, e.g. the reserved names cliff at 4 years. it's only a problem if they result in substantially competitive forks, which would require community division on these issues. if and when some broad consensus is ascertained about this kind of decision, that's how blockchain systems are supposed to make improvements over time. if there's no strong community consensus, then it probably shouldn't be done. a github thread is probably not the right way to figure that out, but it's a good enough starting point for weighing the arguments at least.

i'm not convinced writing a fork PR ahead of a high level decision is a good use of resources unless it's something that could be time-sensitive to resolve quickly when some incident occurs. i'm not sure whether this is one of those.

for now i tend to concur with leaving it alone as-is, since we can expect more FOSS devs to claim as HNS exposure grows and that's generally a good thing.

[kibagateaux]

Option 2 doesn't solve anything. If you are operating under the assumption that founders control 70% of total supply, the profitability of executing a 51% attack to claim will only increase over time. If this were to happen, presumably we end up hardforking out the airdrop anyway so all we really did was deny FOSS developers the money they were gifted.

I agree with @SomaticFanatic that forking is not inherently bad and we should even look on it positively since we are actively improving the core protocol in a verifiable way.

Personally I don't care between option 1 or option 3. I lean towards 1 for similar reasons to @jfmontanaro. Even if 70% were claimed by founders it doesn't change anything about the Handshake DNS system. The only people that get hurt are speculators and they took that risk or should have done better research. If we do go with a hardfork I think it would be better to incorporate value adding features into the process (e.g. confidential bids or native trustless subdomains) since this isn't time sensitive and we don't have to coordinate an extra hardfork.

[smcki012]

I want to state that I think Namebase has too much economic incentive here and their opinions should be carefully examined. The best move is to respect and trust the creators of the chain, and verify where you can.

Forking to change the distribution at all shows a strong misunderstanding of blockchain governance, and it is a spit in the face of those who thought mindfully on how to ensure Handshake's success long term.

Stop trying to change the economics to benefit some in-group that wants more influence in the short term, because they didn't create it and desperately seek validation. That's all this is. Anyone seriously discussing this is a danger to Handshake.

This is why we need a second full client implementation ASAP so HSD maintainers don't get brave and become tyrants of ego.

[DIPMR]

The code is stable and serves the intended functionality. The air-drop is an integral part of this architecture and it will contribute to the ecosystem in many unimaginable ways.
Unless until majority of earth's population doesn't vote to make any change it should not be implemented in any kind of fork.
So I request to let it be as it is.