BitDNS and Generalizing Bitcoin

This is based on a discussion on 11/14/2010 on the IRC channel.

BitDNS

Although there have been attempts to tackle DNS in a distributed way in the past, I don't think there have been solutions that have fully removed authority from the equation.

If there was such a solution, it probably would have been able to implement bitcoin directly on top of it, and we all know that didn't happen.

However, it seems possible to create a bitcoin clone (bitDNS) that provides a solution to distributed authority-free name allocation and transfer.

Basically, the system is a copy of bitcoin where miners generate 50 new name mappings of their choosing whenever they win a block.  The name mappings change hands in a way similar to btc.

This system is separate from btc, and it is likely that escrow services will provide a name market in btc, since any such escrow can leverage the two block chains to verify transactions.  Miners can pick names that are already being bid upon with funds in escrow to make sure they are able to sell generated names quickly.

Generalizing Bitcoin: BitX

This is all well and good, but now there are two block chains, and any given miner can only generate for one at a time.  This will be really bad when even more clever applications are developed that require bitcoin-like properties but will be susceptible to attack in their early development.  Enter BitX, designed to support any and every such application on a single block chain.

BitX has a block chain like bitcoin's.  However, miners choose to distribute arbitrary application data in the following manner:

1) The payload in a block is a mapping from application names to hashes: ["bitcoin": <hash>, "bitDNS": <hash>, "bitHaiku": <hash>, ...]

2) Any given block is only allowed to create one new application that does not already appear somewhere in the block chain.  This is to prevent spam.

3) Any given block may omit data for any application.  Similarly to the current situation, miners have a choice as to what transactions to include, and this extends to the choice over which applications to choose to send data for.

4) Application data is transfered separately, so for instance a bitcoin client will never have to care about haikus or DNS names, as it can simply ask someone for the bitcoin payload and make sure it matches the hash in the appropriate block.

5) On the client side, blocks are only ever rejected for an error relating to the previous four points.  In other words, blocks aren't rejected for carrying a faulty bitcoin payload, because this might result in rejecting valid DNS transfers.  Instead, bitcoin clients accept the most recent block but ignore the invalid bitcoin transactions.

Miners will engage in activities they feel profitable.  For example, miners may not see a profit motive in haikus, but will want to generate DNS names because they can be sold easily.  I think this system could support a very wide range of useful applications while adding only a minimal overhead to the block chain itself.  Application proliferation is kept in check by the interests of the miners themselves.

This also seems to make the block chain more modular, as it separates concerns; the block chain is strictly for creating a universal state of the system for everyone in the world, and application data travels out of band but is verified against the block chain.

One effect of the modularity is that applications can ignore illegal or undesirable application data and only download payloads for the applications they care about.

As a last thought: BitX poses a significant threat to bitcoin, because money may not be the "killer app" for the block chain.  In other words, what happens when bitBeanieBabies becomes bigger than bitcoin?  Suddenly the bitcoin system doesn't seem as secure.  If both were running on top of BitX, they would enhance each other's security, and interfere with one another minimally.

Thanks for reading,
Appamatto

So....

I want to register a new domain name "gavin.bitdns" in this hypothetical bitdns system.

How do I do it?  Run a BitX miner and hope that I generate a block sometime in the next week or three?  Ummm... yuck!

Or I want to buy a domain from somebody; what does that look like in the bitdns system?

I thought about the BitX block format more today, and (with the help of ByteCoin on irc) decided that block rejection is an important part of the system.  So, the format would work more or less like the following:

<previous block hash>
<timestamp>

<hash of app name> <hash of app data> <previous app block offset>
<hash of app name> ....

<nonce>

Basically, there is the BitX block chain which is maintained in the first field.  But there are also "subchains" for each app.  The "previous app block offset" is the number of blocks to travel backwards in the chain to find the last previous block for this app.

Omitting some details, a Bitcoin fork would appear as follows, inside a non-forked BitX chain:

block 0:
<empty, this is the genesis block>
(bitcoin) datahash... 0

A previous app block offset of zero indicates that this is a genesis block for that app.  Each BitX block is only allowed to specify a genesis block for one app.

block 1:
<hash of block 0>
(bitcoin) datahash... 1

This is a continuation of the last BitX block and it also claims to be a successor of the previous block's bitcoin chain.

block 2:
<hash of block 1>
<empty>

It's perfectly legit for any given application to not appear in a block.

block 3:
<hash of block 2>
(bitcoin) datahash... 3

This is a continuation of the BitX chain, but it has rejected the previous bitcoin block.  Clients will now have to accept one bitcoin app block and reject the other, but there is no reason to reject the BitX block.  The rejected bitcoin app block will stay in the BitX block chain, but it will not be part of the longest valid bitcoin block chain.

I think that's exactly what I'm suggesting.  BitX is a block chain service (not sure how this differs from 'p2p proof of work') that supports arbitrary applications, such as bitcoin, bitDNS, ...

I've been thinking about your scheme appamato and as we discussed, rejecting invalid blocks and only working on the longest chain is a critical part of the security of these schemes. Therefore all hashing clients need to have the logic to tell the good from the bad. Ths could be done by distributing the appropriate logic for each app as java bytecode or .NET stuff. All clients would therefore understand all apps.

There would have to be some incentive to support an app in this way. Some form of payment.... hmmm

ByteCoin

I didn't read the thread, but you might be interested in the Netsukuku solution to distributed dns:
http://en.wikipedia.org/wiki/Netsukuku#A_Netsukuku_Domain_Name_Architecture

Netsukuku:
http://netsukuku.freaknet.org/

A lot of collaboration on a decentralized DNS by the bittorrent community is occurring here:

http://dot-p2p.org/index.php?title=Main_Page

The brainstorming session is here. BitDNS/Bitcoin could provide them with a lot of the source code needed:

http://dns-p2p.openpad.me/1

If you just allow any number of applications "on top" of bitcoin, isn't that a bit messy? Suddenly some guy says he invented this bitdns2 where all domains are available!

Maybe make it a tad bit hard to add applications?

I find tieing in bitcoins to DNS retarded. There are already some other p2p DNS systems that need help lifting off the ground why make a new one.
http://dot-p2p.org/index.php?title=Main_Page
http://wiki.opennicproject.org/dotP2PTLD

retarded means "slowed" which ironically is the case here

retard - cause to move more slowly or operate at a slower rate; "This drug will retard your heart rate"

meaning... using a bitcoin based dns will be slow to adopt

It is funny how people are thinking about the same issue at the same time.  I have been trying to think of some way that another "chain" using Bitcoin principles of hashing might be able to use Bitcoins as a transaction fee:

http://bitcointalk.org/index.php?topic=2028.0

The issue here is that you would need some way for those "mining" new blocks into this sort of DNS data block chain (or any other kind of similar data protected by a hash chain with miners) to receive some sort of transaction fee for processing that chain.  In this case, the incentive for processing the DNS entries would be to receive these transactions fees.... which could be quite considerable depending on what people would be willing to pay for a domain name under this system.

I have considered perhaps an alternative, which would have the main Bitcoin miners of the main chain have as "optional" transactions to be processing in such a way that could let the miner itself keep these transaction fees.  My main objection to doing that is that it puts far too much processing into miners and makes a bottleneck that I think we would all rather not have.  Bitcoin miners ought to be for bitcoin transactions alone, but it is at least something to consider.

This thread I mention here goes into the technical details, but it is something that could help with this idea too.  I haven't completely "solved" the problem, but I have at least identified what issues need to be solved.

Besides, it would be nice if there were other ways for those interested in using Bitcoins to be able to earn them since the main mining of coins is now being locked up with with stronger computers and GPU miners of various kind including server farms.

The one advantage here of using a fee is to avoid a tragedy of the commons, where those who want to register a domain or transfer "ownership" of that domain would have to put up real money to do so.  The fees don't go to some central processing bureau or organization, but rather to those who are doing the real work, which is processing the actual domain registrations itself.

How would domain name renewal work? 

I see. Then the miners will set the fee for domain renewal.

I assumed you would have the domain name forever without further fee. After all, we don't pay an annual fee to keep our bitcoins working.

The fees could come from domain name transfers, and of course the generation of new domain names.

It's the same as with bitcoins, it just makes the remaining names more valuable.

The loss of sex.bitcoin would surely make sexy.bitcoin and xxx.bitcoin more valuable.

I don't argue from a matter of principle, just from a personal preference that I would prefer non-expiring but losable domain names, compared to ones that must be renewed regularly or lost to others.

In theory you could also put a "lease" on that domain so that after a certain period of time defined within the network protocol the lease would expire.  In this case, if somebody "lost" their wallet the domain could become available after the lease expires.  It wouldn't necessarily make the domain worthless either, as the IP address associated with the domain would still be valid, and the domain would still resolve even after the wallet was lost, but if there was an issue where the person owning the domain switched to another network (and a different IP address) it could be a bit of a problem.

None of these are intractable problems, and IMHO much of this makes domain addresses much more secure than is the case at the moment with domain addresses you get from GoDaddy, Verisign, or ICANN directly.  Social hacking and some other generally minor hacking by somebody with just some casual knowledge about computers is all that is really necessary at the moment to change most domain registrations or "steal" a domain.

What do you need explained?

It depends on the domain registrar and a few other factors.  Back when ICANN ran domain registrations directly, all you needed to do was to simply spoof the e-mail address of the person who made the registration and change the contact information... hoping that the reply from ICANN would get lost in the junk mail with spam and other garbage.  Once you switched the contact information, switching almost everything else was incredibly trivial and a piece of cake.

It is a bit harder now and the domain registrars do require a bit more identifying information, but nothing that a good private investigator would be unable to provide.  Really, the current domain registration is incredibly insecure and there are even "legal" means to "steal domains" that merely need a pretty competent attorney to cover your back if you want to do it through the judicial system.  That is how nissan.com was taken from a small business in southern California in spite of the fact that the last name of the guy really was "Nissan" running a used car business with the name "Nissan Motors" and registered the domain well before the perhaps more famous automobile company got the domain changed.

