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)

[Smithgift]

Question: How are the names bought in the first place in this system? It seems that if it's an auction with sealed bids it ends up first-come-first-serve.

[alexvandesande]

@Smithgift good point. One way to do it would simply be that if a bid was unsealed for a new name then a registry is created with no owner and with a renewal date set for 7 days after that. This would make all new names go to a normal vickrey auction.

[Smithgift]

@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.

[pirapira]

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, newRegistry and editRegistry would call collector.request_entry(string _hash, string _new_redirectAddres, bool _edit) returns (bool allowed) to see if the new entry is allowed. The Collector can even redirect request_entry call to a dynamically specified another contract, and change rules from time to time, but once an entry is registered, the Collector cannot invalidate the entry freely.

[Smithgift]

@pirapira But how would the Collector know whether, say, 0x78ec64bb8319a432962e79252a373554ecd3cec759e53c41c3111c40b45127b3 is the hash of a short name or a long name?

[alexvandesande]

@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?

[rabbit]

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?

[ghost]

Good proposal. Thanks for writing that up!

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.

It might be better to make K=100 in the new owner case and adjust the
formula to be (K * _bidPrice / _duration) / 100. This would allow
for a scenario where the Collector Contract wants to make it cheaper
for the current owner to keep their domain than for a new owner to take it.

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... 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.

Just a point of clarification: when a new collector contract is voted
in, I assume the old one sends its balance on to the new one. Is that
correct?

Also, is this namereg to have support for parsing paths at all, akin to
the ENS system previously proposed? I see that this proposal handles
auctioning TLDs, which is great, but I don't see anything to suggest how
structured data might be handled.

