ERC: Default Ethereum Name Registrar

[alexvandesande]

  ERC: 26 (based on issue number) or 3 (based on ERC)
  Title: Default Mist Name Registrar
  Author: Alex Van de Sande (avsa@ethdev.com)
  Status: Draft
  Type: Informational
  Created: 20-11.2015

Abstract

An important aspect of making ethereum Ðapps easily accessible is a name registry that will connect a human readable name to a hash for usage in IPFS/SWARM or any DHT system.

The name registrar is not meant to be the one and only name registrar on ethereum but rather a default registrar to be used by Mist to resolve names. It will be an user configurable setting.

Motivation

The goal of this contract is:

• To find the optimal price for names: create a strategy where the nash equilibrium for each player is to simply put down the maximum amount they are willing to pay for a name, and not create incentives for names to be overpaid
• To allow optimal usage of names: allow good names to circulate among those who want have better usages for it, while keeping smaller brands reasonably protected
• To make name markets as transparent as possible. Currently domain squatting is a very sneaky business that utilizes information asymmetry to sell names. This proposal, while still allows names to be sold or transferred outside this market, will create a last resort market where name prices are transparent and optimal
• Registering names should have an optimal cost, cheap enough to be inclusive, but not too much to allow excessive name squatting. This intends to describe the design and parts of the proposed system.
• Privacy by obscurity: give unpopular and niche domain holders a reasonable privacy expectation while making the most popular names evaluations transparent. Creating a spider that crawls all name markets is exponentially expensive.

  Specification

The system will consist of 4 main parts:

Hash Registrar

The registrar itself is the contract that stores the basic data. If more data is needed it can be stored in other contracts, using this one as the reference. It doesn't use the name directly to reference the registry but its data. Keeping the names as hashes instead of plaintext has two advantages: first it allows privacy by obscurity, meaning that if the name isn't known enough to be in a rainbow table then you can't really know who the information is about. Second, it allows a more general purpose and future proofing use of the contract, as it can be used to claim ownership on anything that can be translated into hash, like devices, files, texts and other uses we haven't thought about now.

function getAuction() constant returns (address auction)
function getElection() constant returns (address election)
function getCollector() constant returns (address collector)
function setCollector(address _newCollector) returns (bool success)

The registry is set at startup with the address of three other contracts, the Collector contract, Election Contract and Auction contract, that have special rights. Only the Election contract can change the collector. The others are unchangeable.

function getRegistry(bytes32 _hash) constant returns (address _owner, uint _renewalDate,  uint feesPaid, string _redirectAddress)

It uses a hash as an index and attributes these informations to it: an address that owns it; the expiration date of the registration; the amount of ether that the owner effectively paid to the registrar address as the process of renewal; a string which is the http, buzz or ipfs address of the app.

Other contracts might extend this functionality by simply creating a registry of extra information about a hash and then only allowing edits to it by checking this master contract for the owner address. For example, the wallet app might want to make a registry where a name is associated to an address (different from the owner), or if you want to have a secondary content hash for http links then a secondary contract could be deployed, only allowing edit access to the addresses on marked as owner on this contract.

function editRegistry(bytes32 _hash)

All the information on that hash can be edited by the owner of the address up to 48h before the renewal Date, and at that time the information is locked. After the expiration date, only the Auction Contract can change the owner of the hash.

function newRegistry(bytes32 _hash, string _redirectAddress, address _owner)

Only the Auction Contract can add new registries.

function ()

All funds given to the Registrar contract are redirected to the Collector Contract. These will not count towards the feesPaid.

function invalidateEntry(string _name)

The disadvantage of hashes as identifiers is that it literally allows anything, therefore making it impossible to create restrictions such as "names shorter than 6 letters can only be registered after 2017". This could be avoided by creating validity rules that need to be reported and if true will delete the entry, but this would require all those rules to be set at the first setup. Another way to do it is to grant the Collector Contract power to invalidate entries, but this would open the possibility of an evil collector contract censoring entries. Another solution is simply to allow any entries, but simply enforce those rules on the client: mist could be programmed to look at other contracts for special names

I'm open to more elegant solutions.

Auction Contract

The auction contract is set at startup of the Hash registrar, but since they are separated it is possible to clone a copy of the registrar contract and just change these variables.

The purpose of the auction contract is to receive bids for hashes and select a winner.

function startBid(bytes32 _newHash)

If _newHash is not registered to anyone this will create a new register, owned by 0x000 with a renewal date exactly 7 days after this function was executed. This allows a short time in which a Vickrey Auction can decide who is the first owner of the name.

The cost of start a bid can be defined by the collectorContract, but otherwise is kept at free.

function putSealedBid(bytes32 _sealedBid)

A sealed bid is just a message with the hash of the bid and some ether. The amount of ether sent on this step is also recorded, as long as the time in which the bid was put. The amount of ether can and should be higher than the amount bid, to protect the privacy of the bid. For the same reason, the bidder doesn't need to be the future owner.

The collectorContract, might define a deposit value that needs to be added on top of the put, but if it doesn't implement it then it's free.

function revealBid(bytes32 _sealedBid, bytes32 _biddedHash, address _owner, uint _bidPrice, uint _duration, string _salt)