On top of that, the DNS system itself is very much open to attack as long as you can somehow get trusted as a "peer" by one of the main root servers.  There are various kinds of attacks upon DNS records themselves which can be done, some easier than others and some of them requiring better knowledge about computer networking than others, although there are some "kiddie scripts" and "hackerwarez" that you can get to do all of this is you really want to.  I'd strongly suggest staying away from those program mainly because they are trojan and virus sources if you try to just Google for them.  In other words a good way to get your system rooted and part of a bot net not under your control if that is your goal.  If you want to go the hacker route, learning about the protocol itself and sticking to discussion groups is a much better route to go.

None of this is new to somebody who is familiar with the DNS system, and it really is just a house of cards much flimsier than what anybody can possibly believe if you aren't familiar with how it was all set up in the first place.

My point is that using a simple sort of cryptographic storage for the registration of the information is vastly more secure in terms of making sure the information doesn't get tampered with or manipulated that the current system.  Even DNSSEC, the supposed "savior" of the DNS system to keep spoofing from happening (and largely unimplemented by most ISPs unfortunately even for that level of security) is only as good as the domain registrar's security.  Social hacking can still happen.

It is for this reason that I think a bitcoin-related system would work much better and be insanely simple to operate.  On top of that, there would be no gatekeeper in terms of who gets authority to decide if you get the registration.  You simply apply, throw in the fees for processing the application, and the domain registration gets put into the system.

In terms of the "leasing" option, the only advantage of doing that which I can see is to make sure that the domain itself remains in the "public domain" at some point.  Domain registration is a public service and unfortuantely there are people who have taken domain registrations as a sort of "land grab" where the earliest get the best stuff first.  By putting a leasing ability into the standard (and the "lease" is from all of mankind, not any individual), it forces those who grabbed the domains early on to do some "work" or at least pay up to maintain those leases.  Presumably if maintaining those domains is expensive, they'll simply let them expire rather than having to constantly renew the domains.  It also provides a source of revenue for those who are mining blocks as well so it also maintains the integrity of the database... in other words the chain of blocks being used to keep track of all of this information.

I don't have a problem with somebody "renewing" their lease in some manner where they have at least "first try" at keeping that lease.  The "public good" coming from paying the lease fees is maintaining the network.

I don't understand this "sending it to yourself" however.  The domain registration would be something confirmed by a network.  If you were mining these blocks, you might get lucky and mine the block you are also using to register a domain, but perhaps you wouldn't be doing that either.

Knew it. They sucks.

Our opportunity is now, but unfortunately I think we lack the expertise to create a BitDNS.

Let me clarify how I understand the BitDNS idea. First, I think it is somewhat misnamed, as we would not propose to replace the entire decentralized DNS infrastructure of A records, CNAMEs, TTL values, etc. What we want to change is the registrar function, which keeps track of who owns each name.

A domain name entry in this system has 3 parts:

 - the name itself (e.g. example.bitdns)
 - a hash of the owning public key (e.g. djiusjfkrhffhdehyormavtrr...)
 - the IP address of the authoritative DNS server for the name (e.g. 1.2.3.4)

When you generate a block you get to create 50 of these entries, and you then own those 50 names. Of course they have to be new names that were not in earlier blocks.

Subsequently a name might have two things happen to it:
 - the IP address of the DNS server might change
 - it might be transferred to a new owner

Both of these might be handled the same way, via a BitDNS transaction. The transaction would contain:
 - the domain name
 - the new owner key hash
 - the new IP address of the DNS server
And it would be signed by the old owner private key.

As with Bitcoin, transactions would be broadcast and incorporated into the next block by miners.

Is this what people have in mind?

I hope we aren't at cross purposes here as there are multiple ideas.  My idea was more that you would throw in a "transaction" that would have a few bitcoins attached (as the transaction fee) so that any potential miner would be encouraged to put that particular "registration" into a block chain like the Bitcoin mining blocks.  The "owner" is merely the person who paid the fee and is identified by a private/public hash like the Bitcoin addresses are being used right now.  In fact, I would propose that the "owner" of a particular domain might as well be a Bitcoin address unless we can think of a more secure way of claiming such ownership.... which would be of value to the Bitcoin project if you can show it would be unsecure.  It is tying the domain ownership to your wallet.dat file making your wallet even more valuable if you got one of these domains.  The actual hash is irrelevant other than it should be defined in the protocol.

A block would have a limited number of "transactions" in it... perhaps just 1 but it could be 50 or slightly more.  I don't mind putting a limit at 50 per block in the sense that it might drive up the value of an individual domain and set up some interesting economic theories so far as supply and demand are concerned.  That is a network rule to define in this case.  Obviously a miner could create one of these "domains records" for "free", but then again they are contributing to defending the integrity of the database through CPU proof of work.

So really a domain entry would be:

 - the name itself (e.g. example.bitdns)
 - a hash of the owning public key (e.g. djiusjfkrhffhdehyormavtrr...)
 - an optional key which could identify a "new" owner in the case of somebody transferring control of the domain
 - the IP address(es) of the authoritative DNS server for the name (e.g. 1.2.3.4)
 - transaction fee paid in BTC

A block entry would also have a timestamp that could be rejected if it was for some time in the future

As a network rule any name collisions that can't be resolved as from the same person making a request for changes would be rejected.  The cost to run this network would be through the transaction fees, where a "miner" may be as inclusive or selective as they care based upon the transaction fees involved.  Miners might have a different fee schedule for "new" domains as opposed to existing domains and could discriminate on that basis... or simply only select to process one kind or another.  All of this would be essentially a marketplace where those trying to "register" domains are playing chicken with those making the blocks, presumably with the miners wanting higher fees and those registering domains wanting lower fees.  My bet is that domain registration fees would be considerably lower than what GoDaddy charges or for that matter any other domain registrar other than those who simply do it for free.  Maintaining the DNS records does have a cost, which is the purpose of the transaction fee as well.

The only glitch here that I can see is trying to get those transaction fees to the miner.  The miner needs to be able to demonstrate proof of work before they get paid, and presumably that the proof involved has generally been accepted into the network before they get paid as well.  Otherwise, all I can see is that people are being altruistic and simply mining as a free public good.... which has problems related to a tragedy of the commons as well.  I personally think that you should "pay your own freight" for things like this.  Besides, it provides another way for people to earn bitcoins simply by leaving their computer running if you can get the transaction fees for running such a DNS mining application processing these records.

BTW, I created a stub of a document on the wiki for this concept if anybody is interested in filling out some more details of this idea in terms of a formal spec:

http://www.bitcoin.org/wiki/doku.php?id=bitdns_draft_0_1

I'll see what I can contribute to filling this out, and I'm thinking of bumping this idea up on my own priority schedule for perhaps writing an application to do this.  It sounds like something to really get my teeth into even though I got a couple of other good ideas I'd like to try.  Besides, it sounds like there is some real interest to get this going sooner rather than later among many in the Bitcoins community.

I see, that makes sense. I have an idea about the transaction fee. What if this were integrated with Bitcoin itself? This would be a different kind of transaction that would be mixed with regular Bitcoin transactions and included in regular Bitcoin blocks. Then the block creator would automatically receive the transaction fee just like all the other tx fees in the block.

If that sounds good, I see a way this could be implemented into the current Bitcoin system compatibly with current clients. We could use the mysterious and extravagant "scripting" system to add additional data to regular Bitcoin transactions. These would look like NOPs to current clients and be ignored, but BitDNS aware clients would look inside this NOP block and see the extra DNS data, and interpret it as BitDNS transfers.

Specifically i could imagine using OP_NOP1 to mean BitDNS, then OP_PUSHDATA to push the DNS info, then OP_DROP to drop it from the stack, followed by the regular tx opcodes. This will have no effect on regular clients and look like a regular transaction (can be a dummy tx, 0.01 to yourself) but BitDNS aware code sees a BitDNS transaction. This is actually a powerful general technique for adding overlay protocols to Bitcoin.

People already put up links about BitDNS.

A domain name key should be so important that people will backing it up, automatically.

The likelyhood of the idea getting implemented is likely slim to none.

There are others into the subject of a P2P dns as well, Peter Sunde (former spokesman of the pirate bay) was also talking about this a couple of days ago.

Check out http://techcrunch.com/2010/11/29/peter-sunde-seconds-the-idea-of-an-alternative-root-dns/
and http://dot-p2p.org/

If you lose the keys, you can no longer sell the domain name or change the IP address of its DNS, but the domain name itself doesn't immediately stop working. So you have plenty of time to choose a new domain name, set it up, and install redirects from your existing site.

You can protect against this by leaving a copy of your keys with a couple of trusted people. That's a much better solution than leaving your domain name hostage to an untrusted registrar.

In the 1990s, Turkmenistan was selling .tm domain names and I registered one. After a couple of years, the Turkmenistan government decided there were .tm websites they didn't like and they removed access to the domain name. But there was plenty of time to get a new domain and install redirects. It worked just fine.

Ultimately, a name is just a name and it's not the end of the world if one is lost. Even cocacola.com could switch to cocacola2.com and it wouldn't be the end of the world.

Where do I pledge?

Best way to get the BitDNS system running off the ground?

Adapt the bitcoin source code?

Ribuck, If only I have the necessary knowledge to adapt it, I would have dropped it and just implement it.

Speed is of the essence if we're going to show .p2p how to really do distributed DNS.

Github and git. I like. It's distributed version control system. Any developer can fork the project and continue on their own implementation and they can request pulls as necessary.

Also remember, everything is in version control. If you messed up the code, it's not a big deal. Just revert to the last state. Remember to commit as well push often too.

By all means, pledge some bitcoins if you can't code, or do anything. I can't do any of the real important stuff, but I can show that I am serious.

There still are some technical challenges here that I am not completely sure how to solve.  In this regard, all of the help we can get will be appreciated and there will certainly be some "heavy lifting" where I think there can be some good division of labor in terms of separate parts that can be worked on.

Major areas will include:

