Referencing this thread http://bt.irlbtc.com/view/2129.msg27968#msg27968

I think Gavin is trying to tell us the way forward .




BitDns is not bitcoin.  

We already have a forked chain.... Get something working on the test network and prove your theories.

Lets get it started in  here.....

In other words, this isn't really a distributed or P2P DNS system, or perhaps I'm missing something else here too.  Each "TLD" would have its own central server where you would have to "pay" to get onto that server?

What I don't see is the mechanism for how or even why a particular DNS server ought to even receive these fees as opposed to somebody else creating a "registrar server" and following this same protocol to put that data into Bitcions for considerably less or even "free".  This issue of where the money goes has been to me the issue all along, and the only place that could be identified easily as having done some sort of "proof of work" in terms of organizing the data is the block miner itself.... that is the Bitcoin block miner and not the DNS block miner as there is no sort of DNS block here at all.

I don't see any rationale for using a particular registrar other than merely because of sheer convenience and the hassle of setting up the software on your computer.

If there is some way that you might show some cryptographic "proof of work" in processing domain records, I might agree that a particular "registrar" deserves some separate fees in addition to the Bitcoin miner, but then the problem is how do you get those fees to that particular "DNS Block miner"?  Otherwise there isn't any sort of effort being put forth by the registrar at all where literally anybody could create some software to put these records into the system.

I could imagine a system where a sort of auction system on a particular domain happens where the person throwing the most number of bitcions in for a registration record "wins" the domain, but something seems a little off on that as well.  It also implies that anybody can "steal" your domain simply by throwing more coins at it than you have.  It is a great idea for miners, but lousy for those trying to register domains.

This is all about the money from my perspective, and this part has not been cleaned up for me upon reading the documentation.  The actual storage of the registration data itself has always been to me a trivial piece of the puzzle.  Throwing those records into Bitcoin transactions are useful as they do provide the time stamping and hashing ability of Bitcoin software, but any fees beyond Bitcoin transaction fees seem to be a pointless exercise without any sort of further proof-of-work.  Any additional fees being thrown with the "registration" is not going to anybody actually putting effort in terms of running the domain server or doing registrations.  I could imagine some "greedy" DNS servers that might expect to be paid for bandwidth and being paid in Bitcoins or some other currency, or perhaps a very small fee for actually putting the transaction into the Bitcoin blocks for those who only have a "thin client" for Bitcoins, but those fees would be subject to a huge and highly competitive market where for most people it would be "free" anyway.

This is why I was trying to put together some sort of proof of work chain for data of this nature too, in part to put some scarcity into creating domain records.

Please let's drop the idea of reserving the top names. Would you think it was fair if you owned the 1001st domain? It's only going to lead to disputes and hassles.

I suggest that we exclude all existing top level domains from DomainChain registration. So no-one will be able to register google.com through this system. They could, however, register google.domain but they would probably have to fight with Google in court under trademark law.

We really don't want the DomainChain system saying that it will "protect" 1000 names but "refuse to protect" all the rest.

If desired, an initial rush could be spread out by a phased introduction.

For example, in the first week only names of ten characters or longer would be accepted for registration. The next week, names of nine characters or longer would be accepted. And so on, until by week ten any length will be accepted.

A more sophisticated phasing would hash the domain name to a number from 1 to 1000. On each of the first thousand days, names that hash to that day's number are added to those that can be registered. So, by day 42 it would be possible to register any domain name that hashed to a number in the range 1 to 42. After day 1000, any name could be registered.

A third possibility is simply to limit the number of registrations. Suppose each block limited the maximum number of domain name registrations to the current generation difficulty divided by 1024. For now, that would mean 8 domain name registrations per block, but the limit would rise over time (quite quickly, I think).

I'm not convinced that a registration rush needs to avoided, but technical measures can be used to avoid a rush if it is desired to do so.

Who would be given the "authority" to remove domain names?  That implies central authority of some sort that has control over this network.

Domain squatting has a time honored and long tradition anyway and isn't going to change with how we are going to be running this system.  By setting up a system to "delist" a domain name, it also sets up the person or group of people with presumably some private key which can in turn authorize the removal of domains as a target for receiving judicial injunctions and potentially other sorts of legal problems.  If instead you can demonstrate that it is cryptographically impossible to change the domain registration information, all you can do is throw your hands up and say "I can't change that, sorry".

