ICANN TLDs will become available for auction at block 210240, around January 31 to February 2, 2024. As there's interest in preventing ICANN TLD trading on chain, we need to either completely disable claims and permanently seal reservations (soft-fork), or extend the claim period for these reserved names (hard-fork). Names on the reserved list fall into several categories: ROOT (ICANN TLDs), TOP 100 (Unique 54), Custom (Unique 25), and Others. To gain a clearer understanding of the situation, we present the statistics of the claims on the network. Calculations are based on the unique list; entries falling into other categories are disregarded. Entries that belong to multiple categories will be grouped into the first category they fit into, in the following order:
| Bucket Name | Claimed | Unique Total |
|---|---|---|
| ICAN TLDS | 5 | 1,516 |
| TOP 100 | 1 | 54 |
| CUSTOM | 9 | 25 |
| Others | 4,825 | 88,448 |
Some examples from unclaimed names for each:
- ICANN TLD:
"nec", "cern", "claims", "cafe" ... - TOP 100:
"pinterest", "tribunnews", "bilibili" ... - CUSTOM:
"ubuntu", "icann", "blockstack", "cloudflare" ... - Others:
"123openload", "sungshin", "zonegfx", "openclassrooms" ...
The critical issue of preventing TLDs (and top100/custom names) from being auctioned can be resolved either through a soft-fork or a hard-fork. Here's a brief summary of what each type accomplishes.
A soft-fork will permanently disable TLDs, top100, and custom names. After January 31, they will no longer be available for claim or opening, effectively locking or sealing them. Implementation: handshake-org/hsd#819
A hard-fork will extend the claim period for TLDs, top100, and custom names by
four years, while allowing all other categories (OTHER) to be auctioned. After
these four years, we will still need to implement a hard-fork or a soft-fork.
What happens after this period can also be included in the hard-fork plan, such
as a lockup scenario.
Draft Implementation: https://github.com/pinheadmz/hsd/commits/thumbwrestle-1
As previously mentioned, a soft-fork will permanently seal the TLDs, top100, and custom names. They will not be claimable (as they would typically become once tradable), nor can they be opened for auction. Upon activation of the soft-fork (BIP9), the OPENs for the reserved names will become illegal and will not be accepted in the mempool once the claim period ends. Blocks containing OPEN of these names will also be considered illegal. Note: Claims will also become illegal as they are no longer "normally reserved" as per usual rules. Names that have been claimed, but have expired or been revoked will also become locked.
-
Pros:
- Only miners need to upgrade (and BIP9 tries to ensure they do).
- Wallets, SPV nodes, and HNSD do not need to upgrade.
- Wallets won't need to upgrade; they only need to be aware that transactions OPENing those names will fail in the mempool and block, which may cause them to get banned from the nodes.
- Only miners need to upgrade (and BIP9 tries to ensure they do).
-
Cons:
- The names can no longer be claimed on the network and are sealed permanently.
- There's a risk of activation failure, so names may end up being auctioned.
A hard-fork allows us greater flexibility with consensus rules. Instead of permanently sealing the names, we can grant TLDs, top100, and custom names additional time to claim their names on the network. We could also add a failsafe for sealing/locking these important names after four years (not part of the current "Thumb Wrestle" proposal). The current hard-fork implementation/proposal does not use BIP9 (which is generally intended for soft-forks) to signal the miner state. Therefore, I believe it would be a necessary addition to have a soft-fork BIP9 signal to activate the hard-fork. If the signalling fails, the hard-fork won't deploy. The hard-fork proposal has other security measures that are separate but carry different consequences. Because of this, instead of discussing the entire hard-fork, we will present a more detailed pros and cons list per feature.
-
Extending Name Claims
- Pros
- This allows name owners an additional four years to make claims.
- We could also add a safeguard to lock them up when that time expires.
- Cons
- Every miner and full node needs to upgrade.
- Pros
-
Light Node Fork Detection allows light clients, such as SPV or HNSD, to choose which network to follow and whether or not to accept a new fork.
- Pros
- Allows greater control for light clients.
- Cons
- All full nodes and light clients (SPV, HNSD) need to be updated to support hard fork detection using Name Set entries. Otherwise, they will follow the old chain. Essentially, every application needs to upgrade.
- Pros
-
Replay Protection allows for safer chain splits, where a transaction sent by old clients on the old chain cannot be copied and replayed on the hard-forked network.
- Pros
- This protects users from accidentally spending money on both chains instead of just one.
- Facilitates future hard-forks, as future hard-forks will already have this feature available and can use it for another hard-fork.
- Cons
- Every full node, light node, and Signer implementation (like LEDGER) will need to upgrade the code because it changes the transaction serialization. Essentially, anything that creates or verifies signatures needs to be updated.
- Pros
-
BIP9 (not part of the draft implementation) will provide a better way to monitor the state of the deployment and allow it to fail if miners do not upgrade in time.
- Instead of an unfavorable split, activation fails if not adopted in time.
The general drawback of the current hard-fork is that every project and every code will need to be upgraded. Depending on which parts we omit from the implementation, this requirement could be lessened. For instance, if we decide not to implement replay protection and accept the associated risks, Ledger and other signer implementations won't need to be upgraded.
handshake-org/HIPs#50 I am curious with this work how far off we really are from a hard fork to extend ICANN etc 4 more years and drop the Others into the auction poll. Maybe we could adjust this and move forward faster?