* GUI design - coming up with the visual appearance and organization for the project.  Most GUI design is simply awful, and it is something I've struggled with over the course of decades and still don't get done very well.
* Networking communication - How the client will communicate with other nodes?  Even that is something which can be sub-divided after a fashion, but it will be a crucial piece.
* Database organization and communication - Even choosing a database route isn't going to be easy, either from a "roll your own" to something like MySQL or BerkleyDB.  Potentially this is something which could get into the terabyte range for storage requirements, so we do need to be careful on some of the decisions we make here.
* DNS communication - ideally what should happen is that the client would become a source of domain information that could be referenced with other DNS records.  For a home office/small business this could be on the same computer but for some businesses or schools they could even put this in their server room as a part of the main domain resolver path for their network.
* Interfacing with the Bitcoin network - How will the usage of this software connect to the Bitcoin network, transfer payments from "registrants" to "registrars" (aka "miners"), and what is a "fair" way to make sure that the people receiving money are going to be paid?
* Thin client design - How can you set up something that would retrieve the "database" yet not be a miner?  Is this even an issue?

Non technical issues include:

* Establishing Problem Domain - just what is it that this software needs to accomplish?  Who would use it and why?  What is it that they need?
* Potential Social Conflicts - What sort of "legal" requirements might there be for "domain registrations" and what do we do about them?  Do we care?  Even if we ignore the law in this case, what would most network users expect from a domain registration?
* Marketing - How do we sell this software so far as to get people to use it?  How can publicity be spread about it once it becomes available.  What sort of outlets are there which might be interested in using this.  If we told a business they could run a domain server and make money (by "mining" registration applications) simply by having it in their server room, would that be something they might adopt?
* Finding "customers" for domain registration - This is more to the marketing, but with a concentration on just those who might want to use domain registration.  Some of this is also going to be an issue in terms of breadth of the adoption of the concept, but what groups might be interested in using this as registration?  Obviously bitcoin users would be an early adopter, but anybody else?

Some of these have some "milestones" that must be met before other things can happen, but at the same time there are things which can be done simultaneously.  Any other ideas for things that might be facing this in terms of a breakdown of tasks?

Kiba is wise.

Remember, speed is of the essence. We can alway replace the database with something else, but not time.

All non-essential features should be blocked from implementation focus.

That mean the core developers don't work on a fancy GUI. They will focus on:

1. The mechanism to mine, register, and change a domain name.

2. The mechanism to distribute or output the DNS database.

Yes, the core developers should be focused on the network and the protocol.

I am making it my project to write a BitDNS client. I don't need the bitcoins. I just want to help so that the core developers can focus on the important stuff.

It's easy for me to change the name of the git project, whatever you decide. Still BitDNS is catchy.

Exactly. The domain name block chain.

Anyway, I have registered domainchain.org, in case people like it. I think DomainChain better-explains what's going on than BitDNS. But I won't object if people prefer another name.

+1 on DomainChain or BitRegister over BitDNS (no offense kiba )

Ooooooo...  I like BitRegister.  DomainChain works out pretty good too and is very descriptive.  I'm so used to BitDNS that I am still somewhat partial to that, but it doesn't exactly explain in a single word what this is going to be other than a shortened form of "Bitcoin DNS".

I'd like to get back to the topic of the scope of the domain naming system itself.  I would like to propose the following specification for actual name of the domain itself:

A domain can include combination of unicode (UTF8) characters with the exception of the period character (U+002E).  We may want to look at some other restricted characters mainly for conformance with normal URL schema as defined in RFCs and avoiding control codes, but I say that right off the start we permit non-latin characters into this scheme.  Other "excluded" characters may include the "/" character (U+002F) or the other non-alphabetic characters common found in the original ASCII specification.  The period character here is something more special, however.

Some possible domain names would be "excluded" from this schema and held in common such as excluding domains named "com", "net", "edu", or any of the standard country codes as currently under the purview of ICANN.  If ICANN wants to get into this game and claim those few domains, I don't mind giving these domains directly to ICANN, but the issue here is mainly to avoid naming collisions with other network resources.  If/when that becomes an issue, a technical solution can be found and it is irrelevant.

"Sub-domains" can also be established using a "dot" structure off of a previously established domain name.  For example a certain oil company could create a domain called "bp" and then create a sub-domain like "usa.bp".  When a registration of this nature happens, some sort of signed public/private hash key confirming permission to create the sub-domain is confirmed (similar to transferring ownership of a domain) before the sub-domain record is kept.  It may be possible to create a domain that is simply a "free-for-all" of sub-domains and defined as such when the domain is created.  An example of this would be a domain named, "bitcoin" and "btc" which would permit the creation of a domain like "mtgox.btc" or "mtgox.bitcoin".  On the other hand somebody creating "this.sucks.coca-cola" may have to negotiate with the domain holder of "coca-cola" in order to create those sub-domains.

Since the sub-domains have their own record, they can also point to separate resources including separate IP addresses.

Essentially, this is also allowing anybody and everybody to create their own top-level domain and charge whatever they want to use that "top level" domain, but it also makes such TLDs essentially worthless for the most part too.

I'll be nice and give "p2p" to perhaps the "dot p2p" folks as well if they want it.  I'm sure somebody would be willing to donate 0.01 BTC to get that record into the database.

Are there any flaws with this idea, or should it "go official"?  

OK, but not so fast! Is there an existing standard we can be compatible with? It will save us some time, and probably also save us from making some mistakes. I know the existing domain names use a weird encoding system ("punycode") for historic reasons, and I'm not suggesting to replicate that. But working with an existing list of valid unicode characters would make sense.


Hmm, can this work? I had assumed that the DomainChain names would all take some standard suffix so that they can integrate smoothly with the existing domain names. Just like .p2p is being used for the non-decentralized project. Otherwise, what if someone registers (say) foobar and next year InterNIC adds foobar as an official top-level domain?

If you have registered a domain name, you automatically get the ability to create whatever subdomains you want. Subdomains are just records in your domain name server, under your control. The registrar doesn't need to know about them.

Where the incentive for generators to get paid?

On the other hand, it won't be limited right? It will be a unique name of some kind.

The existing standard is that ICANN is being very stingy on allocating top level domains.  That, for myself, is a major mistake and if you read some of the links above written by Karl Auerbach he points out that this is completely artificial and arbitrary.  There is no current reason to exclude any alphanumeric sequence for a domain name of any kind.


So, who cares if there is a collision?  If somebody registers that domain, somebody at InterNIC can try to find out who owns the domain with DomainChain and negotiate a price to transfer that domain to themselves.  BTW, I think some sort of "comment" field could be put in with domain registration so you can attempt to contact the domain owner (completely optional BTW!) if they might be interested in "selling" the domain.  That seems like InterNICs problem, not ours.

They are the competitors to this protocol and this is something they should have done from the beginning.  That they aren't doing these things is more why this is something that should be done in this fashion.  There is no reason a million or a billion TLDs can't exist.


Yes, I realize that the current DNS structure allows you to use a "dot" off of the previously established domain.  The only reason for sub-domains is to create a system where "ownership" of a sub-domain can be transferred and have that ownership be kept track of through the DomainChain rather than as something arbitrary which can be revoked by the domain owner.  In other words, once "mtgox.btc" is registered as a sub-domain, it in effect becomes a full-fledged domain in its own right with the protections and controls that would go with a proper domain and would be recognized with a separate domain server for any of its sub-domains.  Basically this is a way to create the notion of a "TLD" registration system too if you wanted to stick with the convention of <server> <dot> <TLD>.  In practice I think such notions would eventually be dispensed with entirely, but perhaps there might be a reason to keep it going.  This system also meshes in a bit better with the current DNS system where collisions would be avoided as a natural part of the protocol rather than a hard arbitrary exclusion of certain words and names... thus simplifying the overall protocol.  Those TLDs currently operated by InterNIC and ICANN can be held in "escrow" by a member of the development community until such time as ICANN decides to pay up or take ownership of those "domains".

Note here that you can go to a domain server operator and "pay" them some money to create a subdomain off of say "mmorpg.org" for a game you made called "coolgame.mmorpg.org", but you are still at the mercy of the domain name server in the same way that everybody is at the mercy of ICANN and InterNIC (as well as the other domain registrars) for simply getting into the game.  That sub-domain can be arbitrarily terminated for any reason at all and would force you to go through the judicial system to get the subdomain put back in.  I think that is something the network philosophy is trying to avoid in the first place.  This alternate method would imply that such sub-domains can't be arbitrarily shut off unless the sub-domain owner is willing to relinquish control.

Here is an idea for how miners can get paid.

Let us start with a fork of Bitcoin. We will start a new block chain just like Bitcoin did two years ago. There will be coins in this chain, which I will call bitdnscoins. People can pay bitdnscoins to each other via transactions in the BitDNS block chain, just like with Bitcoin. Block miners get 50 bitdnscoins.

However in addition to bitdnscoin transactions there would also be domain name transactions. Here is the main idea: at any time a bitdnscoin can be converted into a new domain name registration via a special transaction. This uses up the bitdnscoin and it can't be used again. There would also be 'maintenance' domain name transactions where an existing domain name is transferred to a new owner or has other data fields changed.

Bitdnscoins represent the right to register a new domain name. They are valuable for this reason. You would acquire them by mining, or more commonly by buying them, with Bitcoins, dollars, etc. To register a new name you need a bitdnscoin.

And the incentive for miners to include transactions? Same as for Bitcoin: transaction fees. Registering a new domain name costs 1 bitdnscoin. But you can pay more, and the excess goes to the miner. Pay 1.2 bitdnscoins for your new domain name, and 0.2 of that goes to any miner who includes your transaction. That's the incentive.

Well, I've proposed that Bitcoins be used as an incentive for mining the chains, which I suppose is a way to promote the use of Bitcoins as well.  If you are talking about the "miners" simply creating their own floating currency that could then in turn be put into one of the exchanges.... that may solve the problem of getting miners paid (hmmm.... I've got to think about that one for a little bit) but it does create the problem of what anybody is going to do with that "floating currency"?