Finally, it's a minor pet peeve of mine that domains as they are now
have their elements arranged in order of reverse importance, contrary to
the rest of any given URL. (E.g., http://google.com should be
http://com/google and http://ether.fund/tool/converter should be
http://fund/ether/tool/converter). This seems to me like an opportunity
to correct that error. I imagine this is probably an unpopular opinion,
of course, but I figured I might as well voice it.

Thanks again for starting this conversation. It's good to have all this
written out.

[janx]

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.

What if 'early revealer' needs to pay some penalty? In such case the value of putSealedBid transaction would be at least _bidPrice + fees + deposit, where deposit calculation is another question.

[pirapira]

@Smithgift

But how would the Collector know whether, say, 0x78ec64bb8319a432962e79252a373554ecd3cec759e53c41c3111c40b45127b3 is the hash of a short name or a long name?

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.

[alexvandesande]

@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.

when a new collector contract is voted in, I assume the old one sends its balance on to the new one.

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

Also, is this namereg to have support for parsing paths at all, akin to the ENS system previously proposed?

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.

Finally, it's a minor pet peeve of mine that domains as they are now have their elements arranged in order of reverse importance, contrary to the rest of any given URL.

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 (http://ether.fund/tool/converter). In all other moments the url bar displays it in the hierarchical order using triangles as separators: fund ‣ ether ‣ tool ‣ converter

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.

[Smithgift]

@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]

Please use bytes32 as the type of a (256 bit) hash. string is reserved for utf-8 encoded data - if you need to store variable-length binary data, use bytes.

[alexvandesande]

@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..

[Smithgift]

@alexvandesande

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.

[alexvandesande]

@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.

On Nov 22, 2015, at 12:16, Smithgift notifications@github.com wrote:

@alexvandesande

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.

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

[alexvandesande]

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

On Nov 22, 2015, at 12:16, Smithgift notifications@github.com wrote:

@alexvandesande

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.

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

[Smithgift]

I think the collector setting parameters like that is a good idea, too. "Collector" seems to be a less accurate name, but I'm not sure what else it could be called without sounding centralized.

[alexvandesande]

Comes from tax collector. It's not a manager or Administrador as it can't change name owners or ban people. Accepting suggestions.

On Nov 22, 2015, at 18:46, Smithgift notifications@github.com wrote:

I think the collector setting parameters like that is a good idea, too. "Collector" seems to be a less accurate name, but I'm not sure what else it could be called without sounding centralized.

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

[zelig]

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.
The url hint can just be a scheme name (or even one byte schemecode), this is enough for content (hash) addressed systems like IPFS or swarm which can simply update content by only resetting the hash map. To save even more, one could even have a default scheme so that say if a content hash has no URLhint entry, it is interpreted as a swarm hash. You may not want to commit to the content hash. So if a domain has no content hash but has a urlhint it is considered an insecure redirect. This allowswedding-shoesto redirect toaugur/markets/is-the-wedding-shoes-worth-more-than-USD1000` :)
Not entirely clear to me what information the distinction between registering namehash->urlhint or contenthash->urlhint should convey.

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.
I would just register protocol schemes (bzz, ipns) with electron url handler and simply pass the url to the scheme handler as is leaving the scheme do their preferred name reg lookups. The namereg for a scheme could use an ethereum smart contract (an instance of the registry template contract). This is obviously the case with swarm. In my view this is cleaner and more modular.

[zelig]

Also, is this namereg to have support for parsing paths at all, akin to the ENS system previously proposed? I see that this proposal handles auctioning TLDs, which is great, but I don't see anything to suggest how structured data might be handled.

@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.

[zelig]

@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 NewEntry(name, name_hash), which is cheaper. Then any off chain service can process the logs and create a phonebook (index of namehashes or content hashes), the most uptodate version is always registered as say bzz://phonebook. Note that it is trivial to verify that a reverse lookup entry is correct so if they are phony phone books, they will soon lose reputation.

[zelig]

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. bzz://<contract_code_hex> will resolve to the contract info json file (showing the source, compiler version and params which allows contract source verification for instance)

[zelig]

i think subdomain ordering is silly but i would suggest conforming to url standard so that existing url parsing libs can be used on our addresses in dapps. pragmatic decisions like this matter a lot in adoption

[frozeman]

I see it as follows:

• file:// === bzz:// - will only lookup swarm hashes/content (where you can also add the path, which is resolved by the manifest file). This way you're sure that bzz:// will only access swarm content, as with the file:// protocol you're sure it only access local files.
• http:// === eth:// - will look up things in the registry (done in Mist, so not every node needs to implement the same registry behaviour [though debateable]). This can point to a swarm hash, or HTTP link.
  If it points to a swarm hash you can add a path on the end, which is then resolved through the manifest file and not the registry. The registry only resolves domain names.

Special links like contract addresses, should be prefixed with contract:, like currently for emails, bitcoin or skype numbers (mailto:, bitcoin:, skype:). So it would be:
eth://contract:0x123456789098765432...

This would show a JSON with all the necessary stored information about a contract (Interface, natspec, source)

[zelig]

done in Mist, so not every node needs to implement the same registry behaviour [though debateable]

yes I debate this. As I said if they support IPNS or Swarm anyway, their resolver is already supported
In fact duplicating the resolvers code in mist is a bad idea.
But defining a great scheme specific namereg template contract is very important.

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.

[alexvandesande]

@zelig
Contract names, url hints and content hashes: I think all of those should be separate contracts. Maybe I'll remove all info from registry except owner and renewal date and let all use cases be handled by their own contract.

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.

[frozeman]

@zelig Why is it done twice?
bzz:// then shouldn't lookup a namereg, as it only needs to resolve the given hashes to a file.
We could also add a ipfs:// which only resolves to ifs hashes. This was the only real namereg is used in eth:// and all other protocols are protocol specific to one transport layer, like swarm or ipfs.

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 bzz:// shouldn't be the all in one solution. the eth:// registry is that (like http://, which can resolve to many things)

@alexvandesande concerning the contract:, this is to follow the browsers standard for specific actions. So click gin a link like this could actually open a specific mist popup, showing information about this contract.

We should follow the browsers standards, because thats the tools we have available and we have a lady a great way to extend them.

[zelig]

@frozeman we are going round and round. Please sit back and read my arguments again please.

bzz:// then shouldn't lookup a namereg
well it does, and so does ipns

@alexvandesande

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.

? in order for what to happen? for my dapp to be displayed in Mist? Why? That would be rather unkind.

[taoteh1221]

@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.

[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. 😄

[pipermerriam]

@taoteh1221 thanks for participating in the discussion 😸

[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? 😄

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?