What is Bitcoin? A decentralized way to keep track of ownership of a fixed quantity of things.

The DNS problem is a specific example of a more general functionality: keeping track of ownership of a fixed quantity of things, where each member of the set is distinguishable.

It turns out that bitcoins are already distinguishable. They are well ordered, mathematically speaking, so a number can be assigned to every bitcoin, for example 0 to 21 million.

So, for a DNS functionality, this is all we need to do:
1. create a second coinbase, possibly forked from the main coinbase (bitcoin)
2. interpret each coin in the second coinbase as a well-defined interval of the sha256 hash space of all DNS names.

Ownership of DNS names is therefore determined by which coins in the second coinbase you own.

Some months ago I was opposed to adding DNS stuff to the existing bitcoin network protocol and client, because I argued bitcoin should stay true to its limited purpose. However, thinking more about this now I support inclusion of additional coinbases tracking systems in the main network. The reason for doing this is so as not to water down CPU power into multiple networks. We want one strong network, so the network should be versatile.

In fact, maybe anyone should be able to create a new coinbase on the main network, and specify rules such as quantity and distribution rate. In the case of DNS, everyone will just have to agree that a particular coinbase is to be interpreted as the DNS rights to different parts of the sha256 hash space for the DNS names.

I agree with the idea put forth by da2ce7, which he says is derived from an idea put forth by Satoshi. I think it is compatible with my idea of allowing arbitrary creation of new coinbases on the same network.

I cannot find the nanotube+theymos proposal so i cannot comment on it.

This seems like a sound plan. It includes the proposal of theymos and nanotube and includes what satoshi is wanting. I like the fact that there is no free lunch and everyone would have to pay their way.

While I like this general architecture, the largest problem is how you set up the schema for authentication of the non-financial transaction data.  A node could deliberately ignore such data, but if a node is going to carry some data not directly related to financial transactions it should follow some sort of authentication rules for that data.  The question is mainly how that is going to be performed.

Keep in mind one of the things that made the update with Bitcoin v. 0.3.18 sort of earth-moving is that the authentication rules for the network changed.  Many have assumed that the miners control the rules of what goes into a block chain but that is only partially true.  The nodes themselves also have a huge rule with that too, where even a non-generating node "participates" in the network deciding which node is going to be accepted by its corner of the network, and acting as gatekeepers over what data is passed along to miners.

There are three things that are gained from using a bitcoin architechture that must all be necessary for the data to be effectively using the Bitcoin architecture to its largest extent:

• Time stamping - certifying the temporal order of events
• Cryptographic Integrity - certifying that the data hasn't been tampered with
• Authentication - certifying that the data meets some basic standards

Any sort of general or specific proposal for something like BitDNS really must include all three aspects.  Most of the proposals I've seen ignore the authentication or dismiss it as something irrelevant.

The authentication rules are indeed different for domain names than currency, but the principles are similar.  With currency you don't want to have people "double spend" coins or creating coins "out of thin air" except under strongly proscribed rules.  In the case of domain names, you want to ensure that the same domain hasn't been "claimed" by more than one person.  Furthermore, you also want to make sure that if "ownership" of a domain has been transferred (thus giving authority to change properties associated with that domain), that such a transition is orderly.  Also, any properties associated with that domain such as IP addresses related to the domain or contact information can only be modified by the person who either created or has "ownership" of that domain.  If there are expiration rules, those rules ought to be enforced and managed as well.

All of that is fairly easy to do in a monolithic central server, but it gets much more complicated when trying to do this on a peer to peer network.  If the authentication doesn't happen with some standard rules, you end up with chaos as different "domain servers" all end up pointing to different computers.  Even for computers trying to follow "the rules", without authentication being guaranteed with inclusion into a database of some sort they may still end up displaying the "wrong" information compared to a peer.  For domain registration, that is to me something fatal.  That is why I think pushing the domain authentication down to individual servers to decide for themselves as an optional thing and not integral to the network is a bad move.

Furthermore, I am trying to suggest that the role which "registration fees" can play will both strengthen the network and to improve authentication shouldn't be underestimated.  This isn't just the transaction recording fee, but also the authentication that the data really belongs in the chain too.  The fees also help out on the problem of a tragedy of the commons, as it provides an additional incentive to not "spam" registrations, but that the resources or in this case a "domain" is really something needed.  Cybersquatting is reduced simply because it can be expensive to engage in hundreds or thousands of registrations.  

A miner is double-checking to make sure that the data really does belong in the chain.  If a miner is being sloppy and doesn't do the authentication, or at the least is in error because of a bug in the software, the block containing the "bad" data should be rejected by the network.  Again, this is happening with financial transactions, and I'm saying that it should be happening with other data too.  A miner not doing proper authentication shouldn't receive authentication fees.  