_sealedBid is the hash saved on _sealedBid _biddedHash is the hash that the bidder wants to own _owner is the future owner of the hash, if the bid is successful. The bidder and the owner need not to be the same person _bidPrice is the maximum price the bidder is willing to pay for it _duration is the length of time (in days) the owner wants to renew it for. Must be longer than 180 and smaller than 3660. If this is the first time this hash is being bidder on then the _duration cannot be longer than 366, if it has been registered before then the _duration cannot be longer than twice the length of time that has passed since it was first registered, as to avoid very long registrations during the first years.

_salt is just a random string to prevent deanonimization of sealed bids by brute force

This action can be done by anyone. If the _sealedBid doesn't match the hash of all other parameters put together then the bid is not revealed, otherwise it's saved on the revealed bids. Collection contract.

Once a bid is revealed, the proposed setup is a closed bid Vickrey auction, where the highest bidder becomes the owner but only pays the second highest bid:

• If the new prospective owner is not the current owner then his bidPrice will be the parameter on _bidPrice. If the owner is bidding to renew the name then his bid will be calculated as _bidPrice * K/ _duration. In practice this means that the owner is appraising his own name at that price and is putting down a Fee that is a percentage of the total appraised value of his name, proportional to the renewal period. That percentage is the same for all names and is decided by the Collector Contract
• If the expiration date is on the past, then the bid is deleted and the funds sent to it are sent to the Collector Contract
• Else if the duration is outside the bounds of minimum and maximum durations OR if the ether amount sent during the sealed bid isn't enough to cover his price and fees OR if the sealed bid has been sent less than 48h before the renewal period then the bid is considered invalid, it is deleted and the ether amount sent back to the bidder.
• If the bidPrice it's the highest yet then it should be saved as such and the price to be paid should be set at the asking price of the previous highest bid (or 0 if there are none). The second highest bid should be deleted and its ether sent back to its bidder. If the bid new owner is not the current owner, K is 1, otherwise (if it's the owner renewing the ownership) then K is a factor set by the Collector Contract.
• Else if the bid is lower than the highest bid but bigger than the price to be paid of the highest bid, then the price to be paid is set at the this bid asking price. This bid is deleted and its ether sent back to its bidder.

Should a bid be considered invalid if it's revealed earlier than 48h of the renewal date?

Bids revealed too early might affect the game strategy and will influence the price to be paid. In the other hand a deleted bid might mean that someone will lose his property without the correct asking price. Since losing a domain name is harsher than someone overpaying for it, then I suggest that there should not be an obligatory reveal period, only a suggested 24h window.

The collector contract can set a function that will determine a fee to be paid by the bidders, but otherwise it will default to free.

function revealBid(bytes32 _sealedBid, bytes32 _biddedHash, address _owner, uint _bidPrice, uint _duration, string _salt)

A bid can only be removed by the original owner and only earlier than 48 hours before the renewal date.

function finalizeAuction(bytes32 _biddedHash)

This action can be only executed after the renewalDate has passed. Anyone can call it, so it could be scheduled with the alarm clock.

If owner has not changed, then an amount of ether equivalent to _bidPrice/ _duration * K will be sent to the Collectors Contract and the remaining amount will be sent back to the original bidder. The amount paid will be registered at feesPaid. The renewal date will be set at the last renewal data + _duration.

If the owner has changed then amount of priceToBePaid will be sent to the previous owner, and a fee calculated by priceToBePaid * K / _duration will be sent to the collectors contract and registered as feesPaid. Otherwise a user could keep a name indefinitely by simply selling it to itself. The renewal date will be set at the last renewal data + _duration.

function cleanOldBids()

Deletes any unsealed bids that are older than the maximum duration time that any name can accept and forwards the ether to the Collector.

Collector contract

The Collector Address is an address that receives all the funds collected in auctions and has a special right to change the K factor. The purpose of the name registry auction is not to make a profit but to allow the optimal distribution of names, to prevent name squatting while still allowing cheap and easy access to registering a name. The cost of the renewal is given by the market price of the total price, divided by K. If K is too low it might allow name squatting, but if it's too high it can make keeping names too expensive.

The collector contract can also define fees related to bidding, in order to fight spam. The collector contract can determine which rules are broken in order to consider a registry invalid (short names could only be registered after a few years, etc)

How exactly the Collector contract changes the K factor or spends its funds is not defined here, as the contract itself is a changeable parameter elected by the Election Contract.

My proposal is that the first Collector contract be just a "Boomerang contract", a contract that simply keeps all ether sent to it and then send them back after 1 year. This will allow the funds to be safely kept for a period while the community build tools and DAOs for the collector contract for the first election. Since they can always elect the 0x address, then if the community wants to do so they can still vote to burn all the ether collected during the first year.

Election Contract

The election contract has the special right to change the collector address. The exact workings of the election, as well as their frequency is not yet defined here and is open to discussions.

One important issue is that it's impossible to tell which are the entities behind each name, if they coordinate with each other or if they are owned by other entities, therefore the concept of anti-sybil (and to a point anti-coercion) mechanisms does not really apply here. Also, the job of the Collector Contract is basically to define the use of it's own funds and how to raise or lower the "tax rate" on new names, therefore it's only natural that the weights of the votes should be based barely on the amount of funds each name has sent to the contract during their last renewing period.

