ERC: Default Ethereum Name Registrar #26
ERC: 26 (based on issue number) or 3 (based on ERC) Title: Default Mist Name Registrar Author: Alex Van de Sande (email@example.com) Status: Draft Type: Informational Created: 20-11.2015
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.
The goal of this contract is:
The system will consist of 4 main parts:
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
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.
All funds given to the Registrar contract are redirected to the Collector Contract. These will not count towards the
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.
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)
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)
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:
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
If the owner has changed then amount of
Deletes any unsealed bids that are older than the maximum duration time that any name can accept and forwards the ether to the Collector.
The Collector Address is an address that receives all the funds collected in auctions and has a special right to change the
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.
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
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
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.
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)
The text was updated successfully, but these errors were encountered:
@alexvandesande That seems logical, yes. Perhaps there should be a simple function to just start a function for a new name, because you might as well bid just a tiny amount to start the auction and make the true bid later.
My concern with bidding on hashes as hashes is that the value of, say, 0xcfe33df56932be08b97194721e1d28638ed2f677728b2ffd617bd710fec0952d is not obvious to the average user. As it is, that's the sha3 hash of "wedding-shoes.eth", which I expect (should ethereum become popular and .eth become a TLD) to go for thousands of dollars. Being a Vickrey auction, this is a lesser issue, as you might as well bid the maximum amount you'd pay whether or not someone else will enter.
Making rainbow tables of potentially valuable hashes from dictionaries, web scraping, and Markov chains, then going after any auction with that hash is a potential strategy under this system.
I'm more concerned that random troll-bidding on new auctions will lead to unpleasantness for the actual bidder. If I want some odd new domain name now, I can just buy it. But if I have to fight a troll who's just bidding for the sake of taking whatever it is from me, it certainly feels worse, even if I may effectively pay less. The obvious counter-strategy is to spam the auction contract with new hashes until the trolls are bankrupt.
Also, the fixed election schedule could be broken by the current beneficiaries of the collector voting to transfer the collector to... an identical collector. That would reset the election time.
For imposing certain rules on entries ("short names only after 2017"), how about asking the Collector Contract every time an entry is edited or added? Then,
@Smithgift Thais What I mean by "privacy by obscurity", of course everyone can figure out the market price of the "Apple" name, I don't see that as a problem. They just can't spider and know the price of all obscure names.
Also, notice that there would be no dots. In this case you'd be buying just the name wedding-shoes and you can use any subdomain for that. This rule is easy to enforce because most will simply not honor any name with a dot, always looking for the top level domain first.
We are still discussing what "top level domain" even means in this content which is why I prefer not even register short names for the time being. Will it be .eth? Will anyone be able to register whatever?
This would be easier for me to analyze if I understood the goals of the effort better; what use cases must be covered, what use cases are intentionally not covered. Is privacy a goal here? It's stated that human readable names are a goal in the abstract but is that possible without sanitizing inputs? Why is reverse lookup not a goal?
Good proposal. Thanks for writing that up!
It might be better to make K=100 in the new owner case and adjust the
Just a point of clarification: when a new collector contract is voted
Also, is this namereg to have support for parsing paths at all, akin to
Finally, it's a minor pet peeve of mine that domains as they are now
Thanks again for starting this conversation. It's good to have all this
What if 'early revealer' needs to pay some penalty? In such case the value of
Um, maybe by computing hashes of the shortest names and keeping them (at least we can cover one-character names). Now I see the trade-off between "enforcing policy" and "privacy by obscurity". I have no good answer.
@rabbit the I expanded the text with a "motivation" section
@ryepdx I realised that I'm actually doing the K calculation completely wrong: the duration you want to keep your domain until renewal should not have an influence on the price you pay to buy it , only to renew it. So I think the correct way would be to have the renewal calculation that th e"bid" of the current owner should be calculated as bid = fee paid * K / duration. This means that if you would sell your name at 1000 ether, would like to renew it for 3 years and the current fee is set at 0.5% per year, then you need to send 15 ether to renew it. Anyone who bids more than that will buy it from you, independently of his duration. Maybe whenever a domain changes owners the duration should be always set at 1 year and then can be renewed for up to twice the previous amount every time.
Since any contract can be elected, that cannot be controlled. The new one simply starts receiving the fees from the renewal. The advantage of using a boomerang is that the new one would also be getting any revenue that was sent from a year previously
Watching your talk you mention a lot of great extra information that you will need for many use cases, including how to parse sub registries, some of which I don't understand them myself. The needs of swarm/ipfs also require other kinds of extra information attached to a name, like a hash of the content in cases that the address doesn't provide that.
So I thought that instead of trying to cover all possible use cases it would make more sense to be minimal: the "master" registry only saves a few basic information like the current owner, the renewal data and how much he paid in fees, etc. If you need extra information you can create a contract with extra fields that reads the owner from the master contract and then gives them the right to edit and add information about his owned hash.
You are not the first one to bring that up, actually @gavofyork wanted to put domains exactly as you describe. I see the point and like the idea, but there are some limitations: a slash cannot be used as a separator, since it's important for the browser to differentiate between subdomains and subfolders. Also, inverting the domain subdomain order requires some modification of the core chromium server that we are using. Also I'm a bit afraid of creating user confusion and risk of phishing attack for a user that would see secure.bankofamerica.com and even a tech savvy user might think that this page belonged to bank of america.
In Mist I am using a compromise solution: Im separating the display of the url from the editing. When you click and mouse over the url, the text displays the url bar exactly as traditional web (
I think it's a good compromise of usability and security.
@Smithgift all possible six letter names are in the order of billions, this would make the contract incredibly expensive.
Another solution is simply to ignore it and enforce that on the client, but this is a permanent solution. For example, if you type a name with a dot in mist, it would automatically detect the top level domain and look into that, so mist effectively ignores all names with a dot in the middle. This doesn't mean you can't register them, just means that they aren't used. The trouble with fewer letters is that I'd like to use the same system to names with 6, 5 or even a single letter in the future (if we don't come up with a better solution by then) but if that's the case we would have to use a second contract to store those as the contract will accept them no matter what.
@alexvandesande That was what I was getting at. There's no practical way for the contract to go.
I've decided to call the "bid on any new hash that's auctioned in the hope someone wants it" strategy bobcatting. It's like wildcatting in the oil industry, except you have no idea what you actually bought and you might have gotten hit by a countertroll's nonsense hash. ("INSTEAD OF VALUABLE HASH, RECEIVED BOBCAT.")
On more thought, a sophisticated bobcatter would examine the transaction history of the account that started the auction. If it's a seemingly independent account buying one or two hashes, it's possibly someone's username or something, so go for it. A sophisticated countertroll would attempt to create more "independent" accounts to fool bobcatters, which is in turn an incentive for superior bobcatter algorithms (i.e. if it's funded from a mixer, it's more likely to be a countertroll.) There's probably interesting game-theoretical analysis behind all this which I am not qualified to do.
This all said, an auction like this is far better, troll-feline-wise, than a first-come-first-serve system, because you can at least outbid the bobcatter. In first-come-first-serve, the bobcatter just tries to preempt your transaction with higher gas prices or the like, and if he does he wins.
@chriseth thanks, updated it!
@Smithgift Great point.
Let's say that a BobCatter would bid 10 ethers on random new bids being put. Since bidding is free, they would be able to own a bunch of new names for a year for less than 10.1 ether each, and they would be able to renew them for another year always for 0.1 ether (assuming a 1% per year fee), while being guaranteed that these names would alway sell for at least 10 ether each. The next year he can pay only 0.1 ether more and then these names will have twice the initial asking price and by analysing traffic coming to these names they could probably figure out the original name or at least its popularity.
The main issue I see here isn't even the name squatter holding a lot of popular names, but a worse consequence is that by bidding on all new names he is guaranteeing to make it more difficult for people who just want their own name for cheap to own it, and increasing the price for those who get it successfully: suddenly you can't get a uncommon name for free like originally envisioned, since all auctions are being bid on.
A potential solution would probably come from making bids non free, specially if you are bidding completely outside the market price: having deposits that you get back under certain conditions, incurring costs if you put the second bid (therefore increasing the price paid), etc.
Maybe a solution would be, instead of trying to come up with a solution to these problems right now, parametrize all these options as functions controlled by the collector contract. So for example, the secondary bid might pay a fee of X, which is a function of the total price made on the collector contract. If the collector contract doesn't implement that function then the fee is 0, but its up to them.
This gives the collector contract more power, but I believe that as long as it's controlling some limited auction parameters and cannot take names away, then it's a controlled power..
I think penalizing a second bid hurts spiders but helps bobcatters. If a bobcatter sees some random account unseal a bid to start an auction, the bobcatter knows exactly how much to bid to win, and the legitimate user will have to pay a second-bid penalty.
Suppose that the cost to start an auction is miniscule. Say, a new auction starts simply by calling a function, no bid necessary. Counterintuitively, the bobcatters will be at a disadvantage against a countertroll force, because the countertrolls could start absurd numbers of auctions to screen auctions by true users, and if the bobcatters go after every auction they go bankrupt. Unfortunately, this may lead to severe network spam, depending on how big the bobcat-countertroll conflict grows.
NINJA EDIT: But in that situation, spider-squatters are probably going to spam the network with starting auctions on valuable names before anyone realizes that they're valuable.
I realized there's an additional stumbling block to the countertrolls. They have to spend as much ETH on a new auction as a true user would, or the bobcatter instantly knows it's a countertroll. The true user strategy is then to spend less on a bid so that they look like a countertroll, but then there's a disincentive to bid what the name is actually worth.
@Smithgift bobcats, counter trolls, spiders, our fauna is getting richer!
I agree that to initiate a new bid should be a different function, with no information on price. I edited the proposal to reflect that.
Now the other points I would still keep the principle appointed earlier: parametricize all those fees, prices, taxes, deposits, etc so that these can be experimented by the collector contract.
About valuables names being quickly auctioned by spiders: there's no way to prevent it, there will be a gold rush of the best valid names. The reason duration is measured in days not years is so users can change their renewal date so most of them won't be having an anniversary at the same time.
Sent from my iPhone
Comes from tax collector. It's not a manager or Administrador as it can't change name owners or ban people. Accepting suggestions.
I still believe that a two layer system may be better, namely to have a Hash-to-Hash registrar (which maps sha(domain_name) to sha(content)) and a Hash-to-URLhint map which maps to URL hints.
My more general reservation is that both IPFS and Swarm already supports name resolution, both could use (the same) contract on the blockchain, and http provides DNS, so I am not entirely convinced having a mist central resolution is even necessary.
@ryepdx They do not need to be handled, in fact they should not be. Only domains should register on the blockchain. The domains point to a manifest file (routing table of sorts) with all your paths mapped to hashes (arranged in a trie for a recursive lookup in case of huge indexes). Since the manifest contains the hashes and itself is content addressed, an entire webservers all static routes can be integrity protected with a single entry in the registry.
@rabbit I agree. The usecase of reverse lookups are important. However, those that want to be in the phonebook so to say, can register their names with the string sent as a parameter in the transaction. This can then be logged with
If we keep the standard that we use this same namereg to register contract info belonging to a contract then the best way to do it is to index by contract code as name (as it is currently done in geth natspec implementation, see https://github.com/ethereum/go-ethereum/blob/develop/common/natspec/natspec.go#L107) (and see swarm dns-oid: https://github.com/ethersphere/go-ethereum/blob/bzz/bzz/api.go#L393). A consequence of this is that your browser will automatically serve as contract code reverse lookup.
I see it as follows:
Special links like contract addresses, should be prefixed with
This would show a JSON with all the necessary stored information about a contract (Interface, natspec, source)
yes I debate this. As I said if they support IPNS or Swarm anyway, their resolver is already supported
So once again. If I use IPFS and have a name already registered with methods other than the ethereum contract, I still want it to be available in mist, so we will need to proxy the name to IPFS scheme handler anyway (which, in geth, will probably be done by swarm as well) unless you reimplement the entire IPFS name resolution in mist. Conversely if i register my ipfs hash with the ethereum namereg, I also want other (non-ethereum) users of IPFS to see this, which means ethereum-IPFS name resolution should be implemented as part of IPFS anyway.
So you can have a contract that pairs hashes > hashes and another for hashes > url hints and another for hashes > eth address and so on. Those entries can only be edited by the owner account held on the main registry contract.
This allows greater extensibility but at the cost of the user having to do more transactions to register basic information.
I don't understand the point of name register duplication: if you have already registered a name in IPFS or swarm that uses a completely different set of rules you'll obviously need to register again, there's no going around it.
I don't particularly like the structure eth://contract:0xdeadbeef but this isn't the place to have this discussion in my opinion.
@zelig Why is it done twice?
This is exactly what we should want it we want to be modular. Each module (bzz, eth) has its specifies a way to resolve things, and
@alexvandesande concerning the
We should follow the browsers standards, because thats the tools we have available and we have a lady a great way to extend them.
@frozeman we are going round and round. Please sit back and read my arguments again please.
? in order for what to happen? for my dapp to be displayed in Mist? Why? That would be rather unkind.
@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.
@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.
@RichardGRS #26 (comment) 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.
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
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
I'm highly skeptical that a copy of the current DNS system will result in a usable name registrar.
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.
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.
@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.
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 ?
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.
@pipermerriam, there is no way to prevent squatting without making someone else lose.
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.
I don't agree with this sentiment but I doubt it's something we need to reconcile as it is likely an ideological issue.
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.
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.
@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.
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.
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
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.
@alexvandesande thank you for your explanation, however I'm really not convinced that this should be the way a decentralized registrar should work.
Are you serious? Taxes are the cancer of this World, what are you building here, a socialist registrar?
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.
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.