BitDNS and Generalizing Bitcoin

[kiba]

Before we go too far down the track, can we agree on a project name? I'm uneasy about BitDNS, because we aren't writing a Domain Name Server. How about BitDomains, or DomainChain?

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

[1713485063]

1713485063

[1713485063]

1713485063

[RHorning]

I am making it my project to write a BitDNS client.

Before we go too far down the track, can we agree on a project name? I'm uneasy about BitDNS, because we aren't writing a Domain Name Server. How about BitDomains, or DomainChain?

In a way, we are writing a Domain Name Server.  The hope here is that eventually the data we throw into this database is going to be extracted and used with the current DNS architecture as used on the internet, where computers would have the DNS resolution pointing to this database as a "fall back" position if it can't be resolved through the regular DNS channels.  That is how OpenDNS is currently working right now.

The only differences here is that we aren't relying upon a central server to act as a gatekeeper of this information, and it would be something that you could simply put into the search path through the network configurations of your own.

Getting the DNS protocol hooks working is to me a much more trivial thing than getting the domain registration itself going, however.  Once you can demonstrate that the domain registration is working and that the domain name can be resolved cleanly, getting the DNS portion working is simply plugging through the RFC protocol documents to make sure you get that side working.  The revolutionary thing isn't the DNS server software (which can already be downloaded for free as in beer and speech) but rather the decentralized database keeping track of this stuff and securing the data from getting tampered with.

[ribuck]

The revolutionary thing is ... the decentralized database keeping track of this stuff and securing the data from getting tampered with.

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.

[kiba]

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.

What software are you using for the site?

[chaord]

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

[kiba]

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

Bleg. All I need to do is change the name.

In any case, do ribuck and RHorning have any inkling on what you guys agree on and how to implement the protocol? The faster some things that are agreed on, the more code we can do.

[RHorning]

+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"?  

[kiba]

I have no complaint.

[ribuck]

I would like to propose the following specification for actual name of the domain itself...

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.

Some possible domain names would be "excluded" from this schema and held in common such as excluding domains named "com", "net", "edu"

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?

"Sub-domains" can also be established using a "dot" structure off of a previously established domain name

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.

[bencoder]

I like DomainChain as well.

I would also argue against any particularly special attachment to bitcoins, what would the purpose of that be except to hopefully promote bitcoin? I prefer to allow it to be a separate market in it's own right. With people able to pay for domains from those who've managed to generate them using whatever payment method they want to agree on.

Do we have a wiki yet?

[kiba]

I like DomainChain as well.

I would also argue against any particularly special attachment to bitcoins, what would the purpose of that be except to hopefully promote bitcoin? I prefer to allow it to be a separate market in it's own right. With people able to pay for domains from those who've managed to generate them using whatever payment method they want to agree on.

Do we have a wiki yet?

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.

[RHorning]

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

Bleg. All I need to do is change the name.

In any case, do ribuck and RHorning have any inkling on what you guys agree on and how to implement the protocol? The faster some things that are agreed on, the more code we can do.

The only thing I am banging my head against right now is the issue of how to get the block miners of the DNS blocks to get the transaction fees.  I don't know if that is going to require a change in the Bitcoin protocol or if it can be adapted into the existing protocol.  This idea shows some promise as one way to implement the idea, however I really don't like putting this data into the main Bitcoin transaction database and turning that into one huge monster generic database of home cooking recipes, porn, mp3s, Wikileaks documents, Heroin traffic routing instructions, and other miscellaneous junk.  If you thought Bitcoins faced problems before in terms of governments wanting to shut it down because it is a competing currency, I think that puts it completely over the top without any of the protections that Freenet has put into the message routing protocol.

Where I'm having the problem is mainly that I don't think a "DomainChain" miner should get paid until the block they made is accepted deep into the chain, like at least 10 or so blocks deep (perhaps adjustable on that length with some formula too?)  For the most part I don't think most miners are going to care as long as they eventually get paid for the work they did, but those who are attacking the network may want to suck up the bitcoins for themselves and not really doing any work in terms of generating the blocks necessary to keep this whole thing going.