A user that bought four names four 1 ether each and a user that bought a single name for 4 ethers have contributed the same amount to the collector contract and therefore should have the same right to decide how the funds are spent. If the system favours the former (like quadratic voting does) will stimulate users to buy tons of small names they are not going to use, a system that favours the latter will stimulate users to double bid on their own names to pay higher taxes and therefore get more voting power. Both will would be contrary to the whole purpose of the name registrar.

The suggested voting mechanism is a mix of approved voting with Liquid democracy, as follows:

function setDelegate(string32 _ownedHash, address _delegate)

Instead of voting directly, a voter instead can decide to appoint a delegate. The contract verifies that the msg.sender is the owner of the _ownedHash and then moves his voter weight ('feesPaid') to the new _delegate

function unsetDelegate(string32 _ownedHash)

The voter removes his vote to his delegate and states that wants to vote himself.

function setVote(address[] approvedCandidates)

The voter selects an array of contracts he approves for the job of Collector Contract. These remain static and can be changed anytime. If you

function tallyVotes()

Instead of a fixed election cycle, votes can be counted at anytime if someone feels voter's preference have changed enough. The cost of counting the votes is paid by the function caller. First the function will calculate the voter's weight by the sum of his 'feesPaid' and the weight of all voters that delegate their vote into him. Votes can be delegated forward a finite number of time (3, 5 or 7, depending on gas costs).

Then all addresses the voter approved will be receive an equal number of votes as his weight. The Address with a higher number of approvals will be selected as the new Collector Contract, effectively immediately.

Acknowledgements

People who contributed to this proposal, in no particular order: @nagydani & @zelig (with their research for the swarm name registrar), @vbuterin (for insights in elections), @gavofyork (who designed the first name registrar ), @yann300 and @arkpar (who implemented the current name registrar), @pipermerriam & @nmushegian (for their great insights at DevCon1) and @ryepdx (that is implementing the maker registry) and @danielnovy (auctions Ðapp at consensys)

[taoteh1221]

I agree with @JohnDorien1, and I think the Internet Domain Registry system of today's modern internet is what Ethereum should base it name registration system off:

1) Anyone can buy unregistered names, AND renew those names for a fairly low fixed price (an equation derived from average gas price over 30 days or whatever).

2) Anyone can renew those names at any time, for a maximum of 10 years into the future from the date of renewal.

3) Anyone can auction off, or sell at a fixed price, the names they own.

It works, tried and true without catastrophic issues, and has worked for over 2 decades with the Internet Domain Registry system.

[alexvandesande]

I agree. And you'll notice that the system proposed has these characteristics

1) Anyone can buy unregistered names, AND renew those names for a fairly low fixed price (an equation derived from average gas price over 30 days or whatever).

Unless two people try to register the same name at the same week, any new name registration costs only the amount of gas to do the transaction. Auctions only happen for names that were never registered before AND for names that more than one person wants to register. In this sense it will work as a slow first come first served

2) Anyone can renew those names at any time, for a maximum of 10 years into the future from the date of renewal.

Also true on this system. The name owner selects the date when they want to renew. They can pay the renewal fee for the next period anytime. Yes for the auction to work someone needs to unseal their bid before the final date but that can be sold as a service as it requires minimal trust

3) Anyone can auction off, or sell at a fixed price, the names they own.

The system allows domain transfers or sale at any point.

I believe most of the criticism is an UI problem, because the system is complex and requires a lot of moving parts that will be built so there's a lot of misunderstandings. This is way we intend to open at first only for longer names, as a testing ground until we can work out the kinks. Ultimately this needs to be tested in practice.

On Mar 10, 2016, at 13:16, Michael Kilday notifications@github.com wrote:

I agree with @JohnDorien1, and I think the Internet Domain Registry system of today's modern internet is what Ethereum should base it name registration system off:

1) Anyone can buy unregistered names, AND renew those names for a fairly low fixed price (an equation derived from average gas price over 30 days or whatever).

2) Anyone can renew those names at any time, for a maximum of 10 years into the future from the date of renewal.

3) Anyone can auction off, or sell at a fixed price, the names they own.

It works, tried and true without catastrophic issues, and has worked for over 2 decades with the Internet Domain Registry system.

— Reply to this email directly or view it on GitHub.

[taoteh1221]

Sounds good, this will be great when it is in place. End users only having to type in a username after they set one up should increase adoption I think.

[pipermerriam]

I've just gone back through this proposal and I wanted to voice my continued support for it. Given the upcoming homestead release I think it might be worth beginning a discussion on whether or not we are at a place where we can move forward with this system.

In order for us to have a productive discussion about this, I would suggest the following as guidelines for discussion.

• If you object to something about the current proposal, please include details of what should be changed to fix it.
• If you outright object to the current proposal, please link to your submission of an alternate system.

Assuming this moves forward, I believe the next steps are authoring an EIP pull request complete with contract code.

[JohnDorien1]

2) Anyone can renew those names at any time, for a maximum of 10 years into the future from the date of renewal. Also true on this system. The name owner selects the date when they want to renew. They can pay the renewal fee for the next period anytime. Yes for the auction to work someone needs to unseal their bid before the final date but that can be sold as a service as it requires minimal trust