Just thinking aloud here... if we used a "floating currency" in this system instead that was a "DomainChain coin" similar to Bitcions but not pegged to Bitcions as all, could that work here?  I'm sure Mt. Gox would certainly be interested in exchanging these coins if they had some value, and the point here is mainly to come up with the formula for creating these coins.  The only real use of these coins would be to pay registration fees for domain names, so I think the drop-off could happen a lot faster than is the case with Bitcoins.  

In theory we could even set up some sort of link to Mt. Gox or some other trader so that in the interface you could do a "quick buy" of these "DomainChain coins" in such a way that for an end-user they would be buying them with BTC and then putting those recently purchased coins right into the transaction as a fee for the miner to claim when it gets put into the chain.  If the transaction block is rejected, that miner loses the claim to those coins and they become unconfirmed.... where it is the responsibility for the exchange to worry about the validity of a particular set of "DomainChain coins".  A similar kind of "quick exchange" could even happen with LR Dollars or any other currency that may be tied to some exchange system, or they could simply get the "coins" on a "manual" basis from the exchange if they wanted to get a better exchange rate or have somebody "send" them some of these "DomainChain coins" with a direct hand-over of cash.

I like this a whole lot.  It may "solve" this problem I've been thinking of in terms of getting miners paid.  Are there any other hiccups anybody sees with this situation?  The exchange itself isn't even fixed.

The only real problem I see is that it sets up a situation where this kind of currency could supplant the main Bitcoin for intrinsic value.  Not overnight, but gradually.  We need somebody with a whole lot more economic theory behind them to figure this one out, because I would vote for a "weaker" currency than Bitcions be set up in this situation, however we want to define that.  How would you set up the parameters for a relatively strong currency that the desire would be to trade it in for Bitcions instead when possible?  Would the fact that Bitcions has an absolute limit but these kind of "DomainChain coins" would continue to inflate (aka the 50 DCC produced per block would continue to be produced indefinitely creating a mild sort of inflation over time) be sufficient to make Bitcoins stronger?

I need to think overnight on this particular subject as it is starting to make my head ache thinking about it, but it sounds like an interesting idea to seriously consider.

I'm fine with that.  It is an easy way to allocate the coins.  The role of the halving of the coins "mined" every 2-4 years was mainly to strengthen the currency from an economic perspective, and something which many of those involved with the development of Bitcoin feel is necessary including Satoshi.  I don't think it is nearly as critical in this situation, and as Bitcoin itself has proven there are people who will find value in the currency even if it doesn't half (as it hasn't yet).

Good. Something everyone completely agrees on!

So the formula for creating problems and adjusting difficulty will be the same?(Forgive my ignorance)

Care to stick a wiki up on there?

Well people couldnt say domaincoins werent backed by anything.  

I like the idea of a constant block rate.

100 domains per block is 25 years.

150 domains per block is 18.5 years.

200 domains per block is 12.5 years.

Personally, I don't feel like I am a rush to do a lot of domain registration fast. 15 years is good enough for me. We don't need to register tons of domain within a few short years, since not everybody will be willing to switch from central to decentralized.

Also, the population of humanity ain't likely to grow forever... So we can expect that growth at some taper off at some point in the future.

However, this generation rate have the potential to spark a long debate..so we need a method that let us decide quickly somehow.

I would like to ask for some clarification on exactly what we are proposing here.  From reading this (lengthy) thread, I gather that we are proposing:

• A decentralized domain registrar that maps a friendly human readable name (ie: chaord.btc) to an ip address
• A parallel network bitcoin which will have it's own token currency (represent addresses).  Rather than mining bitcoins, you mine top-level address rights.  Is this correct?

Am I understanding all this correctly? If so, it seems as if in this brave new digital world, bitcoins (BTC) represent a commodity like gold, and domaincoins (DCC) represent real estate.

Lastly, I'm sure this has been discussed, but is there any way that the two system can be combined?  Can the domaincoin system accomplish all things bitcoins can, in addition to domain registration, or no?  IMO the best of both worlds would be if, somehow (not sure how), the domain coin system could use bitcoins as its underlying backing (or vice versa).

Honestly, I feel that something like DomainCoins is the "missing link" that this community is searching for.  Because the data behind DomainCoins actually represents something (an IP address mapping), I think this could be the use-value that something like bitcoin needs to propel it to success!

Wait, I am a bit confused. Alternative currency for DomainChain?

Oh, these represent addresses?

Doesn't seem hard to me. It's a normal trade to me.

So you need two clients running?

edit:never mind...

A coin would represent the work or effort to administer the database.  That is the "reward" a miner gets for processing the domain records.  That it might cost 1 DCC to enter a record into the database is just the "fee" to play the game, where you are buying the effort from previous record keeping efforts.

At any rate, do we have enough information that's agreed so that the core hackers can develop right now?

This was on another thread but is relevant here. It is true, the first domain name is likely much more valuable than the millionth. So even if we don't reduce the number of DCC per block, the value will decrease much like Bitcoin does by halving the block reward every two years. That means transaction fees might have to rise substantially over time.

Is it worth considering to increase the block creation rate above 6 per hour? If we generate blocks every 5 minutes or even every 2-3 minutes instead of every 10, that would be another way to speed up domain name availability.

+1 on that.

I RAGE.

Those are the stakes on the table people.

I'm not sure how it would work to only create one coin per block. Would this only buy the creation of one domain name?

The reason I like the idea of fractional coins is it would give more flexibility in transaction fees. If it costs one coin to register a domain, it might make sense that a good size for the transaction fee would be fractional.

One of the reasons to maintain the 10 minute interval between blocks is because of network latency from distant node in terms of "hops" between nodes.  If you shorten the interval you risk more "collisions" between nodes that may have simultaneously created a "successful block".  In turn that also can make even longer "chains" start to compete against each other.

In other words keeping the 10 minute interval may be a very good idea or even increasing the interval could have benefits.  I know of at least some blocks even with this average that have time stamps which even go "negative" where the successive block is timestamped a few seconds before the previous block.  More likely it was created at almost the same time but the other block literally was created a matter of a few seconds earlier.

I would like to put in perhaps a more continuous or shorter interval between difficulty adjustments, but then again there are some network attacks which are thwarted by the two-week readjustment system.
The exchanges might really appreciate at least some fractional quantities to play with, although that could also be internal to the exchange itself.  The real advantage is for some granularity in terms of competing miners which might want to snag a few additional registrations.  It would also help in terms of setting up a per-kilobyte charge for people throwing stuff into the coin transactions too.  Attacks on the network can also happen through filling up coin transaction information with useless junk, and charging a fee for that can help stop or at least slow down such a flood attack and at least put cost to such an attack that must be borne by the person making the transaction.  Such a charge may require at least some fractional coins, even if it isn't nanocoins necessarily.

I'm going to put my thinking cap on here, because I think ideally if we could do this under one umbrella (either by expanding bitcoin to encompass domainchain or vice versa) it will strengthen both projects.

So if you spent a coin to register a domain, then it stay frozen until the domain expire?

So domain name generation are limited by the velocity of miners spending, but then they have to generate a block to get the coin.

We need to get Satoshi's approval if something goes into the main Bitcoin client.  There are other applications involved here besides the DNS system, even if that seems to have high priority at the moment.  We could create a patch that would put hooks into the Bitcoin software to permit these kind of changes, but it could also be for naught if Satoshi rejects that patch.  Since this is also a major architectural change to the software, it seems highly unlikely that it would get accepted unless we can demonstrate a clear need for this idea or show some huge benefits that would help Bitcoin be adopted as a currency.  It is also a whole bunch of software development that depends on just one person accepting that change on essentially a whim.

In short, if we decide to put this into Bitcoin, Satoshi is the gatekeeper.  We could completely fork Bitcoin, which is essentially what we are proposing here anyway as the alternative with these separate coins.  That is our choice.

Would introducing extra overhead into the existing chain make this cumbersome and maybe introduce vulnerabilities into the financial system?

After all who wants to download a massive block chain just to buy or transfer a domain name?

Is it enough that a parallel domain chain is certified as the way to get a bitdomain? Do we want developers concentrating on other applications rather than the core purpose of bitcoin?

It seems this could be a way for bitcoin to have its own "app" store of different block chain purposes. 

Yes I'll do this. Don't panic!

But first, I've thought of a design for DomainChain that is simple, elegant, powerful, and very easily integrated with Bitcoin. I just need to think it through a bit more before I post it here so that I don't make a complete fool of myself.

<--- In another thread.

So there's an economic calculation problem. We...cannot reliably predict how many domain name registration are needed each block.

So we going to need to price generation of blocks, somehow?

OK, here goes. My design for DomainChain builds on many of the ideas expressed here already. My main contribution is to remove "generation" from the design. It turns out that relying only on transaction fees makes everything very much simpler, and makes it easy to piggyback DomainChain onto Bitcoin.

Here's a quick summary:

• Bitcoin already allows for a text "payload" to be included with a transaction. Any bitcoin transaction that is sent with the right payload becomes a domain name registration.
• To register a domain name, just send any amount of bitcoin to yourself, with a special payload. This payload identifies itself as a DomainChain payload, and contains the desired domain name plus the IP address of the authoritative name server(s). If no-one else already has that name registered, it's yours.
• To transfer a domain name to someone else, just send them the associated bitcoin (actually any part of the associated transaction will do). The GUI will let you do this in terms of "domain names" rather than in terms of "coins".
• To change the authoritative name server(s), just send the associated bitcoin to yourself with a payload that identifies the new authoritative name server(s)
• Registrations last forever unless you terminate them by sending that bitcoin to yourself with a payload that is a DomainChain "cancel" message
• You can register a domain name with the smallest convenient amount of bitcoins (currently 0.01 BTC), so the system imposes no scarcity of domain names. However, miners will impose transaction fees which increase as the block size increases. This provides a disincentive to registration spammers
• To resolve (lookup) a domain name, the block chain is scanned for the most recent valid transaction for that domain name. In principle, anyone can run a DomainChain resolver, but in practice most users will use a DNS service that is DomainChain-aware

Advantages:

