ECIP-?- Ethereum Classic Naming Service (ECNS)

[Dexaran]

There will be an Ethereum Naming Service (ENS) launched soon. I will deploy and support ENS contracts on EthereumClassic mainnet as soon as finaly ENS version will be released. I think it is needed to be done. There will be no serious changes in ENS contracts but there also need to be a UI ECNS lookup realization.

Here you can read more about ENS

[arvicco]

This is a good idea. Immutable public infrastructure like ETC should be a good option for deployment of name services and registers of any sort. I guess we need to bring in EIP137 and EIP162 into ECIP system as part of such effort?

[arvicco]

Natural choice for top-level domain would be .etc, for obvious reasons. Any other ideas?

[Dexaran]

Agreed. As Ethereum is using .eth we can use .etc I don't think it's needed to bring EIP137 and EIP162 to discuss here. I will just implement anything they decide to do. If you have any suggestions/proposals about ECNS you can describe them here. But I don't think there need to be any difference between ENS and ECNS. It will make any implementation of both name services easier for third party developers working with this name services. The only thing I'm worried about is ENS contract is burning paid Ether. As long as ETH emission is unlimited there are no problems here but ETC is hard capped.

[Dexaran]

ENS is preparing to be launched. I'm watching progress. Some more details: https://medium.com/the-ethereum-name-service/updated-ens-now-deployed-on-ropsten-testnet-ffc2c4a8a99e

[bibboyne]

While I like .ETC as a top level domain and there is nothing wrong with using it, we could be limiting the adoption of our ENS service to only businesses that favor the Ethereum Classic. We need a more generic name that people and businesses can use to better represent themselves or the nature of their businesses.

Ethereum picking .ETH as their top level domain might seem ideal at first glance, it is actually their biggest mistake, one that we can take advantage of. We can beat them in their own game by offering a top level domain that represents the cryptocurrency market as a whole so that any Fintech company can use without having to associate themselves to a particular cryptocurrency.

For example, we have Joe here who runs a Fintech-related business and is looking for a suitable domain that best represents the nature of his business but does not want a traditional .com domain. Here we have the Ethereum ENS offering .ETH domains and the Ethereum Classic ENS offering .FINTECH domains, It only makes sense for him to choose a .FINTECH domain over .ETH because it widens the representation of his business.

.FINTECH is just an example. What if we could offer multiple top level domains through the ETC ENS? What if we offer not only .ETC domains but also other meaningful domain extension names like .FINTECH or .BLOCKCHAIN domains? We do this now before Vitalik or any other crypto and we will have all the great extension names under our belt and naturally become the new Network Solutions. The ENS that Dexaran creates could harbor huge potential but only if we are bold enough to think big and act fast.

[sorpaas]

I'm worried that those name (.FINTECH, .BLOCKCHAIN, etc.) may conflict with ICANN's gTLDs. While technically ECNS and DNS are totally different things, a user might use them in similar ways. Even for .ETC, to prevent it from being used as a traditional top-level domain, we might also need to submit something similar to RFC 7686.

[bibboyne]

If the ENS maintains its own registry, I don't believe we are subjected to ICANN's consent in my opinion. Having said that, I do agree that we should not deliberately pick any ICANN-conflicting gTLDs, as well as any trademark names like .google or .apple.

What needs to be done now is for the ENS devs to determine the feasibility of offering multiple TLDs through the ENS. Then get a consensus with everyone involved in the project to agree on the feature and propose a list of ideal TLDs.

[etclabrat]

Shouldn't copy ENS, because ENS is a shit. Few people control it and can undelegate domains. Blind auction makes possible to catch over domain by one with big cash. Bids are unknown, but domains are visible.

For Ethereum Classic, to create a similar naming contract with another TLD is not a good way. Much better is to create naming standard and API like the token standard ERC-20. Anybody can create naming contract with it own name registration rules and all names can be readable by the same API. And for TLDs for these contracts shouldn't assign by a contract, because every contract registration is unfair. TLDs should be assigned manually by usage practice like .onion, .i2p, .bit, .eth, .etc.

[Dexaran]

Much better is to create naming standard and API like the token standard ERC-20.

The ERC20 token standard results in a loss of $ 320,000. It seems that it is not good.