I cannot see how this comes together; The proposal clearly states auction system for renewal, yet you @alexvandesande agree here to @taoteh1221 the renewal would be fixed price. Elaborate please.

@alexvandesande I am interested in your view on my points I stated above and @Cryptix23 enhanced further, on how the described situations shall not happen as per your proposal.

Aside the above I propose following:

Keep the current name registrar as is, as name registrar. Start officially supporting it. Maybe add some features to it, for example a function to list all names one owns. I am happy to code on that on the sol side.

On top of that, or better, as a second instance, create this registrar proposed here, which is in my opinion far away from a working solution as name registrar and or DNS, but rather an awesome proof-of-ownership registrar. Mist could offer both in exactly that way, register with name registrar or register with proof-of-ownership.

[alexvandesande]

@JohnDorien1 A way to think about it would be to think that under the current system all names are always for sale under the current proposal. The current owner sets the price (that price is not revealed until after the bidding deadline) and has to pay a renewal fee proportional to the ask price (but much smaller than it), so they have an incentive not to overestimate it, as they would pay more.

If there are interested buyers but no one offers the full ask price, then the owner will receive a partial refund for his maintenance fee (or full refund if there are no bidders). If there is one or more bidders willing to pay the ask price, then the current owner will receive the price he asked for, or even more. Of course the owner can sell his domain at anytime if they want, this is just an automatic mechanism once per period. Also I think it would be a good idea to give the owner a grace period that if his domain is bought and he changes his mind he can still keep it by paying a higher renewal fee.

As I said, the issue is that this discussion is rather long so new commenters don't have the time to read it all before criticising. If @Cryptix23 has a better system in mind that would keep domain distribution fair and avoid them all being squatted immediately by the organisation with the most powerful system, then it's up to him to propose it, since as far as I understood his plan is just allowing whoever has the fastest system to own whatever domains they want.

@pipermerriam My intended timeline is to, after homestead release a beta 1 of Mist, as soon as we integrate it with swarm. After that we will build a swarm uploading app and start working on building this particular auction system, both the contracts and the interface.

[JohnDorien1]

How can a business in any way do a budget planning if the domain is always for auction and anyone could just skyrocket the price? I do not see the practical use of this DNS for any business / business-like organization mainly because of this major issue.

[alexvandesande]

How can a business do any budget planning if they need to pay taxes on their property? A business can pay for a domain for a long time and not need to worry about it, only need to pay renewal fees once every few years, depending on for how long they own the name. Renewal fees will be decided by public vote on all domain holders so they are bound to be something most people believe to be fair.

[RichardGRS]

My opinion you are focusing too much attention on bidding rather than on the core functionalities of a DNS/Registrar.

I found etherid.org recently and for what I see it does exactly what a DNS/Registrar should do, frankly I don't think we would need anything else, integrating this on Mist would be more than enough.

You also seem to be building this around name squatting prevention, I don't think this should be the concern of a DNS/Registrar protocol, it's like if satoshi would build bitcoin around preventing bitcoins from being stolen... Example someone accesses your pc and steals your pvk, transfers your btc to another address... That's simply not and should not be the concern of the bitcoin protocol, same as name squatting shouldn't be the concern of a Registrar protocol, that's just the way it is.

[alexvandesande]

What are those other functionalities you are missing?

On Mar 27, 2016, at 23:19, RichardGRS notifications@github.com wrote:

My opinion you are focusing too much attention on bidding rather than on the core functionalities of a DNS/Registrar.

I found etherid.org recently and for what I see it does exactly what a DNS/Registrar should do, frankly I don't think we would need anything else, integrating this on Mist would be more than enough.

You also seem to be building this around name squatting prevention, I don't think this should be the concern of a DNS/Registrar protocol, it's like if satoshi would build bitcoin around preventing bitcoins from being stolen... Example someone accesses your pc and steals your pvk, transfers your btc to another address... That's simply not and should not be the concern of the bitcoin protocol, same as name squatting shouldn't be the concern of a Registrar protocol, that's just the way it is.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub

[RichardGRS]

@alexvandesande

From what I understood you seem to want to introduce dynamic fees based on market bidding. This removes total security for domain owners.

Why would I place my business under such risks if the ownership of a name is not controlled by me (the owner) but rather by what the others bid?

Not just the fact that owners will not know how much they will have to pay to renew their names but also what stops someone from biding as much as they can to steal domains and then putting them for sale in secondary markets for a much higher price? Or what if you are a business owner and you want to damage your competition? You would just give Squatting another name.

This system you are proposing favors everything except the domain owner, you are primarily favoring:

1. The rich, the more ethers you have the more you control the domain names prices and ownership.
2. The ethereum network, by basically just keeping bids flowing and therefore more transaction volume in the network.

No offense, but this seems like a "dirty" way of just putting ethers flowing in the network.

The point that I'm trying to make is that a Name Registrar should not be built under bidding or to favor transaction volume, it should be built to do what it is supposed to do: Secure ownership of Domain Names with optional transfer, optional renewal and expiration.