• Provides domain name registration with the same level of pseudonymity as Bitcoin
• Holds registration data in a tamper-resistant distributed manner
• Strengthens Bitcoin by providing additional economic incentive for generators (because they will be able to charge transaction fees for domain name transactions)
• Can be implemented much more quickly than any other scheme that has been proposed so far
• Existing bitcoin clients are unaffected. If they receive coins that are associated with a domain name registration they will see them as coins. do not display domain name registration transactions. No modification is needed.

Disadvantages:

(I'm sure you'll let me know of the disadvantages.)

Implementation:

1. Patch the standard bitcoin client. Run it on the bitcoin test network. The patched client will have a separate panel for domain names that are associated with bitcoins. These bitcoins will not show on the standard panel, nor will they be included in the total balance available to spend. On the DomainChain panel, instead of a "send coin" button there will be buttons for "register a new name", "change nameservers", "transfer a name" and "abandon a name". There will also be a scrolling list of domain names together with their nameservers.

2. Write a program that scans the block chain to determine the authoritative domain name servers for a given domain name. Patch a standard open source domain name server to consult the output of this program as part of its name resolution.

3. If it works well, persuade Satoshi to allow these transactions in the main network. Of course, it would be technically possible to run it on a new network with a new block chain, but who wants competing currencies?

There's obviously a lot to be fleshed out, but I think the design is workable and easy to implement.

Ribuck: I believed that is a brilliant hack. We finally have intrinsic value for bitcoin!

Nanotube and I have been working on a DNS spec that is quite similar to yours. We had hoped to have a private RFC period, but since your proposal is so close, we decided to just publish what we have now.

http://privwiki.dreamhosters.com/wiki/Bitcoin_DNS_System_Proposal

Some sort of expiration is required, preferably a short one (the 52,000 blocks used currently in this spec is probably too big). Having a short expiration requires everyone to rebroadcast their messages, which solves two problems at once:
- With an expiration of x, you can build a complete DNS database by downloading only the most recent x blocks. Having an unlimited expiration would require you to download the entire block chain, which will eventually become several terabytes in size.
- Spent transactions more than y blocks deep can be completely forgotten from the network. The value of y is currently unknown, but I expect it to be between 5,000 and 52,000. Messages need to be rebroadcast at least this frequently to stay alive if you want to use the convenient one-coin-per-domain system.


You can't receive non-standard transactions if you don't know the format (even if it just has some OP_DROP data). Normal clients will ignore such transactions.

I haven't read your spec yet, but...


That's fine. It's not problematic in my design.


That's also not problematic. If someone wants to work with domain names, they will use a domain-enabled client.

My concern is that there would be a rush to grab hot domains. I would expect that the first blocks generated with this system will all be maximum size and filled with the equivalent of sex.com. These domain names are worth millions of dollars, if the system succeeds. I suppose transaction fees would be enormous, otherwise miners will just fill blocks with their own registrations. Ordinary transactions would be crowded out, if this were part of Bitcoin.

What do you suggest is a better way to decide who gets sex.domain?

just to be clear, it's nanotube's+theymos's proposal

and, we're still working out some kinks in the protocol. consider this to be an open RFC period. it's a bit too early for 'consensus'.

Simultaneous inventions are not surprising. This phenomenon had been happening throughout the history of science and invention.

I'm looking at the fees, which certainly would be a reason for a miner to include these into a block with a high priority.  Still, I'm trying to find any sort of motivation for a "DNS Server" to recognize any of this data other than as a repository of potential domain information.  There is a reference to a "vibrant market" for the fees being used here, yet this seems very altruistic that one of these servers would recognize any fee at all if they aren't getting any themselves.  I guess I'm missing the point of the fee other than as a way to provide an incentive for miners, and to put a little pain on the registrants involved here.

I suppose that this is in effect a way to ensure that the Bitcoin network stays strong, as it certainly is going to be making any sort of mining activity much more profitable by doing this.

What pricing strategies that would be used by a domain server which would have an adjustable price in the interface or config file and why one server would set the "price" at 10 BTC or another at 15 BTC or still another at 5 BTC?  Is this basically "filtering out spamsites" or is there something more serious going on here?  Is this simply an "open bid" for each domain where the most money invested "wins" the domain?

Toward the end of the document there is a reference after a fashion about some more complex fee allocation system that passes around addresses which get deposited into some servers after a fashion.  I guess this is where I'm totally missing the point here perhaps or not understanding what is going on at all with these fees as there is something more implied by this document not written down.

This is exciting stuff. The benefits of having an intrinsic value to bitcoin is inestimable and kills a lot of arguments against it. I would like to hear satoshi's thoughts on this as forking the network is not a decision taken lightly.

Is there a way to reserve the top 1000 domains at Alexa ?  I can see massive issues down the road if say google has their name squatted on. Doing this would bring a lot of goodwill towards bitcoin rather than having all the top companies against it. One way this could be done is for the dev team or a council of bitcoin elders  register all of these names before the client is publicly released and hold them in trust. When a top 1000 company wishes to claim their name the profits could go to benefit bitcoin. Is that a good plan?

No, no, no. The DNS system should be kept as simple as possible.

There will be no silly voting, or court, or any complicating shit.

That is the point.

A handful of servers will be public DNS servers running with "authority" over those BitDNS TLDs that they support. To get in one of these, you'll have to pay them directly in addition to the fees that go to whoever generates the block. This can be done with additional outputs, or you can pay on their site in the traditional Bitcoin way. This is where a registrar is especially useful, since they will know all of the current fee requirements of the various servers, and they can pay them all at once automatically.

People who run their own servers will not get a fee like this, but will rely only on the block fee. Configure your server to require the fee that you think is best, and you will see only those domains that have paid that fee or above.


Exactly.


Bitcoin already supports it technically, though recently a change was made that causes non-standard transactions such as the ones used by BitDNS to be skipped in blocks created by the official Bitcoin client. However, BitDNS transactions produce quite a lot of fees for generators, so if an implementation is created, I expect it will be easy to get a reasonable percentage of miners to ignore this new rule (only like 5% is really necessary).


The left-most part has to stay the same. "theymos.btc" can be changed to "theymos.bc". Everything but the left-most part is advisory: "theymos.btc" can actually appear as "theymos.btcdns". In particular, if someone registers a top-level domain such as "theymos.", most servers will probably map it to "theymos.btc" or something.


Anyone can run them. I think the expiry time should be lowered to like 5,000, though, to make it easier to run a server.

So in theory this is the perfect system for claiming a 'named address'.  If I wanted to send a payment to 'theymos.btcdns' I could. Or is my understanding wrong?

This is all very fascinating stuff.  I read themos+nanotube's proposal, ribuck's proposal, and rhorning's.  While I think I grasp the fundamental differences between them, I am not confident to weigh in.  Could I ask that someone more knowledgeable than I am on these matters create a table (wiki?) that lists the proposals as they currently are?

I'm personally very intrigued by the idea of piggy backing on the existing bitcoin network, if it can be done cleanly and with minimal modification to bitcoin (as per nanotube/themos suggested).

As Kiba pointed out, I am most excited for bitcoin to have it's intrinsic "use-value!"  And it couldn't come at a more needed time what with wikileaks, pirate bay, etc all over the news.

Lastly, and this could be due to my lack of intimate knowledge of DNS, but will this work seamlessly with more secure DNS protocols as well? Also, is this designed to ultimately replace existing registrars or will this always be a "DomainShadow" system that is only used in the event of crisis (like wikileaks attack, etc)?

Overall, great work guys!!! If we can get some pros/cons of each proposal down on paper, I'm prepared to up my bounty considerably and help out where I can (perhaps on forming an official DomainChain/BitDNS foundation?)

DNSSEC will work fine. And if you run your own server, you don't need to trust anyone!

I can't see any of this becoming mainstream any time soon. You have to at least change your nameservers, and to get all of the security benefits you have to run a bunch of extra software all the time.

It should scale well, though, if it did go mainstream.

We need a proof of concept. 

Ha.  Good point.  I was thinking the two could potentially operate under the same umbrella.  We'll see though.

A few more questions about http://privwiki.dreamhosters.com/wiki/Bitcoin_DNS_System_Proposal

It appears this can support several top level domains, such as .anon, .sex, .p2p, or whatever. Other proposals envisioned a single new TLD like .bitdns.

Names can be changed when registered, but only from one TLD to another. You could change pics.sex to pics.p2p. I don't understand the motivation for this. It seems like something that would seldom be useful.

I'm still confused about fees. I was assuming that fees would be paid to the DNS servers, for the service of acting as a gateway from the Bitcoin block chain to the DNS system. I now see another interpretation, where DNS servers don't receive the fees, but they nevertheless demand that transaction fees of a certain minimum level be paid to miners. As long as they see that the domain name was registered with a large enough transaction fee to the miner, they will pass it through to the DNS. Is it possible that this is what was intended?

The proposal seems to envision a relatively small set of DNS servers that would be authorities for these new domain names and be the ones who bring the names from the block chain into DNS. These would be somewhat analogous to registrars today. (I may be misunderstanding this!) Each of these DNS servers publishes a schedule of fees for performing this service. To register a new name... hmm, I am guessing now. Would you contract with one particular DNS server to do something else than host your regular DNS records?

I had thought it would be ok to expect DNS servers to follow the block chain and honor valid domain name transactions without requiring certain minimum fees. Domain names are so valuable (at least at first) that miners already have ample motivation to demand substantial (like $100 = 500 Bitcoins per transaction) fees. Eventually, if the system is successful, virtually all DNS servers would read the block chain.

I've now studied the theymos/nanotube spec in more depth, and my questions and comments are starting to flow.


I really don't get this. What's the point of having a "right-hand-side" if it is advisory? The user doesn't want to have to type theymos.bc into their browser when they're at an internet cafe that uses one DNS, but have to type theymos.btcdns into their browser at home if their ISP uses a different DNS. And if they just type "theymos", what if they are on a LAN that has a node called theymos?

Any default right-hand-side should be explicit in the spec. Also, I don't think something hard-to-pronounce like ".btcdns" is going to work with the public. Can you imagine TV ads saying "go to walmart dot bee tee see dee en ess"?

