BitDNS and Generalizing Bitcoin

[dtvan]

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

[joe]

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.

[ribuck]

I cannot find the nanotube+theymos proposal

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

[Anonymous]

It seems like killing two birds...

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.

[satoshi]

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

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.

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

[RHorning]

I propose, a design hinted at by Satoshi, to solve this problem:  Split bitcoin transactions into multiple groups.
While keeping the important tie between data and bitcoin transactions, (every bit of data still must include it’s compensation to the miners as a bitcoin transaction fee).
Group the transactions by templates.  For example:  Put the ‘vanilla template’ bitcoin transactions into the vanilla group, the ‘bitdns template’ bitcoin transactions into the bitdns group, the ‘bitpgp template’ bitcoin transactions into the bitpgp group, and so on.

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.

[RHorning]

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. 

There is no need to trust ICANN, except for perhaps acknowledging that there are other systems for domain allocation that aren't going to go away and that other people will be interested in using.  I don't see any sort of DNS replacement system suggesting that the ICANN domains should be ignored, merely that they ought to be depreciated with new systems.  The history of ICANN is one of a small group of self-appointed individuals trying to gain control over the resources of the internet for their own personal financial gain.  It also concentrates this authority in such a way that allows governments to exert political influence upon the allocation of domain names for political purposes that have nothing to do with the technical operations of the internet.  One of the points of setting up a peer-to-peer domain allocation system is precisely to get away from this central authority.

There is a sort of libertarian/anarchist bent to the whole notion of creating an alternate DNS system, which is one of the motivations for why this is being set up in the way being described.  Otherwise, I guess you can accept the system as promoted by ICANN.

2)  Limiting the TLDs should be a requirement.

I quoted Karl Auerbach, a former director of ICANN and a leading computer & software engineer involved in domain registration, who pointed out that there is no need for a monolithic TLD structure.  I challenge this notion entirely as something which is outdated, but that is a debate that can be left to another day.  For me, restricting this to a single TLD or a small group of TLDs is not even necessary and I think anybody registering domains on this system should also be given the option to create some arbitrary TLDs at will too.  The DNS system does not require TLDs to function, and in particular a system with a peer-to-peer domain registration certainly doesn't need TLDs either.

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 happen to agree here that domains should expire.  Various proposals have also debated the term lengths, but charging fees to maintain those domains also has a side benefit of also helping out the network in terms of paying for data storage costs and network bandwidth to support the registration system.  That is also true for the ICANN system of domain registration too.

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

That is the feature I love about this system too, as it does put the "ownership" of domain registration to a network as a whole instead of a single person.  It also lowers or practically eliminates the barriers to entry for becoming a domain registrar.  Wouldn't it be nice if you could be like "GoDaddy" and start accepting fees for domain registration?

[nanotube]

<some stuff>

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

[em3rgentOrdr]

It seems like killing two birds...

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.

I second da2ce7's suggestion as well.  Makes it more flexible.  It is similiar to the last suggestion in theymous's http://privwiki.dreamhosters.com/wiki/Bitcoin_DNS_System_Proposal#Overcoming_potential_resistance_bitcoin_developers.2Fcommunity here:

Thirdly, we could push off the data handling bits to the root dns servers themselves. The only features we /really/ need from the bitcoin block chain is a timestamped proof that you spent X btc by way of a transaction fee. The rest can be accomplished on the dns server, wherein the user creates an account on a root dns server of his choice, submits a message signed with the ECDSA key of the recipient address, and claims a domain name of his choice. The root server publishes the relevant DNS record, including a TXT record with the details of the transaction that is being claimed. This allows a person to claim one and only one domain, based on the timestamp and fee paid with the transaction to the address in question. In this latter mechanism, we have left only the bare essentials in the block chain - the transactions required are absolutely normal bitcoin transactions, unblockable by the developers.

Separating the data part of the DNS transactions from the p2p distributed timestamping part means that we all don't have to be carrying around all this DNS transaction queries in our block chain, and it means that DNS transactions aren't limited to 120 bytes.  Theremous, could you elaborate a bit more on how this above suggestion would work?

