Ways To Limit Domain Squatting
I propose the following mechanisms in some combination - for discussion - though not necessarily to be used all at once. There is quite some scope for variations on these ideas but I’m sticking to the basics for now.
Note: I’m assuming the DNS is implemented using Structured Data (SD) items, paid for at registration by the user (a very small network fee, but planned to be 10x the normal PUT rate). Once created, changes to and SD item are free (unlike other data stored on SAFE where every “PUT” must be paid for according to the quantity of data stored.)
I propose the following measures to inhibit domain squatting:
- an account must have farmed F Safecoin (Sc) per name it is allowed to register (e.g. F=1)
- there be a network charge of C Sc to register a new domain name (e.g. C=1)
- a limit of D domain names allowed per user account (e.g. D=10)
We can play with different values for F, C and D. It is obvious there are some problems with this, particularly with the variability in the value of Safecoin, but I think there’s a chance to address these if we put our minds to it. Below I explain the purpose of each limiting factor, and the problems I see with each one.
By all means point out other problems and/or solutions - but keep this topic based on the assumption that inhibiting squatting is desirable. We can discuss whether that is the case elsewhere (please ).
Farming Requirement (F)
The strongest inhibitor here is the requirement to farm F Sc per domain registered to an account. This is because domain squatting is a numbers game, and is more worthwhile as a business, and has the biggest negative impact, when it is carried out on a large scale. Setting a value for F of 1 effectively forces everyone acquiring a domain to provide significant resources to the network for every domain registered - proof of resource. This could slow considerably, and perhaps limit, the scale and impact of domain squatting without putting a domain name out of the reach of anyone who has at least the means to purchase network storage (which is a prerequisite for anyone who wants a domain name for their own use, rather than squatting).
I’m not sure how feasible it would be to implement this limit. There would need to be a way of tracking the amount of Safecoin farmed per account, which at the very least means that the close group responsible for a farming reward would have an extra task, of incrementing this count, and it would need to be stored somewhere.
Network Charge (C)
Requiring a payment for each domain helps to limit the number of names an individual is likely to register purely for squatting. The impact this has on squatting will depend directly on the size of the fee, but will at the same time impact other users once the fee rises above a fairly low level. The impact of this fee will also depend on the cost or difficulty of acquiring Sc (in resources and fiat). For these reasons, a flexible pricing mechanism might be needed rather than a fixed fee, which could be determined by an algorithm, but I’ve left my thoughts about that out for the time being.
If Safecoin becomes valuable such that C is more than say $10 SAFE domains become relatively expensive compared to the current internet which may have a negative impact on adoption.
If the price of registration rises further, say C above $100, those with little means will face a hard choice about what to do with their Safecoin, effectively pricing them out of access to the DNS. The can be mitigated by keeping C <= F, but if the value of C meant that domain registration rose to $100 or $1,000, the numbers of people able to register with the DNS would drop considerably which is against the values of SAFE (Secure Access For Everyone).
There are though two potentially beneficial side effects of a network charge to register a domain. The network fee would be recycled, which means returning the Sc payment to a pool that can be paid to farmers, and to reward publishers and app developers. It also creates a demand for Sc, creating utility and adding value to Sc.
Domain Name Limit (D)
As noted, squatting is more attractive the easier it is to scale. Limiting the number of domains per account makes large scale squatting harder, and may inhibit this activity.
Note: The network is potentially vulnerable to attackers who can create large numbers of nodes, so it is possible that unrelated measures designed to protect the network might also make it hard for squatters to create and manage the large numbers of accounts needed to manage lots of domains. For example, one defensive proposal is that an account must have 1 Sc deposited in it within a short period of creation or it will become deleted by the network. If that measure were implemented, it would cost an additional 1/D Sc per domain for anyone using multiple accounts to manage large numbers of domain name registrations.
Initially I suggested D=10 because I think it would be more than adequate for a very large number of users. However, we could set the limit much lower if we feel it will have a desirable impact. Even D=1 would not be particularly inconvenient for everyday uses, and for many users having one account per domain might make sense anyway.
Further Measures
The above measures have the side effect of encouraging users of unwanted domains (for whatever reason) to relinquish them. Even disregarding squatting, this is desirable because good domain names are limited in number, and so leaving them permanently unused is a waste of a useful resource, and will tend to make the SAFE network less “efficient” (e.g. harder to use) than it otherwise would be. On the current internet, an annual renewal fee has the same effect, since even though it is quite small for most kinds of domain.
Having an annual fee is stronger than the measures I’ve proposed, because it prompts a review by the user, and requires them to take action to retain the domain as well as to bear an ongoing cost.
For this reason, a similar mechanism could be beneficial on SAFE network, and may further discourage domain squatting as well. I’m not sure how feasible this would be, but it is also worth considering.