In the initial phase at least, I suggest that all names registered should be of the form something.domain

I propose ".domain" for this purpose because it's generic and pronounceable. It also somewhat cheekily implies that this is the ultimate all-encompasing domain name registration system.

Three advantages:

• This establishes clear branding.
• It helps to keep the system simple, so that we can easily describe how to get up-and-running with these newfangled names.
• It avoids any clashes with existing domain names.

If people prefer to go for something more ambitious, I suggest that all names registered should be of the form something.tld where .tld can be anything of three or more characters except for existing recognised top level domains. So you could register hamburger.red or silly.fool but not zebra.com

It could set some precedent for protocol change that allow people to shut down certain domains.

I suspect most of the domain names will be grabbed by speculators who will ransom it to large corporations. Search engines would ignore domain names that violate certain standard of a business mark.

Agreed.  I suggested in my previous domain allocation system that the standard ICANN/InterNIC domains and perhaps to be fair some of the domains currently being done with other networks like OpenNIC and the .onion "domain" of the Bittorrent network ought to be held in "reserve" as a part of the internal protocol we are setting up here.  My suggested domain allocation system would have that as an organic part of the system although it would be useful to hold these TLD in escrow for whenever or if ICANN wants to have control of them.

Since to use one of the TLDs with a server you would need to have it assigned to an IP address of some sort, somebody like Google could go aver "google.btc" as a trademark violation by searching for the network which assigned the IP address of the server using that name.  If the domain record points to 127.0.0.1, it really isn't a threat to Google until that address changes anyway.  I agree that this is beyond the scope of this protocol to take care of the Alexa top 1000 names and the only real issue is spoofing existing domain names being used by other DNS registries.

As a side note, during the actual reference implementation of one of these servers it would be nice to throw a bone to OpenNIC and the "dot P2P" guys (presuming they set up their own system) to forward DNS requests that might fall under those respective domain registries.  This is sort of a tip of the hat to say thanks for making sure ICANN doesn't have 100% exclusive control over domain registrations and to support what I think are good projects in their own right even if they aren't a P2P distributed naming system.  That might even get a reciprocal agreement with those alternate domain registries to spread these registrations with the DomainChain registries much further at least initially.

You have forgotten the rule that I asserted earlier in the thread:


Nowhere did I suggest that we should give authority to whoever, or shutting down the DNS system in favor of court/judges/messyhumanjudgement.

You misunderstood me. I didn't suggest anything like voting or whatever.

Time based expiry date rather than block based expiration system. Obviously registrar could remain users to renew as they had done in the earlier system.

I think we should dispense with the complexity associated with paying various servers. We should also dispense with the concept of paying more if we want better visibility for our domain names.

No-one wants a system where some people can reach some.domain and some people can't, depending on which servers are getting their share of the payment. Or a system where a new server can come to prominence and put pressure on people to pay again for the domains they already paid for.

Let's cut it down to the simplest business model that can work.

Suppose there are some generators who will include domain name registrations into blocks that they generate, because they want to earn the transaction fees. Those generators will operate public-facing domain name servers.

Why? They need to do this, to make the domain name service credible so that people will use DomainChain for their domain registrations. For the generators, it's an overhead, but a necessary one. Kind of like how most restaurants provide toilets without charging separately for them.

You could argue that there will also be some operators who would generate, and who would collect the transaction fees for domain name registrations, but who would not operate a server. After all, why incur the overhead if the other generators will operate the servers?

But the market will take care of this. The generators who do operate servers are not going to accept the blocks generated by those who sell domain names without providing domain name servers.

Additionally, a market like this is likely to have two other kinds of players.

There will be a few organizations who are willing to operate a server for free, perhaps for ideological reasons. Those servers will probably be overloaded and slow (like the free Usenet servers), but they act as a backstop which forces the commercial operators to provide something better.

There will also be a few commercial operators who provide enhanced super-fast servers without being generators. They will do this either because they have paying customers who want the best domain name service that is possible, or they will do it for their own business reasons (as Google does with their free-to-access domain name servers).

Here are the advantages of this simpler system:

• For the domain name owner, the registration is convenient, secure, and lasts forever,
• For the internet user, the same set of domains is served to everyone,
• For the generators, it's a worthwhile extra source of income, and
• For the Bitcoin system, it's an easy way to get extra strength into the block chain with minimal extra data

I agree with ribuck that DNS servers don't necessarily need to get paid, to support Bitcoin domains. After all, what is the purpose of a DNS server? It is to lookup domains for its clients, which are users wanting to connect to computers using domain names. If BitDNS becomes popular, DNS servers will want to be able to lookup those domains too. All that is necessary is to track the block chain and maintain indexes and hash tables to record which domains are in effect and their basic DNS data. DNS servers don't have to be Bitcoin miners. The existing motivations for DNS servers to operate and provide lookup serves to their clients will be sufficient to make them track Bitcoin domains.

This is like that, too. In this system, you're always registering a TLD. Even if I register "theymos.btc", I'm actually getting "theymos.". For better usability, though, BitDNS servers will make this a second-level domain by attaching a TLD like .bitdns or .btc to the registered name. The TLD in the registration is a suggestion for this: in this case, I'm suggesting that "theymos." be followed by "btc" (though the server is free to ignore my suggestion).

The idea is to allow maximum market adaptability. Probably all servers will just use ".btc" or whatever, and totally ignore the suggested value. As an example of something servers could do:
- If your suggested domain suffix is com/org/etc., then your domain will actually overrule .com domains of the same domain for those few users who have configured BitDNS to do so.
- Otherwise, ".btc" is used.

It's a bad idea to hardcode any TLD into the spec. What if ICANN allocates .btc?

A later version might also look at the entire name+TLD for uniqueness. It might be possible in that case to switch from old-style names to new-style names with namechange.


Yes. The idea is not to compensate the servers (usually), but to eliminate spam registrations. The BTC is the "proof-of-work".


The servers are analogous to DNS root servers. There may also be registrars, which will interface with several BitDNS servers (as current registrars interface with gtld-servers.net, for example).


Certainly not. You pay and everyone recognizes you at whatever TLDs they have chosen to see BitDNS domains at.


Almost all of the load is carried by the Bitcoin miners, which is why they get most of the money. Some BitDNS servers will provide public lookup services, which demands some payment. I'm thinking that the registrants will pay these to list them, but maybe the people looking up BitDNS domains will pay them instead.


The average Bitcoin transaction size is 216 bytes. Why does anyone care if BitDNS names are worth 3-500 Bitcoin transactions over 10 years? If miners are taking the transactions, then there is no supply problem. If there is a supply problem, then whoever pays more gets space in blocks. This is fair.


Without an expiration, you need to download the entire block chain to get a current DNS database. Domains must expire if you want to allow end-users to run their own server.

It also destroys unique resources. The pricing scheme would have to control the use of these unique resources appropriately, which requires some market mechanism.

Asking as a general question, is the whole concept of throwing the data into transactions a dead issue now?  With the release of Bitcoin v. 3.1.18 Satoshi has essentially thrown down the gauntlet that adding such data to transactions is considered a form of an attack on the network.  Miners who aren't using a codebase derived from the reference implementation still may add blocks to the network involving these "goofy" transaction packets, but by design the reference implementation will not recognize the transactions.  If we work around the IsStandard() algorithm, it is only going to change to stop whatever changes we make.

This is a subtle but interesting issue where essentially the only way we can guarantee that a domain transaction can be put into a block chain is to create a custom miner and compete for blocks to put those transactions into the network.  That makes for some interesting problems in terms of latency for an effort like DomainCoin.

Should we move onto the forked version of Bitcoin to implement this idea again?

How are the miners going to get these transactions?  I don't think the transactions are even being broadcast from one node to the next if they fail to meet the IsStandard() algorithm, but rather they must be put in directly by a miner.  I'll have to dig into the 0.3.18 source code for the details, but the description is just an initial shot across the bow on this concept.  If you have a miner as a peer who ignores this algorithm, they might get put into the block, otherwise you might just be SOL.  From what I understand, if all of your peers are 0.3.18 clients (and presumably later versions too) they won't even forward transactions to other peer nodes that are "corrupted".

It is a subtle change, but it is a big deal.

Others elsewhere or previously have suggested we build a chain dependent on the bitcoin chain. Some way to hash the data against a block.

That way, miners would still be strengthening the bitcoin network.

Nothing. But hopefully servers will ignore tricks like that.


Right. You can send directly to artforz.ath.cx or any of doublec's pool addresses. I will relay non-standard transactions at theymos.ath.cx.

I believe the problem with the generalized BitX is that the more that one adds to the chain, the higher the payload and overhead.

The solution to this is to use the Bitcoin chain, and use transaction fees to add additional content, the market will decide what is worth including in the chain or not, based solely on the cost/benefit of doing so.

EDIT: see http://bitcointalk.org/index.php?topic=1847.0  for info about how the transaction fees will dictate what is included in the chain.

Ok its time to stop talking and do something. Create another genesis block for domaincoins. Bitcoin will be a pure financial vehicle from this point forward. As such it should be as lean as possible.

Problem solved. To provide the initial security to the network it needs a few miners with gpu cards.

Whos in?

I'm not in for a new genesis block. It risks harming Bitcoin. If the alternative block chain is commercially successful, someone will add a currency to the alternate chain and it will overtake Bitcoin.

Anyway, don't think that Satoshi has killed the idea of Domain Names in the block chain. Here's what the latest changes mean:

1. If you register a domain name, you must connect to a miner that supports it (because standard clients won't relay your request). No problem. You will need to be using a modified client anyway (to give you a way to specify the domain name, the IP addresses and the fee) and the client can be designed to connect to known performant miners (which will probably be most of them).

2. The standard Bitcoin clients will accept the blocks generated by the performant miners, but won't see the Domain Name transactions.

So what's the problem? What's not to like?

I say we should continue to develop the ideas, then try them out on the test network.

I was doing some reasearch into alternatives to DNS, and I was reading about how TOR's hidden services assigned .onion address, and I came across the concept of Zooko's Triangle, which argues that names cannot be global, secure, and memorable, all at the same time:



"Domain names, for example, are global and memorable, but as the rapid rise of phishing demonstrates, they are not secure".  Basically, there will always be imposters who try to claim the domain name of your brand or some misspelling.  So I'm almost wondering if the whole concept of domain names is fundamentally flawed to begin with.  And it seems there is always has to be some sort of centralized means of allocating domain names.  We can't even decide what should be the rate-of-issue for new bitDNS domain names, what the starting price should be for transaction/purchase, how many top Alexis domain names (if any) we should reserve, where/how should the domain directory be located/stored. Maybe we need to stop using domain names entirely, and put our focus more on search engines, links, coupled with public-key cryptography to authenticate the genuity of an internet brand/website/address.  I'm looking into some system called Pet Names...and am trying to figure out a nice way they could be used to assign unique, human-readable (memorable), and global names for bitcoin addresses.  I will start another thread for this, and provide a link here...

Anyway, I think NoAgenda is right here that the Bitcoin block chain, from now on, should be a pure financial vehicle, considering that the latest bitcoin version update removes the ability to include extra text in transactions:

of course, I didn't mean I wanted to redesign the whole DNS.  The conclusion of my musing is: maybe there is some way to associate bitcoin addresses with a unique and human readable (memorable) name using a petname system.


I think this is important, and I encourage people to work on this.


Ok, thanks for clarifying.

Our code repository is non-existent and we're still debating the best route for DomainChain/BitDNS.

Kiba, I wrote this response before Satoshi posted above. I'll need some time to understand Satoshi's post.


Don't be anxious. I already said I thought it would take 2 weeks to agree design directions before coding.

There has been excellent development over the past 24 hours. It has become clear that Gavin's changes to handling of non-standard transactions don't rule out domain registration integrated with Bitcoin.

It is also becoming clearer that there is less distance between my DomainChains ideas and the theymos/nanotube design. Their design does not have the tangled ties with domain name server operators, that I previously thought it did.

Hang in there! Two weeks will seem like nothing in the long term outcome.

This sounds very very interesting, something to explore.

Can you elaborate on how would it work in practice?  Separate networks and block chains implies hashing one block header for each network, with different resulting hashes, does it not?

The only thing I can come up with is the completely naive and slightly cache-unfriendly implementation...

while (nonce < 0xffffff)
    nonce++
    for each network
        data_block[nonce_offset] = nonce        // ie. our nonce
        scanhash(data_block)

or

for each network
    while (nonce < 0xffff)
        data_block[nonce_offset]++
        scanhash(data_block)

I could easily update cpuminer to poll multiple RPC endpoints for 'getwork'...

So if its possible to have a separate block chain and share the cpu power it seems like the issue is solved. Dont go pushing non financial transactions into one central block chain but let each application be a separate entity. If there are many different block chains it increases the chance of earning a block doesnt it?

Its a simple elegant solution from satoshi.

The incentive is to get the rewards from the extra side chains also for the same work.

While you are generating bitcoins, why not also get free domain names for the same work?

If you currently generate 50 BTC per week, now you could get 50 BTC and some domain names too.

You have one piece of work.  If you solve it, it will solve a block from both Bitcoin and BitDNS.  In concept, they're tied together by a Merkle Tree.  To hand it in to Bitcoin, you break off the BitDNS branch, and to hand it in to BitDNS, you break off the Bitcoin branch.

In practice, to retrofit it for Bitcoin, the BitDNS side would have to have maybe ~200 extra bytes, but that's not a big deal.  You've been talking about 50 domains per block, which would dwarf that little 200 bytes per block for backward compatibility.  We could potentially schedule a far in future block when Bitcoin would upgrade to a modernised arrangement with the Merkle Tree on top, if we care enough about saving a few bytes.

Note that the chains are below this new Merkle Tree.  That is, each of Bitcoin and BitDNS have their own chain links inside their blocks.  This is inverted from the common timestamp server arrangement, where the chain is on top and then the Merkle Tree, because that creates one common master chain.  This is two timestamp servers not sharing a chain.

I'm still trying to get my head around your idea completely.  The main reason that I liked the idea of including BitDNS into the bitcoin block chain via transaction fees is that it gives BitDNS a very comprehensive economic support using bitcoins, thus increasing the value and usefulness of bitcoins.

I gather from Sotoshi's model, both BitDNS coins and bitcoins are generated by the same block, allowing them both to be traded as a commodity.  The problem I see with that is that domain names have value from their name, registration costs, and bandwidth/computer cost , not scarcity in number.

In nanotube's+theymos's proposal, the real cost making a BitDNS is _automatically_ paid by the transaction fee, their is no need to create a second market.  As many or as little domains names will be included in the chain, and the generators will be compensated in bitcoins for providing that service.

While I like the idea in general, it doesn't really solve the problem in terms of parallel currencies.  I don't think the idea of where the CPU power was going to come from for powering this network was ever an issue.  People who got into mining would go wherever the money was at and find solutions to "earn" whatever coins happen to be around.

I do like the idea of pooling Bitcoin-like block chains in terms of attempting to "earn" hashes, and if there were more ways use CPU power to generate hashes it can only be beneficial to everybody involved.

I still would like to use miners for "authentication" of the DomainCoin registrations in some way and I'm trying to come up with a good system to get that done.  By authentication I'm referring to basic "rules" that can verify that a domain hasn't been claimed, and a "miner" who doesn't follow those rules as accepted by the rest of the network gets that block rejected.  That is happening right now with Bitcion in regards to transactions, but doesn't happen with any other data and won't happen with other data at least as it is presented.

It still gets to the issue I presented earlier on another thread:


This is an intractable problem if you want to include the data itself in an authenticated form in a chain block and have that chain block directly connected to Bitcoin without a parallel currency.  Theymos simply ignores the issue entirely with his protocol.... which is fine as far as that goes but a miner isn't really being paid to process domain registrations and certainly isn't authenticating bad registrations.  The real "work" in terms of a DNS system is to authenticate precisely who "owns" the domain and make sure that somebody else can't claim that domain.  The Theymos/Nanotube protocol forces authentication into a free good, and puts potential attacks on the protocol into the hands of the Bitcoin network... where I don't think it belongs either.

I firmly believe that the data for domains must be in an authenticated system, preferably its own independent chain (perhaps linked to Bitcoin), where all of those serving this data can agree upon the same information and there is no ambiguity about the data.  Previous proposals that shove the data into the transactions of Bitcoins fail to get that accomplished.

[edit: nevermind this post. I haven't been able to express my idea clearly here.]

Suppose you have a separate block chain for domain name registrations, and you want people to pay in Bitcoins.

To register foo.domain, the buyer pays 10 BTC using the standard Bitcoin system, then goes to the other system to claim their domain name. But how to know that they paid? They can prove cryptographically that the 10 BTC payment came from them, but they can't prove that the payment was for a domain name. They might be using that same payment to claim services from several separate sites.

So obviously Bitcoin needs a way to associate a transaction ID with a Bitcoin payment. If you can include a transaction ID (of say 64 characters), then you may as well just use the Domain Name details as the transaction ID (because it's short enough), in which case there's no need for a separate domain name registration chain.

A domain registration is just a Bitcoin Payment to an unspecified miner, with a transaction ID that happens to be meaningful.

The thing is that the miner receiving the transaction fee is just getting that as a sort of free lunch.  The fee may be in place to cut out spammers, but they aren't doing any work so far as anything to do with the DNS system.  Those computers which are processing and authenticating the raw data are not getting any sort of fee at all and the generators are not being compensated in Bitcions.  All that is happening is that the miners are getting paid essentially as a data storage service entirely, and that is of marginal utility in my opinion.

This is also why there are some huge complaints about using the Bitcion blockchain as a generic data storage system... rightfully so I might add.


Let's assume for a minute we have another block chain which contains just domain data which is cryptographically hashed, but may or may not have proof of work (let's ignore that for now, which I'll address below).  The purpose of the block chain is for the authentication of the data primarily where the "network" of domain servers can "certify" that the data fits the network rules and that domain data within that chain is valid in terms of who "owns" what domain.  As a public block chain, it also shows what the majority of the "network" agrees ought to be in that chain too.  Improperly formatted data that is not agreed to by the majority of the network is rejected from this block.  Since it is a chain it also verifies against tampering and does a timestamp, and more importantly by being outside of the main Bitcoin chain it reduces the data payload for what is admittedly a specialized service which not all Bitcion users are necessarily interested in.  These are the features of the Bitcoin transaction database that are being desired to be applied to other sets of data.

So far that is the easy stuff.  We also want to set up some system where the "registrar" putting data into this chain is going to be "paid" for the registration and authentication of this system.  I emphasize this as this is both going to be a reason to be a registrar as to even exist as a registrar has a strong financial stake in maintaining the database to receive more registrations, and provides a reason to have fees to cut down on spamming domain names or abusing the public commons.  The fees are being paid to maintain the database, which is the important thing here.  Without this fee, at best this database is being authenticated and supplied to the world at large strictly as a public service for free.  Some people like that but I hope that those involved with the Bitcoin project can appreciate how being paid for such a service can be very useful and motivating.  The Theymos/Nanotube proposal and for that matter all registrations into the Bitcoin database through extra data in a transaction sidestep this issue entirely by ignoring authentication and only using the timestamp ability of Bitcoin, where this database would have to be built anyway but derived from Bitcoin and thus provided as a public service for free.

Here is the real issue, however:  Since there is no central server, the registrant wants to make sure their registration is put in by whatever registrar happens to be in line to put in the next record onto the block chain, however that is decided (by proof of work or some other agreed upon system).  They want to send out some sort of generic transaction that can be received by the "authenticator" of their registration application who puts this registration into that block chain.  Only if their registration is accepted into the block chain should that authenticator be paid.

A problem arises here:  A bitcoin miner may know that a fee is available from a registrant, but how do you decide where those coins properly belong?  Keep in mind that once a fee is processed in Bitcoin, it is irreversible.  If there is a chain split on the domain records due to a formatting/authentication dispute (it likely will happen just like it is happening with Bitcoin even now) those Bitcoin transactions may be going to an authenticator who in fact never did get the registration done because the majority of the network has ignored that domain registration block.  Some other registrar may pick up the registration and simply out of the kindness of their heart decide to include it in another block, but they won't be receiving any fee at all for that service.  Some system could be perhaps set up where after a block is down to a given depth in the block chain that the fee can be "released".  Still, regardless of how you set this up there will be some trolls who will be collecting fees, pretending to put stuff into the domain registry but not really caring about the domain registry protocols and siphoning off the fees for themselves, perhaps in collaboration with a Bitcoin miner.  Since this represents serious money, there will always be some trolls doing this.  Even an "honest" registrar is still going to make some mistakes due to a bug or something similar which may on occasion capture fees when they are deserved under this system.

I believe the fee system is critical to the success of this domain registration system.  That ensures selfish behavior on the part of the registrars which puts it into their self-interest to maintain the databases, computer equipment, and everything else which makes this work.  Yes, there are other ways that a domain name server can earn some coins, and perhaps that ought to be done too, but registration fees are already a part of the marketplace and something which this system is trying to capture as well.

In short, I am trying to demonstrate here that the authentication simply must happen with an entirely different currency, or that authentication of the data (not merely the time stamping) must happen within the Bitcoin client and that data at least in some fashion or another included more directly into the Bitcion block chain with the data authenticated by the miner itself.  A Bitcoin miner may choose not to process domain data, but some system must be set up that can certify that a given block including the domain data meets some sort of authentication standard to be accepted into the block chain to "earn" those registration fees.  Otherwise the system falls apart and any talk of fees other than as a pure transaction fee to a Bitcoin miner alone is meaningless, with that transaction only to be used to preserve the transaction database.

I am also suggesting that to ensure promptness of registration, that it may also have to be a separate currency simply because not all miners are going to want to bother with domain registration authentication and over time the latency of even getting a domain registration into the system may be intolerably long (on the order of days or weeks) depending on the setup of the Bitcoin network and other priorities of the miners.  I'm not suggesting an alternate currency to drive this project out of Bitcoin as useless data, but to point out that it is unworkable even from the perspective of the goals of the peer to peer domain server concept too.  Putting the data into transactions isn't authentication and is also losing much of the power of what Bitcoin offers in terms of the authentication too.  The proof of work system as used by Bitcion is also the only reasonable way to ensure that the system stays decentralized in terms of deciding who gets to put in the next block.  Certainly some sort of common protocol for finding the next proof of work hash can be set up through a common mining pool between multiple currencies like this, but that is a completely separate issue from if it is to be a separate currency or not which I don't think has been decided on this thread.

The only other solution would be for Bitcoin to fully embrace this and other similar concepts that might come along and provide hooks and some sort of standard protocol to authenticate data of this nature on the main Bitcoin network.  I think in theory that could be done and may be done in the more distant future in terms of "unifying" the proliferation of currencies that may result if it isn't done.  I just don't see how that is going to get into the main Bitcoin chain anytime soon and even that has a whole bunch of drawbacks which I haven't fully explored either.

2. "powerdns" can work with plugins and with bind9 configs by default. We can write a plugin for it.

No-one has made a proof-of-concept, but we think that all we need is a program that trawls through the block chain, extracts the registration details, and writes them out in bind's data format. No plugin or hacks should be needed.

bind9 is not the best format. pdns have a simple interface for plugins, do not worry.

Got you now. Yes, keeping two chains synchronised is fraught with difficulty.

If you say "no" after you've seen how this runs on the test network, I will totally respect that and won't generate domain registrations on the live network.

Bitcoin is your bird, and if you don't want it to soar as high as it can, that's OK.

But even if the domain name stuff is on a separate chain, there is still going to be a Bitcoin transaction for every DNS registration. So having two chains would cause no reduction in the number of Bitcoin transactions, just 40 or 50 bytes reduction in the size of the transactions in the Bitcoin chain.

Also, why on Earth would a BitDNS want a blockchain that updates every 10 minutes?  Why not an hour instead?  Or every minute?  Why be chained to the cycles set for another purpose?  It's less than ideal from the beginning.

This is indeed something that can be tweaked, but the issue has to do with network latency, which is independent of the purpose for which the "currency" was created.  10 minutes is a guess that has worked out pretty well.  Yes, it could be longer or shorter.  Shorter intervals increase hash collisions from multiple "miners" and a longer intervals decrease those collisions.  10 minutes is also something tolerable on average to somebody used to using computers, certainly if you have experienced sending information and expecting a reply by e-mail.  Domain registrations in particular may take a day or so for processing, depending on the registrar and the method of payment, so anything less than a 10 minute interval seems like a waste of effort.

In short, the reasons why 10 minute intervals would apply to Bitcoin apply equally well to any other peer-to-peer cryptocurrency with what other applications are using similar principles.

If you are a miner and you "win" the block, yes, you can throw in any domains to the chain for free I suppose, and the network could accept or reject your block depending on whatever rules that network sets up to regulate that behavior.  That is like a Bitcoin miner can throw any transactions they care for as much as they care without having to pay a transaction fee, since they are paying for themselves.  Including a transaction fee in the process is just rearranging coins and doesn't change the net amount actually being spent or received.

I think that is of limited utility, unless you are saying that miners can eventually "earn" the "right" to a top-level domain after a certain number of hashes and inclusions into the domain registry.  That would be an artificial form of scarcity that would be interesting to implement, but it still fails to get fees paid by registrants to the registrar.  It would just make you "god-king" over a particular TLD... if you really "owned" that.

Such a non-coin "reward" also doesn't provide any incentive to maintain the database, while a coin-based reward would.

Right, the exchange rate between domains and bitcoins would float.

A longer interval than 10 minutes would be appropriate for BitDNS.

So far in this discussion there's already a lot of housekeeping data required.  It will be much easier if you can freely use all the space you need without worrying about paying fees for expensive space in Bitcoin's chain.  Some transactions:

Changing the IP record.

Name change.  A domain object could entitle you to one domain, and you could change it at will to any name that isn't taken.  This would encourage users to free up names they don't want anymore.  Generated domains start out blank and the miner sells it to someone who changes it to what they want.  

Renewal.  Could be free, or maybe require consuming another domain object to renew.  In that case, domain objects (domaincoins?) could represent the right to own a domain for a year.  The spent fee goes to the miners in the next block fee.

OK so if there are going to be bitdnscoins (aka DCCs, DomainChain Coins) then they have to be useful for something. Otherwise every BitDNS miner is going to fill every block with his own domain name registrations, rather than replace one with someone else's registration in exchange for a transaction fee in a useless currency.

The rules have to be that you have to spend a certain amount of bitdnscoins/DCCs in order to register your names and/or do other BitDNS transactions. That's the only way to make this alternative currency desirable and valuable.

(Well we could do like Bitcoin and say there would only ever be 22 million DCCs ever created, so they'd get valuable from scarcity just like bitcoins. But that seems weak.)

Then be sure to add the ability to specify multiple authoritative servers for one domain. This is possible for DNS as I know (MS Windows AD does it)

So those who do not want what their site to be able to shutdown can make a lot of spare servers and when they turned off by Big Brother name owner just change the settings by removing old servers and adding new ones.

After reading through this whole thread, I've got a couple of comments that I think would be helpful:

1)  Everyone in the thread seems intent on replacing the entire DNS infrastructure in one fell swoop, which I think is the wrong approach.  The real problem with the DNS system as it exists today is that somebody has to own the root.  At the end of the day, you have to trust ICANN.  What the DomainChain/BitDNS system should strictly focus on is establishing ownership of domain names.  All it needs to track is that the holder of Key A owns domain foo.bar.  Once we've established this shared trust, we can support many different DNS infrastructures that can be implemented independently from this project.  Whatever new systems are created use DomainChain/BitDNS to establish which key owns the domain, and only allows that individual to insert records for that domain.  This works out well, since all participants in the system can validate that the record they've looked up is valid.  Right now it is easy to get bogged down in all the details of managing DNS records, when all we need to do is establish a trusted, distributed authority that can form the root of DNSSEC, some new p2p DNS, or whatever.

I'm also thinking this could be used to solve the CA problem with HTTPS, since signing your certificate with the same key would prove that I've reached the correct server.  But I digress...

2)  Limiting the TLDs should be a requirement.  If this system doesn't inter-operate with the existing DNS infrastructure by preventing name collisions, it will undermine the trust you are trying to generate.  Even I'm not sure I'm ready to sign up for a distributed DNS system if someone new can pick up www.mylocalbank.com and cause havok.  I'd humbly suggest .web as the TLD to use, but anything will work as long as it is short and not currently in use.

Right now the focus should be on getting this up and running in a way that doesn't conflict with the existing system.  If this system becomes dominant at some point and needs to tackle additional TLDs, that is a "problem" that can be dealt with then.

3)  Personally, I think expiring domain names are the way to go.  Even with relatively expensive renewals today, there is still a ton of junk out there.  I can't imagine how bad it would be if you owned a domain forever.  It isn't asking much to say that you have to renew your domain periodically to keep it, especially since this shouldn't be the ripoff that the existing system is today.

I'd like to close out by saying that this is really exciting stuff.  I've read a number of different ideas about how to solve the DNS problem, and this is the first one I've seen that could actually solve it (and not just replace ICANN with pick-your-new-benevolent-dictator).

It's here. The simpler DomainChain proposal is here.

@dtvan: all 3 excellent points.
1) IP records don't need to be in the chain, just do registrar function not DNS.  And CA problem solved, neat.
2) Pick one TLD, .web +1.
3) Expiration and significant renewal costs, very important.

Avoiding CPU power fragmentation is no longer a reason.  Independent networks/chains can share CPU power without sharing much else.  See: http://bitcointalk.org/index.php?topic=1790.msg28696#msg28696 and http://bitcointalk.org/index.php?topic=1790.msg28715#msg28715