That's all what a name registrar is. (Excluding the DNS part of course...)

[alexvandesande]

Secure ownership of Domain Names with optional transfer, optional renewal and expiration.

Richard this proposal does all that. Let me be clear that the intent is to minimize both wasted money and wasted names being held without any use. It's not at all the case I'm trying to maximize ethers going anywhere.

The proposed system allows the owner to transfer the name and renew it and if the name has been held for a while, it also allows the user to hold it for many years before needing to renew it. The owner can also sell it directly, loan it, put it up as collateral, auction it, rent or anything they want that smart contracts allow, so if there's a use that is not covered here, third parties could create a service for it and still have a lot of trust need removed from the system.

An important factor is that if the fee you laid for renewal is much lower then what happens isn't that the name is "stolen" from you, but sold at a price you set it up yourself and you get 100% of the profit. Again, I remind you that this will be probably at least a 100x the price you paid for the domains and if you invested more than that, then you're free to set your sell price.

This means that if a very rich entity decides to pay huge prices to buy out all domains names, they will be funding their adversaries.

On Mar 30, 2016, at 05:58, RichardGRS notifications@github.com wrote:

@alexvandesande

From what I understood you seem to want to introduce dynamic fees based on market bidding. This removes total security for domain owners.

Why would I place my business under such risks if the ownership of a name is not controlled by me (the owner) but rather by what the others bid?

Not just the fact that owners will not know how much they will have to pay to renew their names but also what stops someone from biding as much as they can to steal domains and then putting them for sale in secondary markets for a much higher price? Or what if you are a business owner and you want to damage your competition? You would just give Squatting another name.

This system you are proposing favors everything except the domain owner, you are primarily favoring:

The rich, the more ethers you have the more you control the domain names prices and ownership.

The ethereum network, by basically just keeping bids flowing and therefore more transaction volume in the network.

No offense, but this seems like a "dirty" way of just putting ethers flowing in the network.

The point that I'm trying to make is that a Name Registrar should not be built under bidding or to favor transaction volume, it should be built to do what it is supposed to do: Secure ownership of Domain Names with optional transfer, optional renewal and expiration.

That's all what a name registrar is.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub

[RichardGRS]

@alexvandesande

What about the owners that simply have businesses running on the domains?

What happens to their business when it gets to the renewal date and they find out that they have to pay 5000 ETH to renew the domain because one of their competitors decided to try to damage their business?

You seem to be putting all this system on the perspective that all owners buy domains for profit... The main purpose of a domain name is to eventually run a business on it, many owners don't care about selling domains and just want peace of mind while running their business.

What's your comment on this?

EDIT: One other example, let's say I have a son or a daughter and I proudly register their name on a ethereum domain name and put a page on it dedicating something to them. This domain is priceless to me, I don't want to sell and I don't want to pay astronomical amount of fees, assume the domain is a general name like simply "bob" which would likely get lots of bids... What's your comment on this scenario also?

[taoteh1221]

@RichardGRS If I'm not mistaken, I think @alexvandesande is saying renewals are more like modern day internet domain registrar renewals today, with a somewhat fixed / low renewal rate? I do agree if this is not true, it is a big issue. I think new un-registered / renewed registered (not buying from a 3rd party in other words) would benefit the 'small guy' best if modeled after the Internet Domain Name Registration Services of today's internet. I think trying to squash name squatting may backfire if not done very carefully, and may introduce larger issues like you mention. Might be best to just let the cards fall where they will regarding name sqatting...something simple like fixed rate registration on new registrations being a $15 minimum may work.

[RichardGRS]

@taoteh1221 where does he say that? for all what I saw they want the renewal prices to be set by the market - This is the base of the system, meant to avoid name squatting.

This is a complete madness in my opinion.

$15? For the sake of the future internet and for the sake of an "Ethereum revolution" I don't really think we need to have any additional costs at all for renewals / registrations, the only costs we need to have are transaction fees.

Look at etherid.org... all the core work of a registrar is done there already and is already live anyone can go there and register domains, the only costs are transaction fees, merely 5 U.S cents per transaction at current gas price if I'm not mistaken.

[taoteh1221]

@RichardGRS https://github.com/ethereum/EIPs/issues/26#issuecomment-194973879 My personal opinion is just model it after today's internet domain system, simple as that...it's still working great over 2 decades later, with name squatters going nuts to this day. Only charging transaction fees on never registered names sounds like a name squatting festival to me...bad idea.

[RichardGRS]

@taoteh1221 I see, well if bids are only for unregistered domains... sounds reasonable.

[pipermerriam]

I'm skeptical of a system that does not mitigate name-squatting and the domain-name gold rush in general.

If you look at the actual registrations present within EtherID you will see that name squatting is already a huge problem. My brief research shows that there are 1000's of names registered there that appear to just be squatters grabbing up common names and holding them for ransom.

My opinion is that bootstrapping a new DNS system must account for the fact that users expect google to resolve to something owned by google, and thus, google needs to be able to come along and acquire that name with relatively low friction. In my opinion, a name registrar that allows for someone to squat on a name while paying a very small renewal fee year to year will result in a name registry that is largely useless because any business who wishes to acquire their name in this system is likely to face extortion by someone who is already squatting on it.

