Enabling .BCH domains similar to .eth with ENS

I notice that .ETH (using Etherum Name Service) domains generate billions in trade value. Would it be feasible to include .BCH (BCNS?) support next upgrade to enable domain.bch in a similar way?

Apologize for any possible technical misunderstanding on this topic.



Interesting idea. You need to campaign for it more to bring it to public attention. I remember one Hackathon project that worked on it.

As I see it, the idea to add name resolution capabilities to BCH may be motivated by:

  1. In case BCH stagnates in popularity: it becomes addamant to add more features to attract users.
  2. In case BCH is already popular enough but has room to scale more: it may provide additional services, like name resolution. By adding new services it only improves the health of BCH by making it even more demanded and liquid. It makes BCH more competitive against alternative coins with name resolution.
  3. Improving the technology and UX of existing decentralized name resolution systems. By adding this feature, the technology itself may be improved by BCH devs if they have better ideas. Also, by being integrated to the other services BCH offers, UX improves.
  4. Providing a more robust ecosystem for a decentralized naming system. Ad-hoc cryptocurrencies that specialize in one service (e.g. name resolution) are more fragile because they have less use cases, less developers, less network effect, less security, etc. By incorporating the service in a mature general-purpose cryptocurrency like BCH, the service benefits from the security and popularity of the network.

I believe that point (1) will not be the case. There are many use cases that BCH can tackle that are of interest to current developers. Only in the event that developers run out of ideas to implement and those becoming unsuccessful would such a necessity of adding name resolution exist. And if that is the case, name resolution only will not save BCH.

Point (2) is quite plausible if it becomes apparent that users stop using BCH because they go to another coin which offers the same use cases plus name resolution.

Points (3) and (4) are of interest to those that care about name resolution. Right now, such users and developers are satisfied by systems such as Namecoin or ENS.

So, I don’t think this is going to happen in the near future. Such a system would be useful for things like mapping names to BCH addresses, but this is already covered by CashAccounts and CashID with a decent enough UX.

I’m writing another comment to give my opinion on current decentralized naming systems.

One thing I do not like about ENS is that it is not truly decentralized since the root is owned by a 4-7 multisig address, which controls all the system. Moreover, ENS scales poorly because it uses smart contracts.

I would instead suggest looking at Namecoin as inspiration, because it is fully decentralized and its codebase is the most similar to Bitcoin (what with being the first altcoin based on Bitcoin). It scales much better since names are just stored in the blockchain.

More differences between the two can be found here.

Now I’m going to mention two potential issues I see with Namecoin.

1. Squatting

These systems suffer heavily from squatting, especially Namecoin since it never had a benevolent dictator, like ENS.

Namecoin names are acquired by making a claim to an unowned name and paying a miner fee; the name is disclosed after it has been mined, otherwise miners would abuse the system. This system is first-come-first-served, which causes high rates of squatting. The mining fee is flat, that is, the fee is the same for all names.

After acquiring a name, the user owns the name forever, and he must renew his ownership once a year or so, by paying another fee. This serves as a recovery mecanism in case the user loses his private keys: if the user does not pay the fee after a year, the name becomes unowned again and up for grabs. Someone may acquire an owned name by buying it from the owner using an exchange.

I’m not that much against squatting: squatters at some point want to make a profit, so they’ll end up selling some of the names at some point.

But maybe there are other systems of name acquisition that have a fairer distribution.

One such system could be by staking and auctioning, instead of paying a flat fee:

  1. Bob stakes an amount of money toward an unowned name; this starts an auction for the name.
  2. The network notifies that this name is being auctioned. The auction lasts a certain time (eg 1 week).
  3. During the auction, any user may offer more money for the name. In that case, the time for the auction resets and another week must pass before the auction finishes.
  4. After noone has made a higher offer during the auction, the name is given to the last bidder, say Alice, and she cannot sell the name for some time or freeze period (eg 1 year).
  5. After the freeze period, Alice may decide to sell the name. Until she sells the name, Alice cannot recover the staked coins.
  6. From here it gets more complicated, as incentives must be taken into account. Should the new buyer be required to stake coins to the name? Which amount? How is renewal made?

