[Hard Fork] Extend name claim period

[Falci]

Alexa top 100k, ICANN's TLD and any other reserved names are available for claim in a 4 years window. Ending in February 2024.

hsd/lib/protocol/networks.js

Lines 307 to 313 in 72892cc

	/**
	* The time window in which the
	* nameholders can claim reserved names.
	* @const {Number}
	*/
	claimPeriod: (4 * 365) * main.pow.blocksPerDay,

Simple and direct: should we extend the name claim period?

Keep in mind this would be a hard fork!

• Should we discuss it now or closer to the dead line?
• What should be the extended time?
• What's the impact of such change?
• What would be the process to apply this change?

I'd like to hear the community opinion.
(I'll add my opinion in a separated comment later)

[pinheadmz]

Thanks for starting this discussion, @Falci

This is indeed a hard fork, which means ALL hsd nodes, miners, bob wallets, exchanges, registrars, etc will need to upgrade. For that reason I think acting sooner rather than later is important. And actually, we could bump that 4 to an 8 this week and it wouldn't split the chain or anything for another 2.5 years. As long as 100% of the network upgrades to at least v3.0.0 sometime in the next 2.5 years, we will effectively hard fork the protocol with essentially 0 impact.

We should still include miner signalling with BIP9 or some similar mechanism to ensure at least the hash rate is on board.

The extended time I think is a good open question, I'd start the discussion at "4 more years" (total of 8 since genesis).

If this is all we do, and we do it soon, it should be easy (there is plenty of time to get everyone to upgrade). However, starting a hard fork discussion opens pandora's box for other rule changes. If we are going to hard fork, I think we should plan on doing so as infrequently as possible, so... what else do we wanna hard fork?

[sebastianrasor]

I think that if we are to hard fork, it's better to do it sooner rather than later. That being said, I think there is value to extending the reservations. @pinheadmz makes a great point about how we shouldn't hard fork often, I agree that we should definitely try to compile everything that we have seen as a problem or foresee being a problem to avoid difficulties in the future. Back to the name claim period itself, I'd hate for Handshake to take off in the future and have to tell large players "well you should have got here earlier."
Would there be any way to measure the "popularity" of Handshake on chain so we don't have to worry about if the arbitrary amount of time we choose is enough?

[NetOpWibby]

I think almost a decade is adequate reservation time, even by ICANN's glacier-like pace.

At that point I think it's definitely fair to say "well you should have got here earlier."

Another perk of extending the reservation time is signaling to the community/outsiders that we're not in this to simply squat on brand names, make a quick buck, steamroll Web 2.0 with an idealized DNS, &c. We're signaling fairness (outside of "someone sniped my 1 HNS bid!") and our intention of longevity.

[nickrattus]

Agree with Paul. I am not technically qualified so can't comment on those aspects short of wanting the least risky approach. Macro wise this is a marathon not a sprint and we need to be diplomatic/ fair and firm.

[pinheadmz]

We can introduce some creativity into the new reserved claim rules, as well. For example, there are flags in the code that identify reserved names as ICANN TLDs, alexa top 100 (the top of the alexa 100,000), and the "custom" names like icann itself.

The hard fork rules can be applied differently to these groups, for example the ICANN TLDs can be permanently reserved (See #294 and #256).

I might even like to see a rule where the "ordinary" alexa 100k names (that are not top 100) are still released on schedule at the four year mark -- but we could even put those ~80,000 names on another 52-week rollout.

Just food for thought. The simplest and safest thing is changing a 4 to an 8, but we can also get more creative with it.

[rithvikvibhu]

I like the extension from 4 to 8 years.

Permanent reservation for ICANN TLDs might be convenient, but imo there needs to be some pressure to claim them. If in 8 years we still have problems with getting registries to claim them, then we'll still have options:

• Handshake has significant in-use domains and can stick with the current plan of dealing with conflicts at the resolver level
• Extend the claim period again (unlikely, but can't predict what's going to happen in a decade).

---

For other things to include in the hard fork, maybe we could consider doing something about the ICANN TLD conflicts.

In case of existing conflicts like .music, .kids, Amazon's IDN TLD, they can be added to the reserved list and the owner (if there is one) gets back the burned HNS. This should be possible with hard forks, right?
If not, they can be added to the blacklist -- currently only the holdmyhand plugin stops them from resolving, but the name still exists on HNS. Getting them into hsd would cover a lot more surface.

Upcoming ICANN TLDs in review can also be added as they are likely to be accepted in 8 years. Even if they don't get approved, the Handshake names will be available once the claim period ends.

[smcki012]

I believe the simplest change from 4 to 8 is the safest and most effective way to move this forward.

I will explain why game theoretically and psychologically.

-- It is commonplace and socially accepted for a regular parameter change that pushes a layer 1 protocol towards its effective end goal. A working example would be the Ethereum difficulty bomb, and how that is regularly extended by social consensus and then adopted by miners to ensure they remain profitable as they iteratively build to Proof of Stake.

For HNS, our goal is bridging as many legacy TLD owners and the Alexa top 100k as possible. A simple extension signals we are building and waiting, and can come to social consensus to make sure no one is left with a technological ultimatum. We remain backwards compatible, and are willing to wait for people to take their seat at the table.

-- The smaller the scope of changes, the easier it'll be to avoid any community backlash or angst towards a consensus change. Educating the community on the change and why becomes much more manageable. Adjusting various policy rules to favor ICANN TLDs over Alexa 100k distorts the game theory of the incentives of getting HNS adopted, as all should be treated equally. Modifying those policies could create unnecessary disagreement and complexity. I think it's best to honor the original mechanism set in place by JJ/Poon.

-- As Matthew stated, we've awhile before this is much of a concern, and by bundling this small parameter change while HSD is still the main reference implementation helps build a track record and set norms for changes in the future. Those norms being: scope must be sensible and thoughtful as to the wider response it will create socially; it must be bundled in such a way the wider economy of scale has time to deliberate if they wish to run the update; each implementation of Handshake must also accept the scope of the changes, creating a natural counterbalance for changes.

-- This also signals the community has matured and can deliberate as it has organically formed governance norms. With many protocols now utilizing HNS, it's important the root governance never appears unstable. Getting the deployment accepted is a large part of that. This aids in our lindy effect too, and establishes a layer of trust that is needed and naturally emerges in a healthy community.

[FistFullOfAss]

Am all for the extra 4 year extension for people to claim their names. I see it as a nice gesture from the community extending an olive branch saying that we really do want you to claim your name and not for some anon to squat on it. It took Bitcoin about 7 years to get it's first big spotlight in the mainstream, so giving 8 years with the rate of adoption from traditional domainers seems like more than enough time to hop on the ride. Am curious to see what other small changes people will want to include in the fork. Would be cool to see a 52 week roll out for every name unclaimed, gives people even more time to claim their names and fair chance for everyone to have a chance at getting an unclaimed name.

[Falci]

what else do we wanna hard fork?

Are you referring to developer claims?
If so, I would avoid merging both proposals because it would force the community to accept or reject both together, with no option to accept just one and reject the other.

[pinheadmz]

@Falci sorry I hit the wrong button 😬

I was referring to any of the hard fork proposals from the community over the last year. Funding development from miner subsidies, SLDs on chain, shortening the auction life cycle, even "he who opens an auction gets to bid last" etc

[befranz]

I think extending the claim period - and this better sooner than later - would be a good move. Having the option to set different rules for ICANN TLDs, Alexa 100k and other reserved names would even make it possible to avoid future naming conflicts (with few exeptions) but still encourage legacy name holders to claim with rules like this:

1. Extend claim period for all reserved names (to 8 years?)
2. All names but ICANN TLDs will be open for auction if not claimed within (1.)
3. ICANN TLDs are reserved forever to claim but (the full amount of) HNS can only be claimed within (1.)

[pgs0]

@Falci sorry I hit the wrong button 😬

I was referring to any of the hard fork proposals from the community over the last year. Funding development from miner subsidies, SLDs on chain, shortening the auction life cycle, even "he who opens an auction gets to bid last" etc

I think slds on Chain would be a great additon as an alternative to the namebase staking program and taking a decentralized route. I mean the current program is just falsely advertised as decentralized

[smcki012]

SLDs on-chain and other major revisions this early in the protocol's lifecycle is not wise. The tooling necessary to make SLD ownership decentralized is matter of technological innovation, not something that needs to be touched in the root.

With decentralized nameservers/compute/storage, we will have all we need in the layers above without creating unnecessary bloat on-chain.

As the community gets more subject matter experts and creates more community norms around research and implementation, the need and push for improvements will be easier. There is a technical/economical reaction for every change to Handshake's mechanism design (Especially in regards to auctions, such as making the one to open is last to bid. Ruins the functionality of a Vickrey auction).

We must remain mindful of the social contract that is always in place here. Before HNS is established socially/mimetically as the root across the ecosystem, any change to consensus/auction system resets that clock.

[tldblock]

Extending the claim period and having different rules for ICaan TLDs is a great positive move in my opinion as it will allow the .org and .info internet infrastructure custodians to upgrade the security on their DNSSEC making it easier for Alexa ranked site owners to claim their Alexa HNS names. The operators are using a weak key to sign their zone. ICaan would need to do the upgrade to release .icaan/ Alexa HNS Name and approximately 24,480,503 HNS. Furthermore with different countries regulations regarding crypto the added 4 years grace period for iCaan TLDs would allow adoption of crypto which more banks and large institutions are using currently.

[Falci]

Another idea: reward halving.

This could be applied to all kinds of reward:

• Alexa 100k name claim
• ICANN TLD claim
• Developer claim

It is already applied to block rewards:

hsd/lib/protocol/networks.js

Lines 92 to 99 in 56c83ca

	/**
	* Reward halving interval.
	* Roughly every 3.25 years.
	* @const {Number}
	* @default
	*/
	main.halvingInterval = 170000;

(Never happened but it is already in the consensus rules)

To make it simple, we could use the same values: 50% less every 170000 blocks.

As long as 100% of the network upgrades to at least v3.0.0 sometime in the next 2.5 years, we will effectively hard fork the protocol with essentially 0 impact.

Note the halving will happen sooner (around April of 2023)

[dnsguru]

Extending the claim period is a good and responsibile idea to put in place, +4 years, +10 years, +25 years, whatever the term is. The downside is that it might diminish the urgency to act which may have had some claim sooner vs defer, but the upside is that Handshake can be seen as a mature and trustable platform.

There are TLDs that should have been set aside as ICANN TLDs that either:

• went to auction and were acquired (ex: .music, .spa, hotels etc); or,
• were placed in the alexa list instead of the ICANN list (ex: .web etc)

There are also some TLDs (mostly .brand that opted to later not launch) which were in the ICANN root which have been released and could be available in Handshake (ex: .active, .blanco, .boots etc) (see: ICANN gTLDs JSON Report, constantly updated)

It would be good to use this hard fork to address where some TLDs were missed and went to auction - we've discussed this and it seems a bit controversial but the mistakes that let some errors slip through should be fixed. It is problematic and it creates more difficulty in having conversations with large providers to describe that there is name collision now as opposed to it being something to address later for names that have auctioned (.music, .spa, hotels etc).

[smcki012]

I would agree that a solid bundled upgrade would consist of the parameter bump, and the clean-up of ICANN reserved names (Note: even if this means deciding things are best as-is) so we can continue as we have, successfully, with less concern over those narratives (which is really one of the few I've seen publicly). If we're going to push that timespan back, it would make sense to do all we can to lessen objections from incumbents in the current DNS space (within reason).

Then you just brand the hard fork upgrade, and it's more easily digestible. I.E the "Wecann" update, that extends claim time for ICANN and clears up any minor backwards incompatibilities that were missed. It's sensible, easy to grok quickly, and doesn't make anyone uncomfortable with the scope of changes.

This is human psychology: you need to establish trust by doing small things before you can make larger sweeping changes to the globes new universal namespace. Show you can deploy a simple hardfork upgrade and go from there.

[ca98am79]

I am ok extending the claim time, especially for ICANN TLDs, to 8 years.

However, my company owns and paid for TLDs like .kids and I would be upset if they were taken away from us simply because ICANN created the TLD after the fact. I really prefer this doesn't happen because I would lose trust in the protocol. My view is that if I own the keys, I own the name. But if it can be taken away because of ICANN, I see less value in using Handshake.

[Falci]

Agree with @ca98am79. ICANN TLD may have changed since Handshake launch, but also Alexa Top 100K and "developers with 15+ followers on GitHub".
UD has also "launched new extensions". And all them conflict with already existing Handshake names.

I would not like to address TLD conflict in here.
IMO, those conflict should be solved at resolver level.

[evbots]

I am fully in favor of bumping the claim time by some amount and I've been pretty vocal about this in other channels (telegram, discord). I realize that any claim period length is arbitrary, but 4 years seems too short for large organizations to become aware of the protocol and act on the information. Something closer to a decade seems reasonable. 8 or 10 years would be fine with me.

I do not think we should use this thread to hash out other ideas we want to bundle with this proposed hard fork. Those ideas should have their own threads associated with them. If there are separate GitHub threads for different hardfork ideas, and those ideas get implemented around the same time, there's nothing stopping us from bundling those resulting merges into the same hsd release version.

[pinheadmz]

There are TLDs that should have been set aside as ICANN TLDs that either:

* went to auction and were acquired (ex: .music, .spa, hotels etc);  or,

Names that already exist in the HNS root zone, with owners like in @ca98am79's example, are in my opinion strictly off-limits for this discussion. Personally I refuse to write code that reassigns blockchain assets that already have owners, and I seriously hope the community doesn't consider this an option at all.

* were placed in the alexa list instead of the ICANN list (ex: .web etc)

This kind of thing makes a bit more sense. We will need to be more careful in the hard fork code that names in this category don't get claimed by the HF activation height, in which case they will fall into the in-my-opnion-off-limits category. We must also accept the risk that web.de claims .web on HNS using the normal process before the HF activates, and they become the rightful owner instead of NU DOT CO LLC, delegated by ICANN.

[dnsguru]

Agree with @ca98am79. ICANN TLD may have changed since Handshake launch, but also Alexa Top 100K and "developers with 15+ followers on GitHub". UD has also "launched new extensions". And all them conflict with already existing Handshake names.

There is a regrettable situation on the names that slipped through, but they completely cost the entire handshake project on acceptance and accellerate the timing of and force a conflict between the legacy name system and handshake in a way that creates immense friction to institutional adoption over the conflict. They should not have happened. They do not match the intentional protections and consistent handling of the ICANN / Alexa pre-mining and claims names.

All of the legacy systems and operators that the handshake community keeps jiggling the doorknobs of in attempts to open doors, such as browsers, DNS resolver systems like Cloudflare or other DNS / DoH infrastructure, etc. all follow something called 'ICP-3' in order to not get drawn into namespace collisions that would degrade their customer experiences.

The ability to identify that there are NO conflicts with ICANN TLDs is not possible in the presence of the collisions like .music, .spa etc conflict strings that were missed by the founders. Chosing to leave this situation as-is leaves this project toxic to institutional players' perception and adoption. It shouldn't have been possible for these to happen, and yes there are now auction winners, but doing nothing about these conflicts hobbles the entire project adoption and acceptance pace.

That said, the ICANN TLD conflict issue and the Unstoppable domains conflict are really entirely different matters, which should not be conflated.

In the case of the ICANN conflicts, the Handshake founders made mistakes on what they included when attempting to proactively protect the ICANN namespace. They just didn't know about the conflicted applications because they didn't know what they didn't know about the domains in the 2012 Round that were applied for and missed some which were tied up in the contention period. They were applied for in 2012, and "existed", but had not been added to the root. The founders just took a snapshot of the root zone, which was a decent solution but not the right one.

The important thing to consider is that ICANN did not introduce conflict after Handshake launched, Handshake created the conflict due to lack of understanding of what it was doing, and there's loads of public information to support this.

In the case of Unstoppable names like .crypto or other types of later 'entitlement' scenarios that exist outside of ICP-3 or that were created later than 2012 are not hobbling acceptance for handshake.

[pinheadmz]

@dnsguru

there's loads of public information to support this.

I would like to see the public information that supports your accusation that the founders' design was negligent or ignorant or a mistake.

The public information that I can see is:

• A bunch of Handshake code that relies explicitly on DNSSEC signatures by ICANN
• A list of names signed by ICANN

The public information I do NOT see is:

• A verifiable signature by ICANN for the name .music in the IANA root zone

[dnsguru]

Taking the 'where was the DNSSEC signature in the root at time of bootstrap' perspective, it leaves the conflict with strings from the 2012 round that got us into the 'This project has conflicts' mess that's hindering adoption of Handshake with larger institutional players.

The objective I have held, throughout the discussions on the conflict TLDs, is that I witness all to often folks hitting their head against walls on why provider X is not adding handshake. The TLD conflict issue contributes to the institutional player adoption in a large way and cannot be ignored. If the community entrenches on this for the benefit of a few, the entire project shares the cost in adoption pace.

There was an attempt at dealing with the conflicts so that the project was immune until later TLD rounds at ICANN would be when the conflict might surface, which has lived at a perpetual 18-36 months from when asked.

Taking the 'There was an attempt' perspective on identifying strings in conflict with the ICANN universe and including them in the bootstrap, you can see that there is effort in identifying strings to set aside as architectural decisions based upon understanding of the ICANN TLD system.

Example: There was no DNSSEC signature for .invalid or .example in the IANA root zone, but these were set aside as 'ICANN Reserved' in list 1.

Someone with an understanding of ICANN in 2020 would have qiuckly identified the applied for strings and contention sets from the 2020 round as being 'pending', and blocked them with as much or less effort as it took to block any of the pseudo-TLD projects in list 2. When I say mistake or ignorance I am not suggesting nor implying incompetence or negligence, it just is abundantly obvious that someone with the lightest knowledge of ICANN TLDs would have caught the gap, which appears to have been overlooked.

But I do see that some community members comment about ICANN adding .music or .spa or .kids after handshake launched, and that kind of oversimplifies in a way that distorts the timing aspect. These all existed after technical, financial and other reviews that were conducted between 2012 and 2014, but most importantly ANY and all gTLD strings from the 2012 round were cast almost 10 years ago, and there have been a straggling few that had a longer journey that are in this conflict with handshake TLDs.

The public information about the 2012 round TLDs is here: ICANN new gTLD Application Status, where there were no less than 10 applications that were successfully evaluated for .music (choosing that example, but for each of the other contention sets there were likely >1 applicant or issues to address such as Amazon faced with .amazon and the river region gummints on .amazon et all IDN variations). These all were 'existing TLDs', but undelegated.

The logic of the Bootstrap didn't state 'only those with DNSSEC signatures in the IANA root', it stated 'existing TLDs'.

The two perspectives overlap and conflict on a short list of names. It is very important to recognize that these TLDs in question DID exist within the world of ICANN prior to the conception of Handshake, and ICANN did not 'create them' after Handshake was launched. The TLDs in question had been created by applying for them in 2012, and they already existed, but in a delayed state before being added to the root zone.

Clearly there was an attempt to make a list of strings to block based off more than just DNSSEC in IANA root. It really should not have been possible for the conflicting list of TLDs to exist in Handshake for these were the 'existing TLD' list assembled by someone with awareness of ICANN system that they were designing bootstrap on.

It is up to the community to decide between these paths. Do you want to opt for protecting a few strings at the expense of hobbled/slower institutional provider support, or do you want to remove a significant barrier to adoption at the expense of a few strings?

[Falci]

Shall we follow @evbots' suggestion?:

I do not think we should use this thread to hash out other ideas we want to bundle with this proposed hard fork. Those ideas should have their own threads associated with them.

If you posted in here some extra suggestion, first: thank you. But could you create a new issue instead?

Don't see it as censorship but cleaning the extra suggestions would make it easier to comment here. Please :)

[dnsguru]

Et Viola, #649

[faltrum]

I'm in favor to extend the period to 8 years to facilitate the adoption. I'm against to include more TLD in Alexa 100k. Thnks

[Falci]

Random idea: what if we update the Alexa 100k list?

For sure the list won't be the same. Some new domain in, some old domains out.
Almost sure the new domains in have their HNS names already auctioned, nothing we can do about them.
However, the names that are NOT in the "new alexa 100k" AND are not yet claimed could be removed from the reserved list.

[hnshnshnshns]

Most of the names that haven't been claimed are of high value to web 2. if they know about hns, that would be a big deal, put blockchain domain names get more practical.

mainly with the claimed names, it made the web2 domain auction community attracted by hns, domain name speculators, etc., they are quite important to the domain name ecosystem. cocacola , pepsi, they all love web3, web 3 domain, but they still don't know they can claim their rewards.

I like how Balaji looks at HNS, an ID. a company like tesla might have bob's employee profile at bob.tesla , or if twitter claims their domain, something big will happen...

[pinheadmz]

I've written a draft HIP for a hard fork to extend reserve name claim period: handshake-org/HIPs#50

TLDR: https://github.com/handshake-org/HIPs/blob/0e64ddb761c2bf66c44006be081472262fefd70d/HIP-xxxx.md

I think debate about whether or not this HF should be deployed can continue here. If you want to comment or make suggests on the existing proposal, that can be done in HIP PR above.

[Hassanaboulhoda]

Beside extending the claim period, I suggest to freeze the claimed $HNS from being traded for another couple of years.