The auction system doesn't eliminate this problem but it does mitigate it by forcing the owner of a name to specify a value which directly effects their cost for renewal. If someone grabs the name google intending to sell it to the company Google for a million dollars then they are going to have to pay 1,000's of dollars in renewal fees to hold the domain name. This makes name squatting much less profitable since you cannot squat on a valuable domain name while only paying a tiny renewal fee.

I'm highly skeptical that a copy of the current DNS system will result in a usable name registrar.

[pipermerriam]

And for anyone who'd like to view the entire state of the EtherID registry, you can download an export of it that I made today from this IPFS hash. http://gateway.ipfs.io/ipfs/QmXcjgmupXqGtvwwg2DYnyZi7QHnTjUWzgFycotzE28akt

Here are the 60 addresses that own the 31,361 registered names. The number to the right is the number of names they've registered.

• 0xfeb92d30bf01ff9a1901666c5573532bfa07eeec (6385)
• 0xc5a59924cce38b9c8bef18dff73569a0e2fb8d08 (4540)
• 0xfc6d284942ac65b21758c40ef87a59ba8be98237 (4221)
• 0x8dfb6033c8b9bc0222a8aeea700db1a058d283e0 (2248)
• 0xd147627b5e13c97b06d445e9002656041cc24b96 (2080)
• 0x39416b274538193926bb9f6d3a4a53d850710988 (1717)
• 0xfcae7970392f510a985a7eaccd3820b7759d65d9 (1266)
• 0x1a88c052fc7a8401e00b2f76f96ac62a19427731 (1095)
• 0x9f7dfec75b555f26a9f6ef2ed343617e6e76b19a (1019)
• 0x9ea4121a295c3265886ce203c7262b478f1f4950 (807)
• 0x41eafbf791753b37284241223e1ba263e8da7e56 (769)
• 0x86e1daaef619159d7a95757fd28b284ee0a29dc4 (654)
• 0x4d67473ca7d1915cfd02182249fb6f4085dfc916 (652)
• 0x1c2679097d2d6995763fbf6a25f62e9b735d4875 (626)
• 0xb3e080df7a85ad8c68f2b40aacfb572769c73c05 (570)
• 0x969a4102d3953c4edb10f34108084fa34696cc74 (544)
• 0x3ec65ce6990b1656532cc98c9f46315711b676e4 (296)
• 0xe405713f7fd88324f065e20effbcaf1fec11163a (295)
• 0x5fa0c49519cc615cd703b06140bbeba87a8e59a1 (281)
• 0xba16e62978d488b42b80da5af837cc84686e14b7 (227)
• 0x53d2ecb69e014495b6993d96bf43f66fbf67d6ac (223)
• 0x4c313ae629947321b411ef6421cbb7275a7f94e9 (189)
• 0x72e7aafa213243eeff69399d65b7ddd4d4c00051 (164)
• 0x1811dc50007a1f4561f6e731c4bc11ffa0aff177 (111)
• 0xcbd0ce2c723850d6a8da052353361340d10a8eda (69)
• 0x7c4401ae98f12ef6de39ae24cf9fc51f80eba16b (64)
• 0x02ba341de5ef7646862f39658b46dd4cb8695957 (50)
• 0x817855762f13a40dd4eef6676ef8b8ff00b65f83 (30)
• 0x579ae49566612d5e746af048555076ed089fa3b1 (26)
• 0x9af084c559597c65417d817075c037a0cba22a29 (25)
• 0x3cc517f003fd4b5c22975feb2db7e73e6d830bc8 (23)
• 0xf56a5f8f61bcc8296fee08e126a32b08046161ec (17)
• 0x6c11fa9f82689aa0d4d41f2ed3e3a80932707b46 (13)
• 0xa1c24c9da4c206c6785517308945a17a9374c000 (8)
• 0x123cb57c922daa49faefa5fe0f2788d92a9bc872 (7)
• 0x6a06143f9d42f37b171bc115ed183654022757a8 (6)
• 0x43cc7df71013f52aecdd86aaf34532fea215c248 (5)
• 0xb00ba93afd3a02fe25994055d5178ebb9ac2c2d2 (5)
• 0xcda0ad7542e30bf520652a05056ebe0105c7e49a (5)
• 0x74f2f93d5f837dfdcdb641c89dcd50f7a02fdf5d (3)
• 0x245133ea0fb1b77fab5886d7ffb8046dfeff3858 (2)
• 0x7cc2af566f0e21f4a98e3556342a8b70999e40f7 (2)
• 0xf2e767bea51b1a8fc4b6ced82ba4ab0de166ec2c (2)
• 0x6000b846630e4f8ae883a270c118f681bd12e593 (2)
• 0x8d90ad45d23983cbb4d331b8291ceeae5aea40e5 (2)
• 0x6710c2c03c65992b2e774be52d3ab4a6ba217ef7 (2)
• 0x6bccce69ca0223a421f5c672a29e29c6dc73f268 (1)
• 0xabfb6556c844623fe77b1edd91f1d06b5a2ee1fe (1)
• 0x0549c870873cd5dd0be6420541a5eca47bc59940 (1)
• 0x3a759675b8f05697e7210d1098e995bcb4e05ec0 (1)
• 0x0519fb77c25bdadbe77d356405a1a0dee171bd62 (1)
• 0x07d17318441b50017ee3233871b0248770532f08 (1)
• 0x10e65e72cfe5e1d95b93fa250878a0e476f505b1 (1)
• 0xfffa4fa7bae043946e2be6a7f7b1302fa0adee2b (1)
• 0xcb4baa0344065655da9e7d2dde781e5efa25995e (1)
• 0xf98d8e8ffb838695e5fb15fd1c9d9a1b437335c2 (1)
• 0x363be44335d8b8d9cc7447913a72d077041bbfba (1)
• 0x0d20351567d96e3a2d1aa15c10eeef99402ad4d5 (1)
• 0xa16269e97a007781a3ce05a4ec9fb462b3b02501 (1)