2)  Limiting the TLDs should be a requirement.

I quoted Karl Auerbach, a former director of ICANN and a leading computer & software engineer involved in domain registration, who pointed out that there is no need for a monolithic TLD structure.  I challenge this notion entirely as something which is outdated, but that is a debate that can be left to another day.  For me, restricting this to a single TLD or a small group of TLDs is not even necessary and I think anybody registering domains on this system should also be given the option to create some arbitrary TLDs at will too.  The DNS system does not require TLDs to function, and in particular a system with a peer-to-peer domain registration certainly doesn't need TLDs either.

I second this.  Limiteing TLD is totally arbitrary.  Major internet entites like Wikipedia or Google or YouTube or Facebook or blogspot should be free to compete for and obtain a TLD with their name.

[RHorning]

Thirdly, we could push off the data handling bits to the root dns servers themselves. The only features we /really/ need from the bitcoin block chain is a timestamped proof that you spent X btc by way of a transaction fee. The rest can be accomplished on the dns server, wherein the user creates an account on a root dns server of his choice, submits a message signed with the ECDSA key of the recipient address, and claims a domain name of his choice. The root server publishes the relevant DNS record, including a TXT record with the details of the transaction that is being claimed. This allows a person to claim one and only one domain, based on the timestamp and fee paid with the transaction to the address in question. In this latter mechanism, we have left only the bare essentials in the block chain - the transactions required are absolutely normal bitcoin transactions, unblockable by the developers.

Separating the data part of the DNS transactions from the p2p distributed timestamping part means that we all don't have to be carrying around all this DNS transaction queries in our block chain, and it means that DNS transactions aren't limited to 120 bytes.  Theremous, could you elaborate a bit more on how this above suggestion would work?

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.

[da2ce7]

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.

Yes, this is what I was implying by having 'templates' for the data.  To be accepted into the BitDNS 'group' one must follow the BitDNS template, otherwise the block that is created is orphaned.

The rules of the 'template' is whatever a majority of the network decides to requite; for instance, it could include a rule that the same domain name cannot be registered more than one. Or not.  But this is a longer term thing.

It is important to note, that when somebody claims a BitDNS address, then another claims the same address, it doesn't need to be network enforced, as those using the BitDNS information will just ignore the later claim as junk.

[RHorning]

It is important to note, that when somebody claims a BitDNS address, then another claims the same address, it doesn't need to be network enforced, as those using the BitDNS information will just ignore the later claim as junk.

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.

[kiba]

Are we...dead?

[SmokeTooMuch]

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.

[nanotube]

Are we...dead?

no.

[kiba]

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

[RHorning]

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

There are some very different philosophies here, so I think we may have a couple of different applications being developed, perhaps jointly.  I'm certainly not going to be implementing the Theymos/Nanotube proposal at least initially, but somebody else might.

[Hal]

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?

[SmokeTooMuch]

Maybe we should start a poll about what we think is best and accept the result as a democratic decision.

For me it looks like this was the best:

[ ] Bitcoin main chain
[X] start a new chain, with DCCs ("DomainChain coins").

[ ] Permanent name registration
[X] renewal necessary
(registration for 1 year ?)

[ ] Support for an unlimited family of applications
[X] just focus on DNS.

[ ] DNS "gateway" servers setting minimum transaction fees
[X] burning a DCC to register a domain.
(not sure if I got all the details about this)

[ ] Include in the block chain, in addition to domain name: just ownership public key,
[ ] ownership public key plus authoritative DNS server IP addresses, vs arbitrary DNS records.
(actually I don't care about this)

[ ] Single TLD .web or .p2p, etc.
[ ] "advisory" TLDs which may be ignored
[X] all TLDs being allowed in names.
(up to 4 or 5 Unicode letters)

[MoonShadow]

Maybe we should start a poll about what we think is best and accept the result as a democratic decision.

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.