This has the advantages that the barrier to purchasing a name is increased by the demand the name has, so squatting is reduced for popular names.

The drawbacks are that it is a more complex system, the auction process is less straightforward for users buying an unowned name, and the incentives are more difficult to follow (if Alice sells the name to another address owned by herself, and no new stake is made, then she did not lose money, only money was freezed for some time).

I think I prefer the flat fee unless someone finds a simple enough but less squatty alternative.

2. Name spaces

The content of a Namecoin name may include IP addresses, PGP public keys, onion site addresses, etc. This allows the same name to have multiple attributes to be used by different apps. However, to allow different users to own the same name but for different purposes, the concept of name spaces was introduced in Namecoin. Name spaces are top level names that are permissionless, cannot be owned by anyone, and in different name space the same names may be owned by different addresses.

By default, when a user acquires a name it belongs to the name space /id/. Alternative name spaces come into existence when a user explicitly chooses it when acquiring the name.

I would propose a different design however: instead of allowing top level name spaces, there would only be plain names at the root.

The names would be more powerful though: they would contain attributes (as they do now) but also other names, converting any name in a sort of directory, and creating an infinite hierarchy.

In the following Namecoin example, name spaces are indicated by /…/, names are in the next level, and each name has several attributes indicated by x: …

There are two different Alice in this example.

/id/ [unowned]
    alice [owned by the first alice]
        ipAddress: ...
    bob [owned by bob]
        pgpPK: ...
/n/ [unowned]
    alice [owned by the second alice]
        bchAddress: ...

In my proposal, this would become:

alice [owned by the first alice]
    ipAddress: ...
bob [owned by bob]
    pgpPK: ...
n [owned by the second alice]
    someOtherAttribute: ...
    alice [owned by the second alice]
        bchAddress: ...
        webSites [owned by the second alice]
            ipSite1: ...
            ipSite2: ...

In the Namecoin approach, the second Alice must:

  1. Check her desired name, and once she sees that it is owned in /id/, choose a different name space /n/.
  2. Acquire the name “alice” in the /n/ name space.

In the hierarchical approach, the second Alice must:

  1. Check her desired name, and once she sees that it is owned, she must acquire any name available, for example “n”.
  2. After acquiring the name “n”, Alice may acquire the name “alice” inside of “n”.

The second approach requires 2 purchases, but the result is the same: someone else could have already owned /n/alice in the first (name-space) approach. The requirement of buying “n” does not decrease the chances of the second Alice getting the name “n/alice”.

By allowing hierarchical names, this opens several possibilities: a project may buy a name “bchGame”, and then it may sell any name inside “bchGame” because the project owns the top level name. The conditions of selling could be permanent or just a lease. This allows creating and managing separate ecosystems and networks fully in control of the owner of the top-level name.

The limit in the number of names that there can be in the same level is determined by the allowed name size. Thus if the maximum size is large enough it would still not be difficult to find a random unowned name to then buy the desired name inside of it.

Worth mentioning:

Namecoin and ENS provide naming systems for what I call “brand names”, that is, names that must only have one meaning and that represent a user or entity uniquely.

However, there are other cases where multiple meanings for the same name are desired, which I call “common names”. Let’s say that I want to implement a decentralized wikipedia. The name “BCH” may have different articles written by different authors. So, when a user searches for “BCH” it can read different viewpoints, without censorship.

Another use is when searching for a file to download, for example the book “the bible” (this surely doesn’t have copyright). The results of the search might show several available files, all with the same name, and the user must choose one of them.

In order to disambiguate among the multiple results, users would vote by staking money in the result they believe is the most accurate, and when searching one would choose the result with the most staked money. Also, by incorporating a web of trust, a user would find which votes are more trustworthy.

More over, one can give additional names to the same file, even if they do not own the file, thus working like tags.

This is exactly what the LBRY blockchain does (except for the web of trust I believe). Its code is based on Bitcoin, so adding such features to BCH is certainly possible.