This is likely what any registry that re-implements the current DNS registration system is going to look like, and it doesn't feel like a very useful registry.

[taoteh1221]

@pipermerriam I see where you are coming from. My only concern would be an unforseen way an auction format could be manipulated by the rich (and the 'small guy' just gives up and forgoes using the platform, which affects adoption), and the opposite undesirable scenario where anybody could by a name for a transaction fee and many thousands of names are squatted on easily by anybody. For instance, auctions can be pumped up just like market assets...if I want to register myname.eth and somebody sees that, who's to say they won't pump the price if they think I may really want it badly (and maybe even outbid me hoping I or somebody else may want to buy it for more later on)? On the other side, if nobody is seeing I want this name or any other X amount of names and I only pay transaction fees for X amount of names, I am squatting on thousands of names very affordably. I guess some middle ground that protects the 'small guy' while making name squatting fairly expensive is the goal here. I'm sure just going slow structuring the protocols will work out the potential kinks.

[pipermerriam]

if I want to register myname.eth and somebody sees that, who's to say they won't pump the price if they think I may really want it badly (and maybe even outbid me hoping I or somebody else may want to buy it for more later on)?

I believe blind auctions solve this where auctions are just for hashes and the actual name being auctioned isn't revealed until after the auction has closed. I don't recall if this is part of the current proposal but I know it has been talked about. I'm unaware of what the downsides to such a system would be. @alexvandesande ?

On the other side, if nobody is seeing I want this name or any other X amount of names and I only pay transaction fees for X amount of names, I am squatting on thousands of names very affordably.

Yes, but people can then buy them out from under you at a very reasonable price when they come up for renewal which drastically reduces the impact of your squatting.

[taoteh1221]

@pipermerriam Great replies, did not think of either of these things. I'm sure @alexvandesande and the rest of the team will do a great job as usual implementing. Slow and steady wins the race. :smile:

[pipermerriam]

@taoteh1221 thanks for participating in the discussion :smile_cat:

[RichardGRS]

@pipermerriam, there is no way to prevent squatting without making someone else lose.

1. You increase the registration prices - this will hurt the whole protocol as the more expensive it is the less people will be attracted. - And by the way it raises questions - where will the registration money go?
2. Increasing renewal fees with bidding - this will hurt the owners.

If as alexvandesande said, the bids will only be for unregistered domains... fine. But I don't see how this will prevent squatting...

I don't really think name squatting should be a concern of the protocol, that's just the way it is.

A name registration is a registration of a combination of characters it's up to the market to give them value or not and up to the owner to decide what to do with it, if you register 1000 domains, even if they are squatting, what's the problem with that in the view of the protocol? If the squatting has no value the buyer will eventually be the loser as nobody will want the domains, over time the buyer will lose money with renewals and eventually will drop them off.

If the squatting has value, the buyer eventually will sell the domains at an agreed price between both parties... this is the principle of a free market.

Personally the current worldwide DNS registration system is not good or bad, is just the way it has to be.

It's like bitcoin and cash, bitcoin didn't really revolutionize cash, it just made it digital and decentralized, the core of it works the same as cash.

If you make an illegal transaction with cash, a court order can be issued and the transaction can be revoked, while with bitcoin there is nothing that can revoke the transaction other than the owner.

Same for an ethereum name registrar the only difference is that it will be decentralized, in the current worldwide registrar system name squatting is even illegal per united nations laws, which means a court order can be issued and a name registration you made can be revoked.

In an ethereum decentralized name registrar as in bitcoin, if a transaction is illegal or not... it should not be the concern of the protocol.

[pipermerriam]

@RichardGRS

I don't really think name squatting should be a concern of the protocol, that's just the way it is.

I don't agree with this sentiment but I doubt it's something we need to reconcile as it is likely an ideological issue.

If as alexvandesande said, the bids will only be for unregistered domains... fine. But I don't see how this will prevent squatting...

It doesn't prevent it, but it does mitigate it's effectiveness. Since owners set the price and then pay a small percentage of that price for registration, then if a squatter wants to price a domain at 1 million, at a 10% fee they will have to pay 100,000 for it which makes squatting on many names pricey. If instead they choose to value it at 100 in order to pay a smaller registration fee of 10, then someone who actually values that name can purchase it for 100. The squatter still benefits, but the system mitigates the manner in which a squatter can inflate prices as well as the amount of real-estate that they can squat on since the price is not flat.