This is one of the reasons why I have suggested that this data be done in a completely separate block chain and currency system, as that way the authentication is done by miners with a self-interest to make sure that the authentication takes place.  A network dedicated to a particular kind of data would also root out people trying to abuse that data format.  Setting up currency exchanges is something that is already a well established principle with Bitcoins, and there is no reason to presume that it can't be used for other "parallel" currencies made for more dedicated purposes, particularly if they are allowed to float.  Apparently this concept of a separate currency is being rejected so let's explore including this into Bitcoin for a moment.

If this is included into Bitcoin, both interested miners and network nodes wanting to perform authentication checks on a particular set of data should have some way to get the rules for that data.  So far the presumption is that the rules should be "hard coded" into the software itself.  Perhaps that could change too in some way.  What would the consequences of having some sort of "scripting language" that could be used for authentication of data that could be injected into the network?  I'm proposing this as a way to make Bitcoin extensible too so other forms of data could be applied to the network.  How a node obtains these scripts can be debated, as that may be something a node or miner can obtain from Source Forge, Git, or perhaps some protocol could be set up for spreading these scripts through the network itself.  It wouldn't need to be an ongoing issue as there only needs to be one script per data type, but the role of the script would be to ensure the authenticity of the data.

If a miner doesn't want to bother with authenticating some data, they simply don't have to include that data at all in a block.  That miner would also be giving up authentication and transaction fees associated with that data, so it seems rather unlikely any miner would ignore that kind of data, but it still is completely optional.  The data can be authenticated, and on the positive side the network isn't just restricted to a very limited number of data types too.  I am doing some handwaving here as I'm not specifying the scripting language, but I think that can be developed.

The one weakness I see here with this alternate system of actually including non-financial data into the Bitcoin Merkle tree is that for non-financial data the authentication is going to be weaker when used in a general network.  Far too many nodes are not going to be interested in authenticating the non-financial data or even passing it along.  Then again, that might be a reason to accept fees or set up a system to charge for network bandwidth between nodes.  Data storage and network bandwidth don't have to be free goods either.

besides the possibility of storing NS records in addition to just registrations... the theymos+nanotube spec does exactly what you suggest.

I know I'm starting to sound like a broken record here, but the time stamping isn't the only issue here.  Fees are being proposed for inclusion with the "registrations", but I see absolutely no financial incentive to even recognize those transactions at all with the Theymos/Nanotube proposal.  These fees aren't going to registrars or anybody associated with the domain data control.  There is also absolutely no standard to establish which domain actually belongs to which set of IP address, much less any sort of other kind of authentication standard with this proposal.  It does include a hook to make sure that the data isn't tampered with, but that isn't the same thing.  Authentication is presumed and mentioned as coming from the Bitcoin block chain, but it isn't happening.

I am strongly suggesting that the economic principles for sustaining this network with this proposal are not present in the proposal.

I guess it will take seeing how it really works out, but I see so many potential "attacks" if this is implemented that I don't see it being sustainable.

This in turn leads to multiple assumptions as to which domain is junk.  If one client recognized a 10BTC "fee" as proper for registration (going back to the Theymos/Nanotube proposal) but another expects a 20 BTC "fee", where somebody else made a registration for 20 BTC, that is the domain registration that will be recognized.... with a completely different IP address that it is pointing to.  If another "registrar" recognizes a 5 BTC "fee", it could be still another IP address.  In other words, the whole concept of a fee here needs to be rethought too if that has any meaning at all.  Even if the role of the "fee" is simply to get miners to include the regsitration into the block, there are other problems to worry about too.

This goes back to authentication that isn't happening, at least to give a "definitive" version of what is in fact the correct IP address or any other meaning to the domain name.  Even slight differences in interpretation of the formatting of the data can lead to some "registrations" being recognized and others being ignored.  I see chaos particularly as multiple implementations of clients try to interpret this data in various ways each with their own assumptions as to which "registration" is definitive.  There is also no means to enforce that a particular piece of software is necessarily going to be the definitive and "authorized" software for this application.

With such chaos in terms of trying to determine the validity and authentication of a domain, I fail to see how it would actually be accepted as a directory of IP addresses, which really is the purpose of a domain registry when you get down to the whole issue on a basic level.

I guess he is hinting at the very chaotic planning of .p2p which makes the developement really slow because they can't really start before the specifications are clear.
Ignore that post. I was looking on the wrong page.

Do we have enough uncontroversial detail that somebody can start coding?

Seems like everyone's tugging in a different direction. Here are some of the specific issues:

1. Bitcoin main chain vs start a new chain, with DCCs ("DomainChain coins").

2. Permanent name registration vs renewal necessary.

3. Support for an unlimited family of applications vs just focus on DNS.

4. DNS "gateway" servers setting minimum transaction fees vs burning a DCC to register a domain.

5. Include in the block chain, in addition to domain name: just ownership public key, vs ownership public key plus authoritative DNS server IP addresses, vs arbitrary DNS records.

6. Single TLD .web or .p2p, etc., vs "advisory" TLDs which may be ignored, versus all TLDs being allowed in names.

Any other issues/design choices which can be factored out?

If it were truly democratic, there would be a choice of, "don't do anything like this at all" and would require a quorum of 50% or more of bitcoin users.