The owner of the IP address referenced by the domain registration should be the target of attack, not the domain registration system.

Then I'm confused about how else you would set up a system to arbitrarily remove a domain record from the DNS network?  If you got an idea on how to implement that, I'm interested.  The only system I can think of is to arbitrarily assign authority to "somebody" to take care of that issue.  You could have a "voting" system perhaps that would count up requests to eliminate a domain from a majority of the network and therefore "by consensus" drop the domain.  It would also provide an unneeded attack vector on the network as well as the "votes" would also be subject to some kind of manipulation that perhaps would be even worse than a trusted authority figure.

I just don't know of an effective way to kill a domain record shy of simply letting it expire.  As long as the registration is following the rules of the network (however we set that up), I don't see how it could possibly be removed.

The theymos/nanotube design is much more heavyweight than my design, in terms of how much data it stores in the block chain.

My design stores the domain name plus a couple of nameserver IP addresses (say, 50 bytes) for an everlasting registration.

The theymos/nanotube design needs much more data: the initial registration, the regular renewals, and the possibility to include actual DNS records themselves up to 520 bytes. There's talk of the renewals being required perhaps as frequently as every 2000 blocks, and certainly no more than every 52000 blocks.

Over 10 years, the theymos/nanotube design might store anywhere between 600 bytes and 120,000 bytes per domain name.

I'm starting to think that an everlasting registration really is the way to go. In the DomainChain design, the registration would not be affected by block chain compaction, since compaction only affects spent transactions. If you transfer a DomainChain registration, or modify its name servers, all of the necessary information is contained in the latest transaction, which will remain unspent until the registration is deliberately modified. However, the theymos/nanotube design requires a sequence of transactions (registration, extra fee, DNS record, ...) where only the last transaction in the sequence remains unspent.

I think users will be uneasy about having to renew every 2000 or even 52000 blocks. Having to remember to renew, in order to avoid losing your registration, is bad enough. But block generation rates are variable, so that you won't even know for sure when your renewal falls due. Unpredictable renewals are not something that would make me feel good about using such a system for my domain name registrations. I can see many accidental domain name losses occurring under this system.

Obviously there needs to be a business case made that non-expiring domain names will work. But there also needs to be a business case made for the renewal process of the theymos/nanotube design.

Re-reading this, I think I "get" how this is going to work for registrars, at least how Theymos is proposing here.

Each "Domain server" would separately and independently charge a fee for "registering" the domain on that particular server, where essentially everybody would be paid simultaneously when a new domain would be registered.

Something here just doesn't sound right, which is why I keep bringing this up.  I don't see the mechanism for recognizing new domain servers or what criteria ought to be used so far as to whom these fees are going to be allocated.  A domain server which is regularly being used by just a couple computers in a small office would in this case be a "peer" to a domain server at a major university servicing perhaps thousands of computers for domains.  Yet in this case both would be receiving registration fees and from a network perspective would be indistinguishable.  However getting "your domain" recognized by that major university server would be much more "valuable" than the server in a small office.  Any attempt to report usage could easily be manipulated in a number of ways making it to me impossible to realistically distinguish between the two servers, at least algorithmically.

Maybe I'm missing something fundamental here.  I sure hope so.  It seems sort of silly for somebody to set up a "domain name server" on their home computer and essentially sit back and earn bitcoins simply by being connected to the internet alone (no proof of work), receiving payments for domain registrations that are never used.  That sounds like a neat gig to get into, but I don't understand what "service" they are providing to the community for doing that or why the fees ought to be paid yet other domain servers who are clearly being used by thousands of computers are going to be considered "equal" and receive roughly the same amount of money?

Well yes, time based expiry is better for the customer, but the motivation for block-based expiry in the theymos/nanotube design seems to be that the transaction records are vulnerable to block chain compaction, which might happen after a specific number of blocks.

Of course, there is nothing that forces the providers of domain name servers to compact their copy of the chains, but then a new entrant into the business can't get all the data unless they can lay their hands on one of these uncompacted block chains.

DomainChain wiki is here:
http://domainchain.org/wiki/doku.php?id=start

There's not much there, but I will work on it tomorrow.

Meanwhile, some interesting further ideas on integrating with the Bitcoin block chain have been added to the Theymos/Nanotube wiki.