Agreeing on basic principles for setting of rent


#1

So, I figure it’d facilitate further discussions if we first make sure we’re all on the same page with regards to the goals and principles of a rent system. Here they are in my mind; further discussion appreciated:

  • The primary goal of charging rent is to discourage mass registration of domains with the sole purpose of selling them on later to actual users (‘name squatting’). Imposing a fee for each domain requires squatters to make an economic assessment of the likely future value of the name to them, rather than mass registering a large number of names on the off-chance someone will want them later. ENS has a vested incentive to prevent this happening, because the name system is only useful if overhead is kept low and if names are commonly allocated to those who can put them to best use.
  • A secondary goal is to ensure that names do not get ‘lost’ and become permanently unusable due to participants leaving the system or losing credentials. Charging rent ensures an unmaintained name will eventually return to the system for reregistration.
  • The above goals do not require that the rent price for a domain depend on that domain’s popularity or level of use. Thus, rents should be the same across all domains, or depend only on variables other than the use of that particular domain (for instance, shorter domains may be more expensive to reflect their scarcity, but ‘mew.eth’ should not be more expensive than ‘xod.eth’).
  • Ideally, rent prices should not be set centrally by a single entity, but rather adapt automatically to conditions, using some form of feedback mechanism to ensure rates stay at a level that achieves the above goals.

#2

As someone who owns a bunch of DNS names, rent also forces me to decide which ones continue to provide me enough value to keep. I often find myself letting names go back into the pool because I realize that I haven’t been using them and I should stop wasting money on them. Recommend adding this as a minor point to the “lost” bullet point.


Ideas for a 'squatter-oracle' - non-rent based squatter disincentives
#3

A name squatter that is motivated will analyze all the names that have commercial value using a metric of their choosing and then acquire all those names unless those names can be isolated and charged premium rent. A squatting strategy is dependent on the ability to make a profit on an assignment or resale. Maybe that is where the attention should be.

Any rent system set to dissuade a squatter also applied to other less valuable names will likely punish the masses at the sake of anti-squatting goal (unless isolation). If the rent is applied equally on all names, the squatter group will just take the premium names and hold them, until they get an offer to assign it or pass “ownership”. Even though $10 USD per year .eth name is probably too much to charge the common user, it is also an amount that the average speculator would rethink their squatting strategy; however, an “across the board” equal rent fee would do nothing to dissuade someone from collecting all the “valuable” well known names and wouldn’t think twice about having to spend 10 times to 100 times that to secure a mark/name/identifier .eth domain if it had some resale, re-rent, redirect features.

Maybe the strategy should be rethought to not allow assignment or “ownership” to be changed on the .eth domain. This would ensure whoever acquired the domain, MUST use the mark and can use it for speculative purposes. And every five years, the owner must re-rent it again, but can never assign it while they are the rentee. just a thought


#5

Indeed. Nobody has yet proposed a mechanism that prevents targeted squatting without breaking other things, though.

There’s no way to do that; if you try and make life difficult, people can just write smart contracts that hold names, and reassign ownership of those instead.


#6

I’m not sure the fact that competent coders could make something functionality similar to facebook or twitter is a reason to think their new competing source would usurp the defacto standard.

I think most .eth users are not going to tackle writing a custom smart-contract in the face of the incredible work you’ve done so far, but I really am not in a position to even check the direction of the wind in this environment.

It is this group here who would (or should) do so, because any other development group is likely to make matters worse.


#7

That’s my point - one competent coder could write such a tool, and everyone could use it. It’s simply not practical to prevent people from selling or trading names.


#8

I love this proposal. By not allowing a domain to be transferred to another address, the resale value of the name would likely be greatly reduced. A shame that @nickjohnson highlights this isn’t feasible.

Couldn’t contracts be disallowed from registering names somehow? (Admittedly out of my depth here…) https://stackoverflow.com/questions/37644395/how-to-find-out-if-an-ethereum-address-is-a-contract … or does that break some other functionality?


#9

Disallowing contracts from own names and/or disallowing (via any means) transfers is a security risk. One simple example is a company owned name that is controlled via a multisig contract. If a private key is the only way to own a name then if that single private key is lost or stolen you lose the domain. With a multisig, your company can reduce the chances of theft/loss by distributing the signers.

Similarly, recoverable owning contracts can prove useful for individuals to protect themselves from both loss and theft simultaneously in a way that single-key ownership cannot.


#10

Fair points, to be sure. Thank you for jotting them down.

Just to play the devils advocate:

These are not typically things I have generally considered “security issues” when considering control over on-chain assets, including ETH. I think of these more as ownership management issues, but I can certainly see where you’re coming from.

So, if it were technically possible, then we are consciously trading a strong squatting deterrent in the name of security for (corporate, probably) ENS owners? Seeing as how setting up a multisig contract to hold your ENS names isn’t yet turn-key, your average Joe Eth probably isn’t implementing these ownership contracts.

Couldn’t the argument be made that not allowing a transfer actually prevents some security issues, though? Multisig vulnerabilities aside… what use is an ENS name to a potential hacker if they know they will not have exclusive control of its properties? They can’t resell it. The legit owner can have a watcher making sure nothing insidious is happening with their name.

Is the greater problem squatting or providing more tools for users to manage/control their ENS names? Does it depend on who we ask?

Again, just spit-balling the opposite view. Thanks for sharing your insights!


#11

Ownership of names by contracts is also essential to enabling registrars - so any change to that would require some new way of assigning new names.

What happens when the private key for the account controlling the name gets compromised? Now the hacker has control over the name, and there’s no way to change that.


#12

This is what I kinda thought must be the case. Other features depend on this architecture…

Right. I get it. But if the original owner still has the key too - then what good is the name now? Two people now have control - it’s worthless to both of them (assuming the legit owner could spot the shenanigans right away and take some off-chain actions to discontinue its use).

I was just trying to flesh out if this was technically feasible and if the trade-offs would possibly be worth it. And I guess I’m going to have to try and think about key management as a “security issue” in its own right … :thinking:


#13

The primary goal of charging rent is to discourage mass registration of domains with the sole purpose of selling them on later to actual users (‘name squatting’).

Can we look to see if this is actually a bad thing?

  1. We have a free market determining the price
  2. We will never run out of subdomains
  3. Subdomains are ‘trustless’ and just as secure as top-level domains. (This is notably different from the DNS world.)

Instead of imposing rent and creating many (perhaps insurmountable) problems, why not focus instead on improving the UIX of subdomains? This is the path of least resistance.

I don’t want to sound harsh, but the idea of rent sounds like a crusade. It is a public idea with a person’s identity attached to it. In Academia one can defend something forever not because it is good but just because of a career.

I hope we look at rent very closely and explicate all of the problems it creates, and make sure it is even solving an immediate problem, and what that time could be used for more usefully instead.


#14

It’d a bad thing because it imposes a deadweight loss on the system: Squatters inflate the price over the base cost, which imposes a cost to users, but they don’t add anything back to the system. All else being equal, we’d be better off without squatters than with.

Subdomains are useful for getting users a domain quickly, but they’re not as short or as memorable as 2LDs. If they become valuable, too, we can expect to see squatting on them unless it’s discouraged.