---

I think we may have some fundamental disagreements on what the actual goal of the system is. My view is that it is a public good with the following goals.

1. Allow current owners of domain names the ability to own the equivalent name within this registrar for a reasonably low cost of entry.
2. Low cost of entry for new names.
3. Maximize the end-user usefulness of the name > resource mappings. This means that for most cases, google will map to something owned by Google, digix will map to something owned by Digix.

If mitigation against squatting and land-grabs is not part of the design then 1 and 3 are likely to fail which in my opinion decreases the likelihood of wide adoption as well as the overall usefulness.

I also feel that it is a false equivalence to say that the current DNS system works well enough so a new copy of it will work well enough as well. The current DNS system has been built up over many many years allowing businesses to acquire their corresponding domain names. The current state of EtherID demonstrates that a blank copy of the DNS system results in a land grab for popular or known valuable names, decreasing the value of that system since the names don't actually map to what they should map to according to user expectations.

[RichardGRS]

@pipermerriam we definitely have fundamental disagreements, in my opinion a decentralized registrar should be completely free, all these eventual rules being discussed here have a name, they are called regulations and I think that regulations and evolution don't work very well.

To be honest, I love the concept of the EtherID, complete freedom, that's how a decentralized registrar should be.

In the beginning of the internet the registration of domains was also completely free and that seems to have worked pretty well, if it wasn't for that you probably wouldn't be writing on this website right now.

[pipermerriam]

@RichardGRS Thanks for engaging and thanks for sharing your thoughts.

[RichardGRS]

@pipermerriam thanks, but anyway looking forward for whatever you guys come up with, will definitely engage on it.

btw, any ideas when the first version will be live?

[alexvandesande]

What happens to their business when it gets to the renewal date and they find out that they have to pay 5000 ETH to renew the domain because one of their competitors decided to try to damaged their business?

Richard I still think you're not understanding how it works, so lets calculate this. Supposing a fee of 0.1-1% yearly (this is a very high max on my opinion) it means that a business that pays 5000 eth is one that has a market value of 500k to 5M eth.

So there's no situation where a business owner "finds out they have to pay". What happens instead is that a business owner declares the value of their business and then they pay a fixed tax on that, which they will be easily able to calculate in advance: it's the current rate (set by a contract chosen in an election) multiplied the amount of years they want to renew it for, multiplied by the self assessed value of his business.

If businesses think the rate is too high, they can vote to lower it. If they can't pay then they get the value they want. Relocating is super easy as it's a matter of pointing a new name to the same address.

I bet most business owners would welcome getting a few million ethers just to move their business one letter up somewhere.

On Mar 30, 2016, at 21:41, RichardGRS notifications@github.com wrote:

@alexvandesande

What about the owners that simply have businesses running on the domains?

What happens to their business when it gets to the renewal date and they find out that they have to pay 5000 ETH to renew the domain because one of their competitors decided to try to damaged their business?

You seem to be putting all this system on the perspective that all owners buy domains for profit... The main purpose of a domain name is to eventually run a business on it, many owners don't care about selling domains and just want peace of mind while running their business.

What's your comment on this?

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub

[JohnDorien1]

I bet most business owners would welcome getting a few million ethers just to move their business one letter up somewhere.

Let's put it this way: no company ever willing to have their brand will use this system.

Further, I agree the squatting is not the issue of the protocol, neither can the user expectation be to find all names given in the current / etherID / possible future registrar to match the current "real world" DNS. If a brand wants their name, they'll pay for it, even to get it off a squatter.

Under no circumstances any company would like

A way to think about it would be to think that under the current system all names are always for sale under the current proposal

IF the renewal fees are fixed, why the auction on renewal names? Either I decide I want to sell it, so i start the auction, or I want to renew, so I pay or it expires, but the renewal auction vote stuff seems just unneccessary and complicating.

[RichardGRS]

@alexvandesande thank you for your explanation, however I'm really not convinced that this should be the way a decentralized registrar should work.

What happens instead is that a business owner declares the value of their business and then they pay a fixed tax on that

Are you serious? Taxes are the cancer of this World, what are you building here, a socialist registrar? :smile:

I vote for freedom and the only costs should be the transaction fees nothing else.

I agree there should be auctions for the domains (and only if the owner wants to do it), this is actually something that is missing in EtherID, you can only set fixed prices there.

I'm completely in agreement with what @JohnDorien1 shared in his previous post.

[BL186]

When are we going to be able to start registering domain names on ethereum default name system? Regardless of the solution that will be implemented...

Not that is much relevant, but I agree 100% with @RichardGRS and @JohnDorien1

[zweicoder]

Might have missed something here but unrevealed bids might have to be confiscated.

If I'm aiming for a particular name/hash I can use multiple addresses and bid different prices, only to wait til the very end and not reveal those that do not 1) Damage the person who outbid me the most 2) Give me the lowest price.

While 2 might be a bit risky to someone just looking for a cheaper price for a domain (s)he wants, 1 will almost always allow someone to just damage the competitor, for instance.

[alexvandesande]

Closing this issue as it has been superseded by ENS

[fulldecent]

@Arachnid You nominated this as an "EIPs that should be merged". Can you please share your notes on that here?