And for TLDs for these contracts shouldn't assign by a contract, because every contract registration is unfair. TLDs should be assigned manually by usage practice like .onion, .i2p, .bit, .eth, .etc.

For what reasons? How will UIs work with it? I think that the existence of only one TLD will simplify the use of name services a lot. For example, if .etc is for ETC and .eth for ETH, then MyEtherWallet can simply verify which chain the user is going to use.

[Dexaran]

To make it clear: I don't like blind auction model. I have also changed some things inside ENS contract already.

I want to create a very similar contract that will simplify the interaction with ENS and ECNS for user interfaces that support both ETC and ETH chains. A similar domain distribution model will allow reference to the ENS documentation and simplify the interaction with both naming services for ordinary ETC and ETH users.

If someone thinks that it would be a good idea to make more valuable changes to the Ethereum Classic Naming Service, then I think that it should be a new naming service, and we can create a new ECIP and discuss it there. I'm ready to create the third naming service for ETC if it will be needed. This is my opinion.

[Dexaran]

I've updated ECNS contract. This is current version that is exactly deployed on Rinkeby testnet: https://github.com/Dexaran/ECNS/tree/test

Native 'namehash' algorithm implementation is added to ECNS registry contract.

The main problem is the excess of the block gas limit. I can't attach any extra debugging functions and emergency ERC20 token extraction function due to 4,7MGas limit.

[Dexaran]

Updated a contract: https://github.com/Dexaran/ECNS/blob/test/HashRegistrarSimplified.sol

Emergency token extraction function was implemented. Dynamic min node price was implemented.

I'm thinking of implementing this functions for multisig that will be owner of root node:

1. Changing of total auction length.
2. Changing of reveal period.
3. Changing of address where the funds would go.

If you have any valuable arguments for implementing any of this functions I'm ready to discuss it.

[Dexaran]

7 easy steps to set up your own ECNS (or ENS):

1. Deploy a Registry contract. You will be the owner of the Registry (owner of 0x0).
2. Deploy a String Library. These functions were extracted to a separate contract due to excess of block gas limit.
3. Choose a root Node (top level domain). Call namehash(string rootNode) at ECNS (there is a native implementation of NameHash algoright in this contract). NOTE: ".etc" root Node is namehash("etc"); wich is equal to 0x2f142013fcc88d47bffe42e5d883f6081cbaa75abaa20e7f34f3043bbc8162c9 Not sha3("etc");
4. Enter root Node and addresses of recently deployed Registry and String Library into HashRegistrar Template contract and deploy it. The Registrar Template is necessary for the process of the base Registrar operation, since the Template contains function codes, which will be exactly executed through delegatecall from the base Registrar. WARNING: Registrar Template should never be executed. It is just container of the code that will be executed via delegatecall from the real Registrar.
5. Enter root Node and addresses of previously deployed Registry, String Library and HashRegistrar Template to a HashRegistrar contract. This Registrar will be a top level domain resolver. All nodes will be registered through this contract at auction.
6. Now you must make the base Registrar the owner of the root Node. Call setSubnodeOwner(bytes32 "", bytes32 sha3(string rootNode), address _registrarAddress); NOTE: You should enter an empty node because of "top level domain" will be a subnode of empty node. You should enter a sha3 hash of choosen root node as label. For example for etc you should enter sha3("etc") wich is 0x997997d543f68c7b77e62a13efc6e546bd2a81c2aa8769c3354422ebbbb4fba4.
7. Now you should check if the Registrar is now an owner of the root Node. Call owner(bytes32 rootNode) at ECNS. If the ECNS is returning the address of Registrar contract then everything is right. NOTE: You should use namehash of root Node at this point. 0x2f142013fcc88d47bffe42e5d883f6081cbaa75abaa20e7f34f3043bbc8162c9 for .etc

EDIT: Deprecated! Contracts are now upgraded and will be deployed on Rinkeby for testing soon.

[Dexaran]

Under bug bounty: https://dexaran.github.io/EthereumCommonwealth/Bounties/#marker-bounty-3

[Dexaran]

ECNS is successfully launched at Ethereum Classic network. https://github.com/EthereumCommonwealth/ECNS