How long should gTLDs be reserved?

[pinheadmz]

Issue: Reserved names are ONLY claimable by their legacy owners for 4 years. After that, any Handshake user can OPEN an auction and acquire a previously-reserved name. For names like Facebook that might be ok, but is it ok for global TLDs like com? gTLDs are perhaps too important to risk a malicious name owner from acquiring them.

One solution, implemented in #256 keeps gTLDs reserved forever, meaning they can ONLY be claimed by legacy owners (at any time in the future) and can never be OPENed by arbitrary users.

Another solution proposed by @kilpatty would be to modify the rules surrounding CLAIMs and OPENs, such that the "4-year" constant could be changed by a soft fork. Currently there are two rules involved, making any change to the claimPeriod a hard fork in the context of at least one of these rules. An implementation of this solution (for example) would prohibit CLAIMs if a name has already been OPENed, and then the soft-forkable rule would be a limit on when OPENs for reserved names are allowed on chain (increasing the limit from 4 to 10 years would be a soft fork, old nodes wouldn't care that no OPENs have showed up).

There is additional discussion on #256 and we can ACK proposals here, or come up with new ideas.

[rsolari]

ACK the soft fork proposal.

I think it makes sense to reserve TLDs for a while – say 4-10 years – but not forever. Reserving for a finite amount of time gives TLD owners an expiring incentive to claim their name if Handshake DNS is promising.

If Handshake DNS does not take off, but some other application does, then future Handshake stakeholders should decide whether it makes sense to keep the TLDs reserved.

[turbomaze]

Just to share an alternative I mentioned earlier today, we could also forever allow TLD owners to claim their names. There is no legitimate reason for a non-TLD owner to ever control an ICANN TLD on Handshake. That said, I like the optionality that comes with changing the rules to permit a soft fork in the future. I'd also want the 4 year timeline to be lengthened for TLDs though since I don't think 4 years is enough time to decide if Handshake should pivot away from DNS. 10 years sounds better

[pinheadmz]

As requested in the recent dev call, here's an illustration of the issue and how it can be addressed:

Current Consensus

Rules:

// lib/covenants/rules.js

rules.isReserved = function isReserved(nameHash, height, network) {
  assert(Buffer.isBuffer(nameHash));
  assert((height >>> 0) === height);
  assert(network && network.names);

  if (network.names.noReserved)
    return false;

  if (height >= network.names.claimPeriod)
    return false;

  return reserved.has(nameHash);
};

Enforced:

// lib/blockchain/chain.js 

  async verifyCovenants(tx, view, height, hardened) {
	...
      if (covenant.isClaim()) {
       ...
        // Can only claim reserved names.
        // Once a reserved name is revoked,
        // it is no longer claimable.
        if (ns.expired || !rules.isReserved(nameHash, height, network)) {
          throw new VerifyError(tx,
            'invalid',
            'bad-claim-notreserved',
            100);
        }
        ...
      }      
      
      
      if (covenant.isOpen()) {
        ...
        // Cannot bid on a reserved name.
        if (!ns.expired && rules.isReserved(nameHash, height, network)) {
          throw new VerifyError(tx,
            'invalid',
            'bad-open-reserved',
            100);
        }
        ...
      }

Meaning:

The mainnet claimPeriod is about four years. A legacy name owner can CLAIM their name on the blockchain up to this time limit. After that time limit, all CLAIM covenants are invalid, will be rejected by all relay nodes, and be illegal in blocks. At the same time, an OPEN covenant for a reserved name will be exactly as illegal up until the time limit. After the time limit, anyone can OPEN an auction for a formerly reserved name.

Proposal 1: Reserved names are always reserved

Implemented in PR#256. Change rules.js such that isReserved() ALWAYS returns true for gTLDs (like com, org, etc.). This will not affect other reserved names like facebook, bitcoin, etc and all the current rules will still apply to those names. Note the in the reserved names list, gTLDs are marked so they can be filtered out.

Proposal 2: Enable a future soft-fork to extend the deadline

Discussed in Issue#301. One issue with the current rules is they can not be changed without a hard fork. Specifically because CLAIM is only allowed before and not after the deadline, meanwhile OPEN is allowed after the deadline but not before. That means that if the value of claimPeriod is changed, even by one block, a network split would occur. Consider this timeline if a set of nodes decide to push back the deadline 1 extra year (to 5 years):

chain height	legacy node, current rules	updated node, limit + 1 year	network state
3 years	CLAIM allowed, OPEN forbidden	CLAIM allowed, OPEN forbidden	fine
4.5 years	CLAIM now forbidden	CLAIM still allowed	fork!
4.5 years	OPEN now allowed	OPEN still forbidden	fork!
5 years	CLAIM forbidden, OPEN allowed	CLAIM forbidden, OPEN allowed	fine but by now we've forked.

The same kind of hard fork would occur if the deadline was moved up (say to 2 or 3 years).

To make this soft-forkable, changes would have to be implemented in chain.js:

• Rejecting OPEN before the deadline would remain a rule
• CLAIM would ALWAYS be valid UNLESS a name has already been OPEN

Now the situation for reserved names looks like this:

chain height	namestate	covenant	valid?
3 years	NONE	OPEN	INVALID
	NONE	CLAIM	VALID
	CLAIMED	OPEN	INVALID
	OPEN	CLAIM	INVALID
4+ years	NONE	OPEN	VALID
	NONE	CLAIM	VALID
	CLAIMED	OPEN	INVALID
	OPEN	CLAIM	INVALID

And the network fork would be SOFT:

chain height	legacy node, soft fork rules	updated node, limit + 1 year	network state
3 years	CLAIM allowed if not OPEN	CLAIM allowed if not OPEN	fine
3 years	OPEN not allowed	OPEN not allowed	fine
4.5 years	CLAIM allowed if not OPEN	CLAIM allowed if not OPEN	fine
4.5 years	OPEN now allowed	OPEN still forbidden	fine majority of hashrate reject OPEN in blocks, old nodes don't care, those blocks are still acceptable
5 years	CLAIM allowed if not OPEN	CLAIM allowed if not OPEN	fine
5 years	OPEN now allowed	OPEN now allowed	fine majority of hashrate now includes OPEN in blocks, old nodes jsut had to wait, but accept these blocks

Proposal 3: Hybrid

Another discussion has taken place offline evaluating the possibility of combining these two concepts. The result would be a soft-forkable OPEN time, but still preventing gTLDs from ever being OPEN.

[turbomaze]

Thanks for such a thorough description of the problems & potential solutions! Makes it very clear.

Handshake is currently all about DNS and the root zone, but in the back of our heads there are all these other potential uses for human readable names + highly available 512 bytes. The DNS use case is the largest though, so I think we should take steps that maximize the chance of success for that use case.

To that end, we've chatted with misc DNS folks/browser engineers/etc, and they're highly sensitive to any potential conflicts between Handshake and existing TLDs. The thought that in just 4 years a random person could register .com on Handshake is a tremendous concern. Even if you believe that Handshake should pivot away from DNS if the DNS use case does not take off within n years, and thus, ICANN TLDs should not be reserved beyond n years, there is short term value now for the DNS use case in signaling that these ICANN TLDs will be reserved forever.

By my calculations utility(reserving ICANN TLDs forever) > utility(opening up 1000 additional names for registration in n years). I like your hybrid solution (proposal 3).

[pinheadmz]

See #301 (comment)

This issue will not be addressed at this time.