By banging my head on this problem, I really mean that every possible option I've considered has a fatal flaw in it.  I think the registration fees are an important part of this whole concept, however, as it makes the difference between a public commons free good and something where the consumer "pays the freight" for the network.  I also think it will make the difference between limited vs. widespread acceptance of this system too.

If you want me to go over some of the ideas I've had, I'll gladly put those dead ends into another thread, as I've come up with at least a dozen different ways to solve this problem in detail... including ideas I even started to type up in various replies to posts on this forum and then simply hit the "x" on the tab in Firefox before I hit the post button because I realized it wouldn't work.  Even the method of putting the data into the Bitcion transactions has a fatal flaw so far as it turns the BTC miners into DNS miners too (they keep the fees for themselves) and it enables some different kind of attacks on the DNS network as well.  I hate to say it though, it may very well be the best route to take shy of some protocol extension to Bitcoin itself that would recognize independent data chains as a source of transactions.

[RHorning]

I would like to propose the following specification for actual name of the domain itself...

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.

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.

Some possible domain names would be "excluded" from this schema and held in common such as excluding domains named "com", "net", "edu"

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?

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.

"Sub-domains" can also be established using a "dot" structure off of a previously established domain name

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.

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.

[chaord]

I don't know how to do this on IRC, but can someone create a #bitcoin-domainchain chatroom or something so that we can get some real time discussion going?

[Hal]

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.

[em3rgentOrdr]

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.

That sounds nice.  However, I was always uncomfortable with how block miners get 50 coins, and slowly halves.  It confuses people and makes them uneasy.  I would just say have a constant 1 block => 1 bitdnscoin.

[RHorning]

I like DomainChain as well.

I would also argue against any particularly special attachment to bitcoins, what would the purpose of that be except to hopefully promote bitcoin? I prefer to allow it to be a separate market in it's own right. With people able to pay for domains from those who've managed to generate them using whatever payment method they want to agree on.

Do we have a wiki yet?

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.

[Hal]

I also had an idea last night of how/where to tie this into the existing DNS.

When you lookup foo.com, software on your computer called a resolver is responsible. It has some caching and local data, but mostly it just asks a DNS server for the answer. You have one or more DNS servers configured as part of your network setup, and these servers respond to domain name lookup queries either directly, or by initiating their own search of the domain name system.

Obviously we want existing name lookups still to work. Broadly speaking, then, we would change the software to first check if a name is registered in the BitDNS system, and if not, to fall back to the regular handling.

My idea is that the best place to add the BitDNS lookup code is in a DNS server rather than in the resolver. Resolvers are different for every OS, so there's more work. I don't even know if the resolver logic can be changed on Windows. Plus this code is going to need to be tracking the BitDNS block chain, and not every end user should have to do this.

Other 'alternative' DNS systems do it like this, with one or more special DNS servers that know about their extra domains.

We would choose some open source DNS server as a base, fork it and add the code to lookup BitDNS names. Whether these names all have a distinguishing TLD ".bit" or whether we are more aggressive and take over more namespace, either way it could be done.

As I understand it, when a DNS server looks up foo.com, it finds the (or a) name server authoritative for .com, and asks it for what is called a SOA record for foo.com. This tells what name servers are authoritative for foo.com, and the DNS server then tries them to get details on foo.com.

We would intercept this first step, and use the BitDNS code to find the authoritative name servers. Maybe we could create a dummy SOA record to hold the data, to simplify falling back into the regular DNS code.

People who want to use BitDNS would just have to select one of the BitDNS aware DNS servers. Paranoids could run their own name servers locally and track the block chain. All the usual optimizations of DNS in terms of caching, distribution, etc. would work, so it would not have much negative impact on the net.

[RHorning]

That sounds nice.  However, I was always uncomfortable with how block miners get 50 coins, and slowly halves.  It confuses people and makes them uneasy.  I would just say have a constant 1 block => 1 bitdnscoin.

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

[em3rgentOrdr]

That sounds nice.  However, I was always uncomfortable with how block miners get 50 coins, and slowly halves.  It confuses people and makes them uneasy.  I would just say have a constant 1 block => 1 bitdnscoin.

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

Exactly.  My points exactly.  The reason for halving bitcoins over time does not really exist for bitdnscoins.