BitcoinTalk
BitDNS and Generalizing Bitcoin

View Satoshi only

External link

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
Just for reference, the discussion on IRC starts here http://bit.ly/9qjLL5
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?
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?


It's pretty much the same as starting a separate service.  You have to convince a few people to use your system.

But in this case, there are some incentives for a BitX miner to adopt your new BitX app (in this case, bitDNS).

For one, it doesn't impact the miner's mining speed.  And he would end up with a possibly valuable resource in the form of a very big head start on bitDNS registrations.

Consider the case in which there are 5 big BitX miners that each control large processing pools.  They each generate 20% of bitcoins (which is now running on the BitX protocol) yet the first one to generate bitDNS names would generate 100% of names until the second adopted bitDNS as well, and this would be at no cost to him.

In the case of buying a name, you need an escrow that will temporarily hold the btc and the name until they are both confirmed, and then pass them along to the new owners.  I think it's best to keep btc and dns completely separate so that they can succeed or fail independently yet leverage the single block chain.
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.
Since more and more of these ideas to uniquely acquire some virtual resource appear, why not abstract away the entire, domain specific, logic and just create a service that does p2p proof of work all day long, on which the services can be implemented? It might help strengthen the main chain, by basing multiple applications on it, and might reduce the repetitive work for each system, since the basis is already there.
Since more and more of these ideas to uniquely acquire some virtual resource appear, why not abstract away the entire, domain specific, logic and just create a service that does p2p proof of work all day long, on which the services can be implemented? It might help strengthen the main chain, by basing multiple applications on it, and might reduce the repetitive work for each system, since the basis is already there.

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, ...
So now the question is what kinds of central authorities can be replaced by this type of quorum?
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
ByteCoin, I think you can just keep a pointer to the last valid block per app in the big block chain.

So, when you mined, you would produce new app data for each app you cared about and stick the hash of that data as well as pointer to the previous vaild app block (per app you care about) into the big block chain.

In other words, the big chain has a next pointer to the last valid big block, as well as a next pointer to each last valid app block you care about.  So, if you think there was an invalid app block, you can still add to the longest big block chain and reject the invalid app block by pointing further back in the chain to the last valid (in your view) app block.

You don't have to know about every app in this case.  This plan still retains the bonus that miners can mine for as many apps as they want.
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/
http://p2pdns.baywords.com/2010/11/30/hello-world/

I just found this from Peter Sunde who wants to create a decentralized dns system.

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
Quick! Offer a bounty in bitcoin!
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?
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?

Hmm? I thought we're going to use a separate blockchain than what bitcoin use.
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
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

Calling something retard and having no substance to back it up is not a good argument.
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

Calling something retard and having no substance to back it up is not a good argument.

retarded means "slowed" which ironically is the case here

retarded means "slowed" which ironically is the case here

Huh

retarded means "slowed" which ironically is the case here

Huh

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

Not really. Since, 144 blocks were generated each day in the bitcoin network, this mean 7200 addresses that can be assigned a domain name. Plenty, if you asked me.
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

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

Bitcoin would be more for buying and selling domains I think. Any profits involved could go to the EFF which already accepts bitcoin donations. In a sense this would tie dns and domain names to the health of the EFF.

 Smiley  Id like to see the government try and seize domains from those guys ,can you imagine the shitstorm that would create  Cheesy

How would domain name renewal work?  Huh
How would domain name renewal work?  Huh

Presumably if the protocol requires a renewal transaction, the identity authentication system (likely a public/private hash key) would allow you to create a new "transaction" on the network submitting the necessary information along with a transaction fee.
Presumably if the protocol requires a renewal transaction, the identity authentication system (likely a public/private hash key) would allow you to create a new "transaction" on the network submitting the necessary information along with a transaction fee.

I see. Then the miners will set the fee for domain renewal.
Presumably if the protocol requires a renewal transaction, the identity authentication system (likely a public/private hash key) would allow you to create a new "transaction" on the network submitting the necessary information along with a transaction fee.

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

Exactly!  It would become a marketplace where those people willing to put resources into building this chain would set the fee they think is most appropriate.  I really don't see this happening without fees getting put in at some point.

This is also something where deflation would be dealt with through the marketplace as well, as there would be increased competition if transaction fees started to get a little high where somebody offering to take on perhaps slightly lower transaction fees would push their way into the block making competition.  So if 0.01 BTC becomes worth $100, there might even be many "miners" willing to charge perhaps only 0.001 BTC or an even smaller amount.
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.
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.

If someone lost their wallet, their domain name stay with them forever, with no way to transfer it.

Eventually, you get a long string of really good domain name that can't be used forever.
Eventually, you get a long string of really good domain name that can't be used forever.
It's the same as with bitcoins, it just makes the remaining names more valuable.
It's the same as with bitcoins, it just makes the remaining names more valuable.

if sex.bitcoin is lost for example, it can't be used forever. And there is only one sex.bitcoin in the whole universe.

It doesn't necessary make other domain names more valuable. What it does though is make certain resource useless.
...if sex.bitcoin is lost ... It doesn't necessary make other domain 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.
The loss of sex.bitcoin would surely make sexy.bitcoin and xxx.bitcoin more valuable.

I concede that one.
Quote
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.
Then this is a matter of competition between various BitDNS system then.
It's the same as with bitcoins, it just makes the remaining names more valuable.

if sex.bitcoin is lost for example, it can't be used forever. And there is only one sex.bitcoin in the whole universe.

It doesn't necessary make other domain names more valuable. What it does though is make certain resource useless.

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

Can you please explain what you mean by this?
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.

Can you please explain what you mean by this?

What do you need explained?

What do you need explained?

Why is it so easy? How is it done?

What do you need explained?

Why is it so easy? How is it done?

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.
Or all domains expire yearly and will need to be regenerated, but if you send it to yourself before it ends you get to keep it. Like this we fix the issue of lost domains and allow dropping old names for free.
Or all domains expire yearly and will need to be regenerated, but if you send it to yourself before it ends you get to keep it. Like this we fix the issue of lost domains and allow dropping old names for free.

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.
Its like bitcoins but time based old domains get freed up after 365 days, if you want to keep it just send it to someone or to yourself.
Quote from: irc
<genjix> dot-p2p: "We currently believe the best way to create a stable
    environment for TLDs is to enact a central authority. We know this
    will cause much argument within the community, but we have made the
    decision that we believe will be best for the continued development
    of this project."

Knew it. They sucks.

Our opportunity is now, but unfortunately I think we lack the expertise to create a BitDNS.
http://bitcointalk.org/index.php?topic=2072.0

Started a pledge drive. Go. Go. Go.
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?
That's very clearly expressed, thank you Hal.

What you describe is almost exactly what I have in mind. Additionally, I would allow the domain name itself to be subsequently changed to any other untaken name:

Quote
Subsequently a registration might have three things happen to it:
 - the IP address of the DNS server might change
 - it might be transferred to a new owner
 - the domain name might be changed

The advantage of allowing domain name changes is that it makes the initial registration easier. Registrars can generate arbitrary registrations, then change the name when they sell them to their customers.

Quote
When you generate a block you get to create 50 of these entries

Exactly. The "50" is arbitrary, but that doesn't matter. The initial scarcity will be reflected in a high price, which will encourage people to generate, which will raise the difficulty and ensure the security of the system.

With 7200 registrations being generated daily, there will soon be plenty to meet the demand. The price will then drop, with transaction fees maintaining the incentive to generate.
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.

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.
ames. Of course they have to be new names that were not in earlier blocks.

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 am using this document as the BitDNS bounty's protocol document.
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.

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.

Sorry for being too lazy to read all previous posts...

But has anybody actually proposed using bitcoin algorithms to create decentralized DNS to Peter Sunde yet ?
Sorry for being too lazy to read all previous posts...

But has anybody actually proposed using bitcoin algorithms to create decentralized DNS to Peter Sunde yet ?

People already put up links about BitDNS.
Sorry for being too lazy to read all previous posts...

But has anybody actually proposed using bitcoin algorithms to create decentralized DNS to Peter Sunde yet ?

Several bitcoiners have been in the p2p-dns irc chat and have spoken about it.

Its also been written about on their wiki.

http://dot-p2p.org/index.php?title=Draft_Discussion_Paper  they have a discussion paper out but looks like they have opted for using open nic for now plus a .key domain for a decentralized dns.

As far as I know the argument against using bitcoin is that if you lost your keys to access the domain you would not be able to recover them.

How does bitdns get around that?

As far as I know the argument against using bitcoin is that if you lost your keys to access the domain you would not be able to recover them.

How does bitdns get around that?

A domain name key should be so important that people will backing it up, automatically.
Sorry for being too lazy to read all previous posts...

But has anybody actually proposed using bitcoin algorithms to create decentralized DNS to Peter Sunde yet ?

People already put up links about BitDNS.


I added bitdns to the ideas page here
http://dot-p2p.org/index.php?title=Ideas#BITDNS


I added bitdns to the ideas page here
http://dot-p2p.org/index.php?title=Ideas#BITDNS



The likelyhood of the idea getting implemented is likely slim to none.
Sorry for being too lazy to read all previous posts...

But has anybody actually proposed using bitcoin algorithms to create decentralized DNS to Peter Sunde yet ?

As far as I know the argument against using bitcoin is that if you lost your keys to access the domain you would not be able to recover them.

How does bitdns get around that?

I think this is a good argument against almost any peer-to-peer distributed database of any kind.  This isn't something unique to just Bitcoin.

All of this is sort of strange, as I thought the whole point of the exercise was to try and decentralize the DNS database.  Instead, there is going to be a central point of control for the whole thing and an official "authority" who is going to be acting as a gatekeeper.  Really, this seems to be a betrayal of whatever it is that they were trying to accomplish and they are now becoming an alternate to ICANN, not something which is really a genuine distributed domain repository.  There may be some differences as it may become a sort of Napster of domain registration, but it still has that point of attack, whatever that attack may be from either a digital, legal, or physical kind of attack.

It is too bad that they aren't rethinking the entire issue down to its roots, which is an attempt to create a "directory" of the internet.  They are also getting IMHO hyper-paranoid about trademarks, as if coca-cola.com isn't sufficient to identify a particular corporation that most people know anyway.  So what if somebody creates coca-cola.p2p?  Or for that matter wikipedia.p2p?

There also seems to be a mindset that it must follow the convention of:

<computer> <dot> <domain> <dot> <top level domain>

There was an historical reason for the original divisions for .com, .mil, and .edu.  They represented three distinct and separate networks originally called "COM-NET", "MIL-NET", and "EDU-NET".  It is sort of like how telephone systems used to be completely separated between business exchanges and residential exchanges.  When the three networks were finally linked, they had to use some way to identify how to access computers on one network to another, so the "TLD" system was originally set up and some other side "TLDs" were made for "miscellaneous organizations" (.org), "international organizations" (.int), and generic "network resources" (.net).  When people outside of America were participating in adding their networks to the internet, they were identified by their country code , now the various "country code top level domains".

Mind you, when the codes were handed out, there was the .us domain which seemed redundant (it was) but those already having .com didn't want to go to a longer .com.us.

Anyway, I contend that the whole notion here of a top level domain is something that completely unnecessary, and that viewpoint has been long advocated by Karl Auerbach.  If you've never heard of this guy, it should be important that he was the one and unfortunately only official elected representative of North America to ICANN, and sort of a major rebel.  He was one of the "at-large" directors that had to get a California court to force ICANN to actually show him their books (he was one of the members of their board of directors and supposedly recognized as such by the organization) and because of his efforts his position was dissolved by the appointed board members made up of people hand-picked by major corporations.  The whole experiment of democratically elected representatives to ICANN was killed by the U.S. Department of Commerce... isn't that something?

Anyway, if anybody knows DNS backward and forward, it is Karl Auerbach, and one of his positions when he was on the ICANN board was that there was no need to even have a top-level domain system at all, and certainly the number of top level domains could certainly number in the millions or more.  It is simply a directory.

This history paper about DNS goes into the gritty details of how it finally got started.  This really is a seminal paper on the history of DNS in terms of how we got to where we are today.

Another paper by Karl Auerbach is certainly worth reading so far as to see what a very well thought out objection to the current DNS system as implemented by ICANN was and how when the whole system was created had people proposing some significant alternatives.  Since supposedly we are talking about alternatives to the centralized DNS, I think this ought to be at least one of the key papers worth reading.  It shouldn't be surprising that the problems he identified over twenty years ago are still present in the current system, and it is important to note that there was opposition back then even to the current system.  If you read between the lines, he was even upset over how IP addresses were allocated... which is a completely different beast altogether.

I don't think that those working with this new "dot P2P" effort are really reading stuff of this nature.  I find it too bad as well, as it shows the immoral and arguably illegal actions taken by those who set up the current system almost as if it was a sort of Jekyll Island episode of the Internet.  There are a whole bunch of common parallel themes between the formation of ICANN and the Federal Reserve.  In this sense, perhaps Bitcoin really is a good fit as it sort of is a merger of the two systems that have been corrupted by aristocrats in a supposedly egalitarian and "officially" classless society.

In short, I think that the "dot P2P" effort is doomed to failure if the continue down the path they are going and not addressing the real problems facing the current system.  Many of those problems are being addressed by BitDNS, even if it is a bit marginalized at the moment.  And I also think that the argument about lost keys is not something nearly as significant either compared to the major issues about what is wrong with the current DNS system.
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/
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/


Yes that is what we are discussing. I was in the irc chatroom while all of it was being discussed. I brought up bitcoin several times but was scoffed at,as did someone else. As usual people dont learn from the mistakes of the past and are bent on creating a mirror of ICANN. All I can say is WTF?

I even saw one guy mention how he worked on an email system for the NSA ! and no one even asked the obvious question about someone from  the NSA steering the discussions towards a centralised system.


I say we prove everyone wrong and do our own thing. Centralisation is a big steaming bag of FAIL.


As far as I know the argument against using bitcoin is that if you lost your keys to access the domain you would not be able to recover them.

How does bitdns get around that?

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.


I say we prove everyone wrong and do our own thing. Centralisation is a big steaming bag of FAIL.


Yes, yes. This is why I offered a bounty. I encourage everyone to pledge some bitcoins if they aren't capable of doing this project.

Why it is only 40 BTC at this stage is beyond me.

I say we prove everyone wrong and do our own thing. Centralisation is a big steaming bag of FAIL.


Yes, yes. This is why I offered a bounty. I encourage everyone to pledge some bitcoins if they aren't capable of doing this project.

Why it is only 40 BTC at this stage is beyond me.

Where do I pledge?
Best way to get the BitDNS system running off the ground?

Adapt the bitcoin source code?
Quote from: irc
<genjix> dot-p2p: "We currently believe the best way to create a stable environment for TLDs is to enact a central authority...

Knew it. They sucks.

They are responding to a problem caused by a central authority by enacting ... another central authority. But I don't think it's because "they sucks". I think it's because they haven't been exposed to such a beautiful decentralised design as bitcoin.

Quote from: kiba
Best way to get the BitDNS system running off the ground?

Adapt the bitcoin source code?

Adapting the bitcoin source code is probably the only practical way for us to get this running. But first I would like to see us produce a brief white paper setting out the design principles, and a non-technical FAQ.

Adapting the bitcoin source code is probably the only practical way for us to get this running. But first I would like to see us produce a brief white paper setting out the design principles, and a non-technical FAQ.

Ribuck, If only I have the necessary knowledge to adapt it, I would have dropped it and just implement it.
Adapting the bitcoin source code is probably the only practical way for us to get this running. But first I would like to see us produce a brief white paper setting out the design principles, and a non-technical FAQ.

What kind of time-frame are we talking about here in terms of getting at least a "proof of concept" project going?

If it took a year, it seems like something else would be taking its place, but if we got some software up and going in the next month or two it seems like the "distributed DNS" supporters might really pay attention to BitDNS.  Indeed, with the philosophies of Bitcoin already established, I don't think there is nearly as much "debugging" to get this going as it may seem.  Some, yes. But it isn't the end of the world.  Getting something done by tomorrow may be a bit more difficult.

The time frame of this idea is something that I believe has a short time span to at least get something to the table, even if there might be some competing ideas.  The strengths of using Bitcoins and a Bitcoin-like system are things that solve many of the problems being proposed from what I've seen.

Writing up a white paper?  It would be nice and if you want to start that I would be willing to contribute to the content, but I would rather be programming right now at least to come up with a rough mock-up of the idea.
Speed is of the essence if we're going to show .p2p how to really do distributed DNS.
What kind of time-frame are we talking about here in terms of getting at least a "proof of concept" project going?

I think this schedule may be possible:

1. Two weeks: Prepare, agree and release three documents: an overview in non-technical language, a FAQ, and a technical but informal white paper which expounds the motivation and the design principles.

2. Three months: Demonstrate a "proof of concept" on a test network.

3. Six months: Release a basic but usable version 0.1.

(4. Generate some names while the difficulty is low.
5. Profit!)

Writing up a white paper?  It would be nice and if you want to start that I would be willing to contribute to the content, but I would rather be programming right now at least to come up with a rough mock-up of the idea.

I will start on the documents. I would rather be programming too, but as kiba says: time is of the essence. This is an idea whose time has come. We can't get this done with just RHorning, kiba and me. We have to build a team. And a set of basic documents serves two important purposes: it attracts newcomers to the team, and it helps to keep the whole team working towards the same goal.

Here are some early tasks that fall on the "non-documentation" side, in case you or anyone else is interested.

* Set up the development environment. Are we going to use SourceForge? GitHub?
* Choose a project name. We've been using "BitDNS", but it's not really an accurate name because we're not reimplementing DNS, just domain name registration. Then register the ".org" domain.
* Set up a build process so that we can distribute for Windows, Linux and OS/X.
* Read, learn and understand the Bitcoin source code and its underlying principles.
* Set up the development environment. Are we going to use SourceForge? GitHub?

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.
I would like to be looped into this project.  I think that something like BitDNS can provide the intrinsic "use value" for bitcoin.  I'm a firm believe that bitcoin in its current state is a solution looking for a specific problem.  Perhaps a distributed dns is that "problem."  This is exciting!
I would like to be looped into this project.

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.

Here are some early tasks that fall on the "non-documentation" side, in case you or anyone else is interested.

* Set up the development environment. Are we going to use SourceForge? GitHub?
* Choose a project name. We've been using "BitDNS", but it's not really an accurate name because we're not reimplementing DNS, just domain name registration. Then register the ".org" domain.
* Set up a build process so that we can distribute for Windows, Linux and OS/X.
* Read, learn and understand the Bitcoin source code and its underlying principles.

For the source repository, I am agnostic toward that as long as I can get the source files in and out.  SourceForge has been pretty good to me in the past and it has worked out with other projects I've been involved with, so I sort of lean that way although it appears Kiba love Git.  I'm fine with that too.

As for a project name, how about DomainCoins?  Otherwise I love more obscure ancient dieties/demigods as names and there are a few out there.  I guess the choice here is one that is more functional or one that can be memorable.  Does anybody know a name of some ancient diety of finance or accounting?  Babylonian and Aztec gods would be especially interesting.  Either that or simply a whimsical name that may not mean anything at all.

For a build process, I'm not really particular either but I do insist upon "free" or "open source" tool chains.  I personally am not a big fan of C++ (sort of antagonist about the language) but I'll contribute however anybody else wants to go.  I agree that it should be built on all of those platforms and be capable of going to more.  I have a stronger preference to C# on Mono if that matters any where MonoDevelop is a pretty good environment.

In term of reading up and understanding the Bitcoin source code.... I'm way ahead of you there.  I've been pounding my head against that for awhile now.  There still is more to pour through, but I'm finally starting to get a good grasp of the base network layer now even if some of the details like the block rejection rules aren't quite so firm yet.  Expanding the documentation would be still beneficial.
I would like to be looped into this project.  I think that something like BitDNS can provide the intrinsic "use value" for bitcoin.  I'm a firm believe that bitcoin in its current state is a solution looking for a specific problem.  Perhaps a distributed dns is that "problem."  This is exciting!

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?
* Potential Social Conflicts - What sort of "legal" requirements might there be for "domain registrations" and what do we do about them?  Do we care?

When in doubt, remove human elements. Adopt certainty of computer software code over uncertainty of judges. Complicated rules invite gaming and abuse.
When in doubt, remove human elements. Adopt certainty of computer software code over uncertainty of judges. Complicated rules invite gaming and abuse.
Kiba is wise.
I suggest tahoe lafs if you are looking for a database for storage.
I suggest tahoe lafs if you are looking for a database for storage.

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.
I suggest tahoe lafs if you are looking for a database for storage.

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.

GUI design is important, but it is also something that non-techies can help with even if all you do is make a mock-up in something like MS-Paint or GIMP.  Getting the buttons to work is a bit harder, but not really so much.  The tough part about GUI design is that it is an art skill, something that techies often lack.  There is much more about artistic balance, the golden mean, and selecting colors or icons that aren't offensive to certain cultures (yellow buttons are a bad idea in Chinese culture, for instance, or showing a swastika to a bunch of germans).

I agree that there are priorities in terms of getting the network layer put together first, but if we can get more people involved I don't think it should be dead last in priority either and certainly can be worked on concurrently with other projects.
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.
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?

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.
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.
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.
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?
+1 on DomainChain or BitRegister over BitDNS (no offense kiba Wink )
+1 on DomainChain or BitRegister over BitDNS (no offense kiba Wink )

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.
+1 on DomainChain or BitRegister over BitDNS (no offense kiba Wink )

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"?  
I have no complaint.
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.

Quote
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?

Quote
"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.
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?
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.
+1 on DomainChain or BitRegister over BitDNS (no offense kiba Wink )

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

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

Quote
Quote
"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.
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?
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.
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.
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.
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.
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).
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.
The reason for halving bitcoins over time does not really exist for bitdnscoins.

Good. Something everyone completely agrees on!
Exactly.  My points exactly.  The reason for halving bitcoins over time does not really exist for bitdnscoins.

Wondering aloud even more, what need do we have for a fractional bitdnscoin?  I could imagine having a little bit of "change" but is there going to be any need for more than about three or four decimal places?

This is essentially the same issue just thought through from another perspective.  Right now I think it is about 100 million "bitcoins" to the smallest unit as defined in the Bitcoin protocol.   We really don't need that many decimal places even for trade purposes.  I still like the uint64 structure used in the Bitcoin protocol, but with a mild sort of inflation happening to the currency (relative to Bitcions) I don't see any major deflationary pressure pushing the value down like I see for Bitcoins.  Again, I am not an economist and this is going to take some hard economic theory and guessing which way even this currency might go in that perspective.  The only other "currency" to make a real comparison about here is the coins on the test network, and the main thing there is that those coins aren't being traded... which makes even that a bad example.

I don't know of any other currency that uses this sort of allocation system even remotely.  Of course that is why this is so groundbreaking.
Good. Something everyone completely agrees on!

So the formula for creating problems and adjusting difficulty will be the same?(Forgive my ignorance)
I also had an idea last night of how/where to tie this into the existing DNS.

I know this discussion is going like nuts here.  I think this is a very good idea and should be fleshed out much more.  If you have some experience or knowledge about local domain name servers, your expertise here would be invaluable.  I know just enough to get myself into trouble on that matter and to debate the policy questions, not enough to really dig into the guts of them.  I've operated a domain server for a brief period of time and have experimented with OpenNIC myself.
Anyway, I have registered domainchain.org, in case people like it.

Care to stick a wiki up on there?
Good. Something everyone completely agrees on!

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

I don't see any reason why we should try something different.  If it breaks for us or for Bitcoins, one or both projects should get the issue fixed with an alternative solution.  There certainly are strong reasons to keep this system, as Satoshi's white paper points out in pretty good detail too.
Quote
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.
Well people couldnt say domaincoins werent backed by anything.   Cheesy

I like the idea of a constant block rate.
On the question of how many domain names to create per day:

http://www.domaintools.com/internet-statistics/

There are about 100 million active domain names, and 400 million expired ones. About 300,000 changes occur per day, divided equally between creation, expiration, and transfers.

If we create only 50 domains per block, 6 blocks per hour, that is 7200 domain names per day. At that rate it would take like 50 years to create 100 million domains. So it seems necessary to make names faster.
If we create only 50 domains per block, 6 blocks per hour, that is 7200 domain names per day. At that rate it would take like 50 years to create 100 million domains. So it seems necessary to make names faster.

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.
On the question of how many domain names to create per day:

http://www.domaintools.com/internet-statistics/

There are about 100 million active domain names, and 400 million expired ones. About 300,000 changes occur per day, divided equally between creation, expiration, and transfers.

If we create only 50 domains per block, 6 blocks per hour, that is 7200 domain names per day. At that rate it would take like 50 years to create 100 million domains. So it seems necessary to make names faster.

The question as to how many domains to include in a block ought to be something dependent upon the miner alone.  This certainly is a useful point to bring up and likely an early "reference implementation" limit will be 50 domains per block merely to increase scarcity.  Still, that up to 300k changes might happen eventually with this system, perhaps more considering that the cost is likely going to be considerably less than the current domain registration system.

----

I have a few other thoughts about this now that we are getting to something a little more concrete in terms of the software architecture.  Would it be reasonable to expect the cost of a domain registration to be 1 DCC (Domain Coin Currency)... at least as the "default" cost expected by the miner to "register" a domain?  I think that would establish at least an initial value to the currency and help to self-regulate those who want to jump in early and grab up a whole bunch of domains early on.  I might even go so far as to say 2 DCC for registration and 1 DCC for information changes.  If you run your own miner, you can "tweak" this if you want to be more competitive, but this is the way that you can spend the currency and what it is based upon and a fair benchmark.

In terms of a social effect that may be negative (depending on your viewpoint) some of the country code TLDs represent a substantial source of income for some of countries involved.  One in particular, the country of Tuvalu, has only a little over 12,000 citizens and is the smallest member-nation of the United Nations in terms of population and pretty close to that in terms of land area.  Only the Vatican has a smaller population in terms of a sovereign state.  Its current TLD (*.tv) is currently run by a company in California but a significant portion of the revenue from that domain goes to the country's government under contract.

On the topic of small countries and their "country codes", it seems like if we could get this software rather stable, we might even want to offer this "service" to some of these smaller countries for their domain registrations, where I'm pretty sure that this would be cheaper than whatever contract they currently have with their current service provider.  That goes under "marketing", but something else to think about.  I certainly think that it would be awesome if we could get a whole country like Tonga to switch to Bitcoins as their national currency, and is much more likely to happen than the major western countries like America or the EU.  Just dreaming there.
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!
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!

I think you got the ideas down.  The role that the "DomainCoins" (DCC) are playing here is to give a financial incentive to "miners" who are creating a cryptographically secure domain registration database.  It is also a work-around due to the fact that we can't seem to figure out a way to accomplish the goals of getting Bitcoins directly to the miners, so instead we are going to be using an alternative currency which can be traded for mining.  To me, the only reason for putting any sort of coin generation into the blocks is simply to "prime the pump" to get some DCC put into circulation.  Hopefully what will normally happen is that DCC will be exchanged for Bitcoins in both directions:  Some folks will "buy" some DCC with Bitcoins (or LR Dollars or whatever) so they can pay for domain registrations and the miners will "redeem" the DCC for Bitcoins as earnings.

Trade between DCC and BTC will be almost insanely easy by design and the exchange mechanisms may even be put right into the GUI interface.  I could even see custom clients that might even combine transactions for both "currencies".

This same system could be used in a number of other similar situations, such as an idea I floated about creating a Bitcoin-based Stock Exchange.  If such a stock exchange is set up, a similar parallel currency may have to be implemented to also pay for mining the transaction blocks.  I can see many other kinds of "databases" set up which would require some sort of cryptographic time-stamping.  Something I played with a while back that could be useful here would be "timestamping" police evidence (especially digital evidence such as a dashboard camera video feed from a police vehicle) in a chain of custody system.  An engineering company could set up a custom "bitcoin" system to keep track of engineering documents to be used as a defense against a patent lawsuit to both show date of creation and prove that the document file hasn't been tampered with since its inclusion into the database.  Seriously, this system is something that has a whole bunch of possibilities that I can't even start to describe the kinds of things that would be useful and we are just scratching the surface.
Wait, I am a bit confused. Alternative currency for DomainChain?

Oh, these represent addresses?
Actually I am concerned that transactions between BTC and DCC may not be simple. Because both currencies tend to be anonymous, it is hard to make the two transfers in a coordinated way. If Anne wants to sell Beth 1 DCC (allowing 1 domain to be created) for a certain number of Bitcoins, then Beth must send Anne the Bitcoins via the Bitcoin block chain, while Anne sends Beth the DCC on the DomainChain. If the two are anonymous to each other, it seems there must be a trusted third party like a reputable exchange. It seems hard to do peer to peer.
Actually I am concerned that transactions between BTC and DCC may not be simple. Because both currencies tend to be anonymous, it is hard to make the two transfers in a coordinated way. If Anne wants to sell Beth 1 DCC (allowing 1 domain to be created) for a certain number of Bitcoins, then Beth must send Anne the Bitcoins via the Bitcoin block chain, while Anne sends Beth the DCC on the DomainChain. If the two are anonymous to each other, it seems there must be a trusted third party like a reputable exchange. It seems hard to do peer to peer.


Doesn't seem hard to me. It's a normal trade to me.
Wait, I am a bit confused. Alternative currency for DomainChain?

Oh, these represent addresses?

A coin would represent a domain. I think that is the proposal.

Could ip addresses themselves be managed by this system?  The ipchain would prevent anyone having duplicate addresses. This removes central control of ip address allocation and the ability to track individual machines. Ipv6 has a privacy issue doesn't it?   They stuffed ipv4 because address allocation became a scarce resource by bad management.


Does .dnc = domain name coins?

We could co-opt the democratic national convention lmao.



Actually I am concerned that transactions between BTC and DCC may not be simple. Because both currencies tend to be anonymous, it is hard to make the two transfers in a coordinated way. If Anne wants to sell Beth 1 DCC (allowing 1 domain to be created) for a certain number of Bitcoins, then Beth must send Anne the Bitcoins via the Bitcoin block chain, while Anne sends Beth the DCC on the DomainChain. If the two are anonymous to each other, it seems there must be a trusted third party like a reputable exchange. It seems hard to do peer to peer.


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

So you need two clients running?

edit:never mind...
If the two are anonymous to each other, it seems there must be a trusted third party like a reputable exchange. It seems hard to do peer to peer.

Doing peer to peer currency exchanges is beyond the scope of this project.  If there is going to be some sort of peer to peer currency exchange (I think it might be possible, especially for non-reversible currencies like Bitcoins and Liberty Reserve Dollars), it should be in a completely different project.  All that I'm suggesting is that some sort of API be set up so one or more "trusted exchanges" can be selected to facilitate the "purchase" or exchange of these "coins" for some other currency.  I just don't see too many people going through the hassle of trying to obtain these "domain coins" by selling other services in these coins, even though that would in theory be possible.

If we could dump this idea of another currency, I'd be all for it.  I just don't see how to do that though.

On the positive side, the fancy API and GUI exchange methods won't be strictly needed at all at least initially.  We could even use essentially the existing bitcoin software where all we would do is to simply "tweak" the low level features so we would be including the domain information into the blocks.  If we did that as a quick bootstrap of the network, websites like Mt. Gox could use the same JSON API system for Bitcoin on this system as well, particularly as the exchanges wouldn't have to play with the domain information but rather just the coin trading mechanisms.  Exchanges would want to get into the act as there certainly are arbitrage opportunities between the DCC and BTC currencies.

Our hard part is to define the "rules" of what domain information needs to be present, and when a block can be rejected because of mal-formed domain data.  That is where I think it would be wrong to put this more directly into the Bitcoin block chain, as rejecting Bitcoin blocks because of a malformed domain record seems to be harmful to Bitcoins.
Wait, I am a bit confused. Alternative currency for DomainChain?

Oh, these represent addresses?

A coin would represent a domain. I think that is the proposal.


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.
Wait, I am a bit confused. Alternative currency for DomainChain?

Oh, these represent addresses?

A coin would represent a domain. I think that is the proposal.


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.

Thanks for clearing that up.

Anything is better than buying another domain from godaddy . Smiley
At any rate, do we have enough information that's agreed so that the core hackers can develop right now?
Could ip addresses themselves be managed by this system?  The ipchain would prevent anyone having duplicate addresses. This removes central control of ip address allocation and the ability to track individual machines.

Having ip address themselves be managed by a bitcoin-like system is a very interesting idea...

I never liked how the government and major corporations get to dish out vast swaths of the ip spectrum by dictate and privilege...

Ipv6 has a privacy issue doesn't it?   They stuffed ipv4 because address allocation became a scarce resource by bad management.

Is this privacy issue because ipv6 address will embed your MAC address?

Quote
IPv6, on the other hand, has 128 bits of address space, enough to provide a billion-billion addresses for each square meter of the earth's surface. How one could ever route that many addresses is an interesting question, but at least IPv6 will never run out.

As you might expect, the address field is so huge that the IETF didn't know how to assign it. So, in a move to get buy-in from established industry standards bodies, the right-most 64 bits were designated to contain EUI-64 format information. This is used by the IEEE to assign Ethernet addresses, which are normally not transmitted outside a user's LAN.

Included in EUI-64 are two interesting pieces of information: the registered manufacturer of your NIC card and your 48-bit Ethernet address. Surprise! Every packet you send out onto the public Internet using IPv6 has your fingerprints on it. And unlike your IP address under IPv4, which you can change, this address is embedded in your hardware. Permanently.

Does .dnc = domain name coins?

We could co-opt the democratic national convention lmao.

LOLFEST!   Cheesy


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

Wondering aloud even more, what need do we have for a fractional bitdnscoin?  I could imagine having a little bit of "change" but is there going to be any need for more than about three or four decimal places?

I agree...there is not as much reason for fractional bitdnscoins. That just complicates the algorithm and operation.  Making bitdnscoin be simple unitary entities is much simpler and easy to understand, so it will increase the likelihood of widespread adoption.  Simpler is better.  Computer hardware and software like things simple.


This is essentially the same issue just thought through from another perspective.  Right now I think it is about 100 million "bitcoins" to the smallest unit as defined in the Bitcoin protocol.   We really don't need that many decimal places even for trade purposes.  I still like the uint64 structure used in the Bitcoin protocol, but with a mild sort of inflation happening to the currency (relative to Bitcions) I don't see any major deflationary pressure pushing the value down like I see for Bitcoins.  Again, I am not an economist and this is going to take some hard economic theory and guessing which way even this currency might go in that perspective.  The only other "currency" to make a real comparison about here is the coins on the test network, and the main thing there is that those coins aren't being traded... which makes even that a bad example.

Could you clarify?  Are you talking about because bitcoins have a limited number of digits that it can be divided into (according to the algorithm), that therefore 1 bitcoin could be instead thought of a ~million mini nano-bitcoins that are of fundamental unit of trading size?


Anything is better than buying another domain from godaddy . Smiley

Awesome!  NO need for the middle man!  rent

This brings up another interesting point: most people will not need to have to pay the yearly ~$10 rent to their domain name provider, if they generate the bitdnscoin themselves.  Of course, this does not abolish rent on domain names, as there will be of course some mega bitdnscoin miners will speculate to purchase domain names they think will be in high demand, and will then rent out the popular domains they own.
Whats the general plan here? No reduction in names/block I assume? Won't this make the first blocks incredible valuable and later blocks less valuable as the goodness of remaining names declines? Maybe it should start really low (1?) and move up gradually to a stable amount (100?)?

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.
At any rate, do we have enough information that's agreed so that the core hackers can develop right now?

Well before starting coding, let's make sure we have the protocol clearly written out.  For instance, are we going to take my suggestion of using unitary, non-fractional, bitdnscoins where 1 block == 1 bitdnscoin, instead of having the number of bitdnscoins per block start at 50 and half every few years?  Also, there is no need for fractional bitdnscoins since it doesn't make too much sense to own one-tenth of a domain name.  Keep in mind that people can use fiat money or even bitcoins when trading unitary bitdnscoins, incase they need to make a trade of two domain names with unequal subjective valuations.
At any rate, do we have enough information that's agreed so that the core hackers can develop right now?

Well before starting coding, let's make sure we have the protocol clearly written out.  For instance, are we going to take my suggestion of using unitary, non-fractional, bitdnscoins where 1 block == 1 bitdnscoin, instead of having the number of bitdnscoins per block start at 50 and half every few years?  Also, there is no need for fractional bitdnscoins since it doesn't make too much sense to own one-tenth of a domain name.  And, keep in mind, people can use fiat money or even bitcoins when trading unitary bitdnscoins, incase they need to make a trade of two domain names with unequal subjective valuations.

+1 on that.

Oh god.  I try not to read the news...it just makes me angry.

Quote
White House intellectual property czar Victoria Espinel said Monday that the Internet community should \u0093expect more\u0094 pre-emptive action as the administration combats online copyright infringement \u0097 especially the illegal copying and sale of pharmaceutical drugs.

So now we will all have to pay rent for an artificial government-imposed monopoly on life-saving pharmaceutical drugs, just so that we can live longer.  Intellectual Property => have to pay rent for your body.  IP == slavery.  Just because someone is the first to file a patent on a lifesaving drug, doesn't give him the right to exclude others from reverse engineering or independently discovering and producing that lifesaving drug.
Those are the stakes on the table people.
Remember, we can't let those .p2p dudes beat us to the punch!
Well before starting coding, let's make sure we have the protocol clearly written out.  For instance, are we going to take my suggestion of using unitary, non-fractional, bitdnscoins where 1 block == 1 bitdnscoin, instead of having the number of bitdnscoins per block start at 50 and half every few years?  Also, there is no need for fractional bitdnscoins since it doesn't make too much sense to own one-tenth of a domain name.  Keep in mind that people can use fiat money or even bitcoins when trading unitary bitdnscoins, incase they need to make a trade of two domain names with unequal subjective valuations.

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.

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.


Umm, each coin stand for one domain.

However, I don't think we need transaction fee. This is not bitcoin after all.

The incentive for 50 coins each block they generate ARE the transaction fee. Maybe?

I am worried about people who spam change to the DNS database?
Whats the general plan here? No reduction in names/block I assume? Won't this make the first blocks incredible valuable and later blocks less valuable as the goodness of remaining names declines? Maybe it should start really low (1?) and move up gradually to a stable amount (100?)?

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.

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.
At any rate, do we have enough information that's agreed so that the core hackers can develop right now?

Well before starting coding, let's make sure we have the protocol clearly written out.  For instance, are we going to take my suggestion of using unitary, non-fractional, bitdnscoins where 1 block == 1 bitdnscoin, instead of having the number of bitdnscoins per block start at 50 and half every few years?  Also, there is no need for fractional bitdnscoins since it doesn't make too much sense to own one-tenth of a domain name.  Keep in mind that people can use fiat money or even bitcoins when trading unitary bitdnscoins, incase they need to make a trade of two domain names with unequal subjective valuations.


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.

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.

Let me this straight: so we use fractional coins to prevent network spamming? Or is it bitcoin?
If we could dump this idea of another currency, I'd be all for it.  I just don't see how to do that though.

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.
Umm, each coin stand for one domain.

However, I don't think we need transaction fee. This is not bitcoin after all.

The incentive for 50 coins each block they generate ARE the transaction fee. Maybe?

I am worried about people who spam change to the DNS database?

Coin transfer transaction fees are also important here as well.  It allows the cost to be scaled with the size of the network and note that there will be coin transactions in this network as well.  There will be coin transfers independent of domain registrations as there will at least be transfers to and from exchanges and likely from miners to people wanting to make registrations directly.  There may also be other applications that use these coins that haven't been developed yet.

The "50 coins" they may collect are not going to be generated coins but rather fees collected from processing domain records, presuming they are getting 50 domain registrations in a single block.

The only role that generated coins play is strictly to bootstrap the exchanges.  You have to get the coins from somewhere, and giving them to miners is as good of a way as I can imagine without simply creating them all in the genesis block and then handing them out like the Bitcoin faucet until that feature runs out of coins.

Let me this straight: so we use fractional coins to prevent network spamming? Or is it bitcoin?

This is another currency that is essentially identical to Bitcoin, but with a few tweaks and miners more concentrated on working with domain records.  We could put this into the main Bitcoin protocol, but then we would have to change the Bitcoin miners as well.
This is another currency that is essentially identical to Bitcoin, but with a few tweaks and miners more concentrated on working with domain records.  We could put this into the main Bitcoin protocol, but then we would have to change the Bitcoin miners as well.

So if you spent a coin to register a domain, then it stay frozen until the domain expire?
If we could dump this idea of another currency, I'd be all for it.  I just don't see how to do that though.

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.

It could be put into the Bitcoin protocol itself, but keep in mind that would require changing the miners in a way that would also have to set up the rules for accepting and rejecting the domain registrations.  It also makes this a hack onto Bitcoins to be performing tasks that aren't financial transactions.  Some Bitcoin miners wouldn't be willing to participate and may end up rejecting blocks with the domain information buried in the block.  This gets back to burying the data into the transaction record itself, and then you get problems again trying to decide what blocks get rejected and which ones don't.  On top of all that, it makes this a one-time only change and is not extensible to incorporating other ideas that may be similar.

Really, the only way this is going to work is for a completely separate block chain for the domain data.  That implies a second currency.

If we could get some hooks into Bitcoin that would open up some additional data types which could be put into the Merkle tree for the blocks and have some way for a miner to bootstrap verification rules for those additional types, perhaps we could put it into the main Bitcoin chain as well.  We would also have to come up with some sort of scripting language that would be used to "verify" those extra datablocks sort of like the current scripting language being used to verify coin transactions.  Would that be worth some extra effort to make a "generic solution" that could be added to Bitcoin for this and other similar kinds of data types to be added to Bitcoin?

It would require a major network-wide upgrade regardless.  Coins wouldn't be lost, but older clients would have to be abandoned with an update of that nature.  Miners would receive any transaction fees for simply following those rules.

Another question here, and this is perhaps the most important:  Would Satoshi be interested in putting in these kind of extra hooks into Bitcoin?  By creating a separate currency that is essentially a fork of Bitcoin for a specific purpose, Satoshi's blessing is irrelevant other than coordinating the effort of the two projects to relay problems identified in the two efforts and to make sure fatal problems get updated in bother projects.  If we decide to put the data (even as a separate data structure) into Bitcoin, Satoshi needs to be in the middle of all of this discussion.  Bitcoin, as it currently exists, really doesn't deal with this kind of issue.

This is another currency that is essentially identical to Bitcoin, but with a few tweaks and miners more concentrated on working with domain records.  We could put this into the main Bitcoin protocol, but then we would have to change the Bitcoin miners as well.

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

No, that coin is received by the miner processing the transactions and handled just like coin transaction fees are right now in Bitcoin.

No, that coin is received by the miner processing the transactions and handled just like coin transaction fees are right now in Bitcoin.

So domain name generation are limited by the velocity of miners spending, but then they have to generate a block to get the coin.
RHorning...thank you for the very detailed responses.  It's been helpful that you are so willing to lay down your logic so that some of us can play "catch up" as we wrap our heads around this project.

Quote
Satoshi needs to be in the middle of all of this discussion.  Bitcoin, as it currently exists, really doesn't deal with this kind of issue.
I completely agree here.  Even though his "blessing" is not necessary, it could potentially save a lot of time and effort if we can at least get Satoshi involved in the discussion.  Does anyone here have enough of a working relationship with Satoshi? I know he is quite evasive these days.

I completely agree here.  Even though his "blessing" is not necessary, it could potentially save a lot of time and effort if we can at least get Satoshi involved in the discussion.  Does anyone here have enough of a working relationship with Satoshi? I know he is quite evasive these days.

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.
We need a wiki real bad so Rhorning can write down what he means.

RRRRRRRRRRRRRibuck?
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.  Smiley
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.  Smiley

An interesting thread related to this can be found here: http://bitcointalk.org/index.php?topic=2124.0

Theymos has been discussing how to put miscellaneous data into the transaction blocks themselves, but there are dangers to doing that.  It also shows some incredibly strong resistance to "tweaking" Bitcion itself as a software package to permitting this kind of activity, which seems to me as coming from at least a source that would end up killing any attempt to put a patch into Bitcoin to permit data inclusion for something other than the "stealth" method with transactions.

While the suggestion that Git itself ought to be sufficient for cryptographic timestamping and cryptographic data storage (that is interesting by itself... something I haven't thought about), I don't know enough about Git to say much about it at all in terms of its distributed nature.

I firmly believe you should "pay your own freight" so far as anything which costs others to do, which is why I think this proposal is incredibly useful.  There are costs associated with domain name registration and data storage, and they aren't trivial expenses either.  The concept of Bitcions enables those costs to be borne by those who use the service.  I tried to explore this idea further on this thread:  http://bitcointalk.org/index.php?topic=1764.0

This is indeed a political idea here too, which is where perhaps it is getting some resistance as well.  The idea could be summed up with the concept that "you get what you pay for".  Places like Source Forge offer their "services" for free, but there are hidden costs including being tied to other outside interests.... mainly the advertisers and those who are paying for the "service".  With what we are proposing for BitDNS/Domain Chain is that the service is going to be focused upon those who are paying for the service.... which is those who are making the registrations.  They have the most to lose if this project falls apart.  If the registrants aren't happy with the service, fees are going to go down and the DCC is going to collapse as a currency.  That in turn is going to cause developers to be very strongly focused upon meeting the needs of that community.

The other aspect which is really interesting here is that the process of becoming a "registrar" has a very low barrier to entry.  I'm sure many people would love to have had the chance to do something like being BigDaddy or Verisign in terms of processing domain registrations and receiving the fees for doing that.  Now the chance to perform that sort of "business" at least on a part time basis is at least possible.  No single person or even central organization is going to be receiving the fees but rather a "community" that is open to newcomers and even people with modest technical skills.

I've also seen complaints that "open source software" doesn't pay.  Bitcoin can change that model, including doing things like we are talking about here with the DomainCoin system.  Not only can a bounty system be set up for integrating a specific feature into the system, but the developer can also have a continuing source of income afterward.  BTW, in deference to Kiba, the license itself is immaterial here too and can simply be thrown into the public domain, even though I think that copyleft licenses tend to offer much stronger protections against idiots who would attempt to mess with you in the legal system.  You may want to avoid the judicial system, but sometimes it comes and bites you hard even if you are active in trying to stay out of its reach.  Time is really the one resource that anybody has to sell when you finally get down to the gritty details of economics, and it takes time to be a developer to create projects like this.  Also, even simply maintaining the software afterward takes time and effort, fixing bugs that show up and perhaps putting in tweaks.

Anyway, enough of the issue with the overhead costs.  I am afraid that this is going to effectively split or fork the Bitcoin network, and that isn't a good thing either.  I want to work with the Bitcoin community, but if they won't have us, we may have to move on.  Threats to Bitcoin will still be relevant and I'm not going to leave completely in a huff, but as a separate application it will be essentially a fork of Bitcoin if we proceed with the path I've suggested in terms of a completely separate coin chain and currency.  It might be interesting so far as a social experiment is concerned to see which way is better and which "coin" is going to be more accepted in the long run.  I am challenging some of Satoshi's assumptions here too, but not overly so.  Two very similar project with slightly different goals but which also support each other might be beneficial to each other as well, especially as there is going to be a huge amount of common ground to work with.
Anyway, I have registered domainchain.org, in case people like it.

Care to stick a wiki up on there?

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.

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.

We won't make fun of you.

On my Bitcoiner honor!
Trying to predict the exact numbers required is equal to central economic planning, and pointless.
<--- 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?
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.

I'm always interested in alternatives.  Take your time though, and I'd like to see how it is different than what we've proposed here.
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.
The DomainChains payloads could look like this:

Registration (with and without nameservers):

Code:
DomainChains my-domain.tld
DomainChains my-domain.tld 201.73.213.92 98.252.10.34

Changes of registration details use the same payloads, but the payloads must be sent with a coin that is already associated with the domain name.

To drop a registration and turn the bitcoin back into a spendable coin, send this payload with a coin associated with the domain name:

Code:
DomainChains drop

Obviously this is just to illustrate the idea. The concrete syntax may differ.
Ribuck: I believed that is a brilliant hack. We finally have intrinsic value for bitcoin!
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.

The #1 disadvantage:  My complaint about shoving useless and meaningless data into the transaction block.  It would work, but there may be changes to Bitcoin to get rid of this "feature" as it may be seen as an attack rather than something useful for the project.  I am not alone with this attitude.  It also opens a pandora's box of problems down the line as domain information is hardly going to be the only thing to put into transaction chains in this fashion.  Expect more resistance if you actually get a client to accomplish this task.  Bitcion is not bittorrent. 

Transactions really ought to be about bitcion transfers from one person to another, and the purpose of the script is to permit flexibility in terms of the method used to secure that transfer.  It may be possible that the nature of the scripting language itself may be changed to specifically exclude a "payload" being used in this fashion.

Another huge disadvantage is that this really isn't any sort of system for registering domains in a secure fashion.  You might put into the "payload" any sort of in here, but there is no reason for anything or anybody to recognize this data.  Instead you would likely need some other application which is reading all of the transaction and either "accepting" or "rejecting" the domain registrations.  Such acceptance or rejection would be completely arbitrary and there would not be any sort of clear "ownership" of any sort of domain, or any sort of consensus as to which domain record takes precedence in the actual domain usage system (aka the DNS end of this registration system).  Two people trying to register the same domain simultaneously would have no real means to identify who actually has the domain with this system.

I admit that some of this could be worked out simply by saying that the first "registration" takes precedence, including in the same block.  Other systems could be set up (likely as an external app) scanning transactions and pulling out domain records that would "apply" the rules which identify a valid transaction.  Competing software could put in different "rules" for the same data as well and put different domains as valid.

It was also pointed out that transaction records can be dropped.  For instance when you send a coin like this:

Generation Block -- > Alice  -- > Bob -- > Charlie

Since all that is necessary is to simply keep track of where the coin is currently at, all you have left is this:

Generation Block --> Charlie

And all of the previous transactions are ignored and "forgotten".  If your registration record is in one of those other transaction blocks, it is then lost.

This could work.  It would be real nice to see what Satoshi thinks of an "abuse" of the transaction scripts in this fashion.  My own preference is to permit additional kinds of blocks as a separate payload that is linked into Bitcoins, where some clients may only read them to verify the block hash and then dump the data and other clients could keep the data for their own purpose.

BTW, one advantage to going this route is that it would not require any reboot of the network

I do have my reservations about the direction this is going, but I'm willing to have an open mind about it.
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.

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.

Quote
If they receive coins that are associated with a domain name registration they will see them as coins.

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.
RHorning,

The one objection of yours that I can't address is the one about "shoving useless data into the transaction block". This is something for others to decide, and at this time I would respect whatever Satoshi said. But we should not be concerned about "opening the pandora's box" because the box is already open and lots of people are going to look inside in the future. That "problem" (if it is a problem) is for the owners of Pandora's Block Chain to decide.

What I suggest we do is to try out DomainChain on the test network, and see what bitcoiners think of it when it's able to be experimented with. I'm sure we'll get feedback on whether or not it's welcome in the live block chain.

Transactions really ought to be about bitcion transfers from one person to another, and the purpose of the script is to permit flexibility in terms of the method used to secure that transfer.  It may be possible that the nature of the scripting language itself may be changed to specifically exclude a "payload" being used in this fashion.

There's nothing forcing generators to include bitcoin payments that piggyback DomainChain data, but why wouldn't generators want to include them if the transaction fee is high enough to cover the extra costs plus a profit margin?

Quote
Another huge disadvantage is that this really isn't any sort of system for registering domains in a secure fashion.  You might put into the "payload" any sort of in here, but there is no reason for anything or anybody to recognize this data.

That's true, but it's no different from Bitcoin itself. The block chain only has value because a majority of users are prepared to interpret it in a certain way, according to certain rules. If that works well enough for coins, it will work well enough for domain names.

Although we need generators to include the DomainChain transaction data, we don't need the average person's bitcoin client to recognise that data, or act on it in any way. Only the resolver software, and the modified clients used by those who want to register domain names, need to recognize the extra data.

Quote
Two people trying to register the same domain simultaneously would have no real means to identify who actually has the domain with this system.

The first to get their registration into the block chain gets the domain. Ideally the generator who processes these transactions will reject the invalid one. Failing that, the resolver will certainly locate the valid one.

Quote
It was also pointed out that transaction records can be dropped.  For instance when you send a coin like this:

Generation Block -- > Alice  -- > Bob -- > Charlie

Since all that is necessary is to simply keep track of where the coin is currently at, all you have left is this:

Generation Block --> Charlie

And all of the previous transactions are ignored and "forgotten".  If your registration record is in one of those other transaction blocks, it is then lost.

I don't think there is any problem here. The registration data is re-sent if the domain name is transferred to someone else by spending the coin. All we care about is who has the current registration. We don't care about the history of the domain name.

Quote
This could work.

Let's do the "simplest thing that could possibly work" for the proof of concept. This seems to be it. If people like it, they will accept DomainChain into the Bitcoin block chain. If they don't like it, we go to plan B.
I haven't read your spec yet, but...

...Some sort of expiration is required..

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

Quote
Normal clients will ignore such transactions.

That's also not problematic. If someone wants to work with domain names, they will use a domain-enabled client.
Wow, after a first readthrough of the spec by Theymos and Nanotube I am astonished by the similarities. And their spec is so much further developed. This is excellent!

I will look through it in detail tomorrow as I've already spent way too much time on this today.
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.
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.


Speculation is natural; even healthy.
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.

What do you suggest is a better way to decide who gets sex.domain?
Do we have a consensus on nanotube's proposal? Any objection?
Do we have a consensus on nanotube's proposal? Any objection?

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

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

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.

Quote
If they receive coins that are associated with a domain name registration they will see them as coins.

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 read your draft bitcoin DNS spec Nanotube and theymous...very interesting.  And it's fascinating that ribuck also came up with a very similar design independently.  I like the idea of piggybacking bitDNS on top of bitcoin.  However, putting the domain name registration requests inside of bitcoin transactions as a message does cause concern about compatibility, should the bitcoin developers decide to remove that feature in the future for security or other reasons.  I would suggest, maybe is it possible to have the domain name registration request message be not included directly inside the bitcoin transaction, and instead use some cryptogrphic properties of the block be used to index to a bitcoin registration request message?  For example, somehow have the hash of the transaction/block be directly indexable to a DNS registration request?  In which case, the information about the sender and receiver of the DNS registration request would be embedded in the hash such that it proves that address X is the owner of that DNS registration request?  Thus the bandwidth/traffic of domain name table info/requests would only be paid by those clients who are engaged in domain name registration.


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.

Expiration fixes the "problem" of domain names being lost for eternity.  My question is, what are the relative benifits/disadvantages of using a block count based expiration (e.g. 52,000 blocks) versus a time-based expiration (e.g. 1 year)?  I would think a time-based expiration would make more sense for average people to understand, since they will know that after a certain fixed period of time, they will need to renew their domain, and can set that in their calendar, instead of being completely unaware if the block count reaches some number?  Never mind...I get it...52,000 blocks is approximately the number of blocks that should be produced in 1-year time assuming a rate of 1 block/10 minutes is maintained.


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.

Speculation is natural; even healthy.

What Kiba said.  Speculation is a part of any world where there are limited resources.  Speculation allows the market to come to a subjective valuation of the unknown value of such resources.  The speculator takes a risk by buying domains (even if it is just an opportunity cost), and that risk is entirely held by the speculator.


I read your draft bitcoin DNS spec Nanotube and theymous...very interesting.  And it's fascinating that ribuck also came up with a very similar design independently.


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

I read your draft bitcoin DNS spec Nanotube and theymous...very interesting.  And it's fascinating that ribuck also came up with a very similar design independently.


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

Oh yes, I am perfectly aware.  In fact, the prevalence of simultaneous inventions is a strong argument against the necessity of a patent system to "reward" inventors with monopoly.
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.

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.


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.
What if the consensus is that the Bitcoin network should not be used to support DNS (as I expect)? Then the only alternative is to go forward with a parallel but independent block chain, creating a second currency. Are we ok with that?

I have a couple questions about http://privwiki.dreamhosters.com/wiki/Bitcoin_DNS_System_Proposal

When you register a name, there is a fee to a DNS server. In the doc, this appears like a Bitcoin transaction fee. The first example shows 10.01 input and 0.01 output, so the 10.00 difference would be a transaction fee. But tx fees go to miners. Is it assumed that miners are the same as DNS servers? Or would there be a 2nd output, a fee to a particular DNS server to get it to register you, in addition to a tx fee to the miner?

Are you allowing name changes of the main part of the domain? Like elephantfood.bitdns can change to dogfood.bitdns (if it is available)? Or is this disallowed, in which case, exactly which kinds of name changes are allowed?

Would anyone who wants be able to run one of these special DNS servers, or do you envision there being relatively few of these?

Thanks -
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?


Is there a way to reserve the top 1000 domains at Alexa ? 

This is a very good and important idea, we should set-up some 'domain trust' where well established domains will be protected until they are claimed (at a good fee) by a verified owner.

Maybe we could have a 'time-lock' of about a week or so where you claim a domain, and if half of the network decides that that domain should be in the trust they can deny that request.  Once the network is more established the minimum time-lock can be reduced.
Maybe we could have a 'time-lock' of about a week or so where you claim a domain, and if half of the network decides that that domain should be in the trust they can deny that request.  Once the network is more established the minimum time-lock can be reduced.

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.
Maybe we could have a 'time-lock' of about a week or so where you claim a domain, and if half of the network decides that that domain should be in the trust they can deny that request.  Once the network is more established the minimum time-lock can be reduced.

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.

I think the delay in releasing the client would be enough for the top 1000 to be locked in
 

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.

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.

Quote
Is this basically "filtering out spamsites"

Exactly.

What if the consensus is that the Bitcoin network should not be used to support DNS (as I expect)? Then the only alternative is to go forward with a parallel but independent block chain, creating a second currency. Are we ok with that?

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

Quote
Are you allowing name changes of the main part of the domain? Like elephantfood.bitdns can change to dogfood.bitdns (if it is available)? Or is this disallowed, in which case, exactly which kinds of name changes are allowed?

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.

Quote
Would anyone who wants be able to run one of these special DNS servers, or do you envision there being relatively few of these?

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.
I think reserving the top 1000 alexa domains by seeding the genesis block with those "registrations" would be an excellent show of good faith towards the world at large.  A council of bitcoin "elders" could be elected to hold the private keys to those initial 1000 domains, and turn them over when the time comes (for a fee, which will go towards bitcoin/domainchain community funds). 
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?
re-read nanotube's+theymos's proposal! Sound Good  Grin
+1
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?)

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

Very strange to form a foundation for DomainChain before we form an organization for Bitcoin.
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)?

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

just to throw in a little bit of optimism here Smiley, if the piratebay dot-p2p guys 'see the light' than this system is better than theirs, and decide to get behind it, this has a pretty good chance of getting wider adoption. Smiley
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.

just to throw in a little bit of optimism here Smiley, if the piratebay dot-p2p guys 'see the light' than this system is better than theirs, and decide to get behind it, this has a pretty good chance of getting wider adoption. Smiley

We need a proof of concept.  Smiley

Yes, coding need to be done soon.


Repeating ad nauseum:

Speed is of the essence.

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

Very strange to form a foundation for DomainChain before we form an organization for Bitcoin.

Ha.  Good point.  I was thinking the two could potentially operate under the same umbrella.  We'll see though.
Referencing this thread http://bitcointalk.org/index.php?topic=2129.msg27968#msg27968

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




BitDns is not bitcoin.  Smiley

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

Lets get it started in  here..... Cheesy







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

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.

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

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

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

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

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

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

This is why I was trying to put together some sort of proof of work chain for data of this nature too, in part to put some scarcity into creating domain records.
I've now studied the theymos/nanotube spec in more depth, and my questions and comments are starting to flow.

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.

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
Is there a way to reserve the top 1000 domains at Alexa ?

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

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

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

We really don't want the DomainChain system saying that it will "protect" 1000 names but "refuse to protect" all the rest.
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.
My concern is that there would be a rush to grab hot domains.

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

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

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

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

I'm not convinced that a registration rush needs to avoided, but technical measures can be used to avoid a rush if it is desired to do so.
I suggest that we exclude all existing top level domains from DomainChain registration. So no-one will be able to register google.com through this system. They could, however, register google.domain but they would probably have to fight with Google in court under trademark law.

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

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

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

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

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

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

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

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

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

Quote
When in doubt, remove human elements. Adopt certainty of computer software code over uncertainty of judges. Complicated rules invite gaming and abuse.

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

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

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

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

You misunderstood me. I didn't suggest anything like voting or whatever.
The theymos/nanotube design is much more heavyweight than my design, in terms of how much data it stores in the block chain.

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

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

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

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

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

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

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

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

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

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

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

Maybe I'm missing something fundamental here.  I sure hope so.  It seems sort of silly for somebody to set up a "domain name server" on their home computer and essentially sit back and earn bitcoins simply by being connected to the internet alone (no proof of work), receiving payments for domain registrations that are never used.  That sounds like a neat gig to get into, but I don't understand what "service" they are providing to the community for doing that or why the fees ought to be paid yet other domain servers who are clearly being used by thousands of computers are going to be considered "equal" and receive roughly the same amount of money?
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
Time based expiry date rather than block based expiration system.
Well yes, time based expiry is better for the customer, but the motivation for block-based expiry in the theymos/nanotube design seems to be that the transaction records are vulnerable to block chain compaction, which might happen after a specific number of blocks.

Of course, there is nothing that forces the providers of domain name servers to compact their copy of the chains, but then a new entrant into the business can't get all the data unless they can lay their hands on one of these uncompacted block chains.
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.
DomainChain wiki is here:
http://domainchain.org/wiki/doku.php?id=start

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

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

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.

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.

Quote
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?

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

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

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

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

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

Quote
Any additional fees being thrown with the "registration" is not going to anybody actually putting effort in terms of running the domain server or doing registrations.

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.

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

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.

Quote
I'm starting to think that an everlasting registration really is the way to go.

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.

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

Quote
When in doubt, remove human elements. Adopt certainty of computer software code over uncertainty of judges. Complicated rules invite gaming and abuse.

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

Kiba is wise beyond his years!

Anyway, I've been thinking outside the box a little bit...and wondering maybe to scratch the whole idea of domain names.  I'm thinking somehow be able to associate a bitcoin address, or maybe some hash of a transaction, with a location on the internet somehow.  Also, it maybe possible to sidestep away from the concept of domain names considering that nowadays search engine technology has improved so much.

Wouldn't it be cool to associate a bitcoin address directly with a webpage/internet location for that product/resource/whatever that is being sold with that bitcoin address?  Anyway, let me think about this some more and write out a concrete proposal.  Obviously, this is sortof off topic from this thread...
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?
Miners are rejecting the [edit]isStandard.
Miners are rejecting the same.

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.

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.

This is like that, too. In this system, you're always registering a TLD.


So what would prevent me from registering the domain jackass.theymos.btc? 
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.
Hey guys.  I'm really surprised that my post received so much attention!

And, I'm glad that BitDNS (or domain chain?) has generated this level excitement.

However, I urge you to re-read my initial post, as I feel that original formulation of the idea solves many of the problems you are currently discussing, including the (1) business-plan problem and (2) the bitcoin integration problem.  There is also a third problem which hasn't been brought up by anyone thus far, which is (3) the problem of dividing the CPU pool among multiple block chains.

In the original formulation, bitDNS is simply an example of a possible generalization of bitcoin.  It should be possible to dream up many such applications requiring block chains for systems that need some kind of quorum.

We should be discussing BitX, the general block chain that in the future will support both bitcoin and bitDNS.  It neatly solves (1) and (2), as well as the biggest problem in my view, the CPU pool division problem.

BitX is essentially an uber-chain which has hashes of app (bitcoin, bitDNS, ...) payloads as its payload.  This way a bitDNS server will only need to download its own app payload without worrying about bitcoin's payload and vice-versa.  As the number of bit-apps increase, this problem of smushing them all into bitcoin will only get worse, and (2) becomes a big problem that has to be solved for each app.  BitX neatly deals with applications liberally, leaving it completely up to them to decide their own protocols but forming a valuable backbone for them.

With bitcoin and bitDNS as separate apps running on BitX, (1) is easily solved with third-party escrows.  Escrowing is a big problem, and perhaps unsolveable, with respect to bitcoin and USD or PPUSD transactions, but it is incredibly reliable when executed between two bitapps.  A trusted escrow can receive both transactions, verify them mechanically and automatically release the assets when both transactions are properly verified.

Note that this also frees bitDNS from bitcoin baggage when bitMoney overtakes bitcoin as the most popular bit-currency.  I believe in fact that bitcoin in its present form will necessarily be overtaken due to problem (3).

The big deal: the CPU pool division problem.  CPU division will occur when bitcoin can't or won't support bit-application bitFoo.  This may occur with bitDNS, or it may occur later, but I think it will occur at some point.

Every miner for bitFoo will be one less miner for bitcoin and vice-versa.  Both of these systems will be twice as susceptible to attack (if they have roughly equal CPU pools), and the problem multiplies as the number of bit-apps and their block chains increases.

BitX cleanly solves this by having every bit-app generate on the same block chain, the BitX chain.  They weave their own block chains within the uber-chain, and unwittingly protect eachother from attack.  It also greatly speeds adoption of any given bit-app; the BitX miners are already generating bitcoins, so why not generate bitDNS names as well?  There is no cost to the miner, and who knows, this new-fangled bitDNS thing might actually take off someday?

Even if the demerits of separate block chains can be mitigated, the merits of a unified chain cannot be overstated in my view.

Finally, I hope that the name will remain BitDNS or BitNames, keeping the trend of revolutionary projects like bittorrent and bitcoin.  There isn't any reason to call it domainchain if it is built upon BitX in any case, because the name registration aspect will be an implementation on top of the BitX chain rather than a full implementation with its own chain.

This separation of concerns makes BitX and bitDNS/bitcoin simple enough that I feel I can implement them myself if necessary, although slowly, in my spare time.  I'm looking forward to some bit fun!

Thanks guys!
So what would prevent me from registering the domain jackass.theymos.btc? 

Nothing. But hopefully servers will ignore tricks like that.

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.

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.
We should be discussing BitX, the general block chain that in the future will support both bitcoin and bitDNS.  It neatly solves (1) and (2), as well as the biggest problem in my view, the CPU pool division problem.

BitX is essentially an uber-chain which has hashes of app (bitcoin, bitDNS, ...) payloads as its payload.

Responded, in this new thread.
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.
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.


Bigger stuff mean higher priority. Bitcoin users who didn't load the bitcoin chain data with lards are left with lower priority.
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?
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?

Not me! I think that nanotube's+theymos's proposal has real elegance! Creating another chain is all good and well, but the current chain can be used for many things, might as well maximize it's potential.

http://privwiki.dreamhosters.com/wiki/Bitcoin_DNS_System_Proposal
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 still hear talking.  Smiley
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:

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.
Maybe we need to stop using domain names entirely
If you try to redesign everything, you will end up successfully redesigning nothing.

The way for a small group to achieve success is to design a drop-in-replacement that's significantly better in one important way.

... considering that the latest bitcoin version update removes the ability to include extra text in transactions ...

Not so. The latest version won't include transactions with extra text in blocks that it generates itself, but it accepts blocks generated by others that contain transactions with extra text.
Maybe we need to stop using domain names entirely
If you try to redesign everything, you will end up successfully redesigning nothing.

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.

The way for a small group to achieve success is to design a drop-in-replacement that's significantly better in one important way.

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

... considering that the latest bitcoin version update removes the ability to include extra text in transactions ...

Not so. The latest version won't include transactions with extra text in blocks that it generates itself, but it accepts blocks generated by others that contain transactions with extra text.

Ok, thanks for clarifying.
Of likely interest:

"Gov't crackdown spurs initiatives to route around DNS"
http://www.itworld.com/legal/129947/net-censorship-dns-alternative
Our code repository is non-existent and we're still debating the best route for DomainChain/BitDNS.

* kiba is anxious.
I think it would be possible for BitDNS to be a completely separate network and separate block chain, yet share CPU power with Bitcoin.  The only overlap is to make it so miners can search for proof-of-work for both networks simultaneously.

The networks wouldn't need any coordination.  Miners would subscribe to both networks in parallel.  They would scan SHA such that if they get a hit, they potentially solve both at once.  A solution may be for just one of the networks if one network has a lower difficulty.

I think an external miner could call getwork on both programs and combine the work.  Maybe call Bitcoin, get work from it, hand it to BitDNS getwork to combine into a combined work.

Instead of fragmentation, networks share and augment each other's total CPU power.  This would solve the problem that if there are multiple networks, they are a danger to each other if the available CPU power gangs up on one.  Instead, all networks in the world would share combined CPU power, increasing the total strength.  It would make it easier for small networks to get started by tapping into a ready base of miners.
Kiba, I wrote this response before Satoshi posted above. I'll need some time to understand Satoshi's post.

* kiba is anxious.

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.
I think it would be possible for BitDNS to be a completely separate network and separate block chain, yet share CPU power with Bitcoin.  The only overlap is to make it so miners can search for proof-of-work for both networks simultaneously.

sounds excellent in theory...

Quote
The networks wouldn't need any coordination.  Miners would subscribe to both networks in parallel.  They would scan SHA such that if they get a hit, they potentially solve both at once.  A solution may be for just one of the networks if one network has a lower difficulty.

I think an external miner could call getwork on both programs and combine the work.  Maybe call Bitcoin, get work from it, hand it to BitDNS getwork to combine into a combined work.

seems that the miner would have to basically do "extra work". and if there's no reward from the bitdns mining from the extra work (which of course, slows down the main bitcoin work), what would be a miner's incentive to include bitdns (and whatever other side chains) ?

very curious to hear your further thoughts on this. Smiley
I think it would be possible for BitDNS to be a completely separate network and separate block chain, yet share CPU power with Bitcoin.  The only overlap is to make it so miners can search for proof-of-work for both networks simultaneously.

The networks wouldn't need any coordination.  Miners would subscribe to both networks in parallel.  They would scan SHA such that if they get a hit, they potentially solve both at once.  A solution may be for just one of the networks if one network has a lower difficulty.

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'...
seems that the miner would have to basically do "extra work". and if there's no reward from the bitdns mining from the extra work (which of course, slows down the main bitcoin work), what would be a miner's incentive to include bitdns (and whatever other side chains) ?

Same incentive as the main chain -- you get paid.
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.

seems that the miner would have to basically do "extra work". and if there's no reward from the bitdns mining from the extra work (which of course, slows down the main bitcoin work), what would be a miner's incentive to include bitdns (and whatever other side chains) ?

Same incentive as the main chain -- you get paid.

but if you get paid just as much by mining pure bitcoin without the side hashing...
seems that the miner would have to basically do "extra work". and if there's no reward from the bitdns mining from the extra work (which of course, slows down the main bitcoin work), what would be a miner's incentive to include bitdns (and whatever other side chains) ?
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 agree with satoshi's idea. It seems like the best of both worlds.

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

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.
Satoshi's idea eliminates the need for BitX. Alternative chains can be made without splitting CPU power.

Our version of BitDNS would never use its own chain, though, because creating domains should not be tied to a proof-of-work, and we therefore have no generation incentive.

120 bytes with an OP_CHECKSIG is enough for our proposal, I think.
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.



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:

I agree with jgarzik, the chain should not be used as storage.

If you want to create your own proof-of-work chain but would like to avoid double-work, you could make your parallel chain "dependent" on the bitcoin chain. Like, for creating a block in a dependent chain, you first have to create a block on the bitcoin chain and then use the private key you used to create that block to sign your new block on the dependent chain.

I think I've asked this question a number of times getting the run around.  Perhaps I'll be more clear with this example as proposed by Caveden:

If you create this alternate "proof of work" chain (presumably to keep this junk out of the main Bitcoin financial traffic), how can you get those who are performing this work to be paid in Bitcions, based upon some fee system agreed to by the network running that proof of work chain?

If simply running that network is its own reward, it doesn't matter, but if there is going to be a fee involved for adding information into that proof of work chain, I don't see how that can be done without actually putting those block into the main Bitcoin chain, or setting up a completely parallel currency to Bitcoins.

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.
The incentive is to get the rewards from the extra side chains also for the same work.

You don't really get any extra reward. Either you are collecting generation fees + transaction fees from the Bitcoin side, plus some profits from the Domain Name side. Or, everything is in the Bitcoin block and you earn the same total profits, but all from the Bitcoin side (due to the additional Domain Name transaction fees on the Bitcoin side).
[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.
Introduction of BitX reduces the likelihood that will be invented a way to cut the chain?

Or is it generally no longer considered a necessity?
If you currently generate 50 BTC per week, now you could get 50 BTC and some domain names too.
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.

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.

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

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.
I have not yet read all the posts but I have a few thoughts:

Need to divide the creation of a domain name and change of authoritative servers for him:
First is the expenditure limited domain name space and must be expensive.
Second only settings that can be changed frequently and should be generated in large quantities and cost little.

Names should be allowed to specify the relative and absolute value (with dot at the end). Absolute in case the system will supplement or replace the main in the conventional TLD.

Also names should be allowed to specify 3rd or more level domain names too.
I suggest tahoe lafs if you are looking for a database for storage.

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.

2. "powerdns" can work with plugins and with bind9 configs by default. We can write a plugin for it.
... 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 ... 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

That doesn't really reflect how it works. If there is a chain split, eventually the network will settle on one of the chains. The generator that mined the block in the "winning" chain gets the transaction fee.

There is no "irreversible" payment to the generator in the "losing" chain. Well, in a sense it is irreversible but as they can only spend it in the losing chain it's not much use to them.
"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.
I have fleshed out the DomainChain spec quite a bit more:
http://domainchain.org/wiki/doku.php?id=start

Also names should be allowed to specify 3rd or more level domain names too.

Yep, that's in the spec. But it's only useful if you know that someone is going to serve them. For example, the owner of some.domain might announce that they will serve any subdomain that people register of the form something.some.domain
"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.
... 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 ... 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

That doesn't really reflect how it works. If there is a chain split, eventually the network will settle on one of the chains. The generator that mined the block in the "winning" chain gets the transaction fee.

There is no "irreversible" payment to the generator in the "losing" chain. Well, in a sense it is irreversible but as they can only spend it in the losing chain it's not much use to them.

I think you got the context mixed up here.  The reason why the payment is irreversible is because it is derived from a completely different chain.  If there is a chain split in the domain registry chain, the fees spent as bitcoins (going into a completely different system) will have already been spent for those block in the "losing" chain.  Transaction going into that "losing block" are essentially a wasted effort.

I'm suggesting that somebody simply sets up enough of the protocol to be able to appear to be following the domain processing rules so as to appear "legit", but they only have to make an appearance to get a block accepted.  Perhaps they even get some blocks accepted, but then start to make up stuff or somebody attempts to register an existing name (as a scammer claiming they can hijack a domain from somebody else or however).  If there is any reason why the rest of the network doesn't accept the block, for any reason, all of the fees collected by that "miner" or "registrar" would still be collected by that scammer regardless of if it actually gets into the chain.

On the other hand, if the block being "authenticated" is a part of the same chain that creates the currency, this isn't a problem.  If the blocks get rejected by the network, any fees (set up in a system like how transaction fees are done with Bitcoin) are also similarly rejected by the network too.  Any chain splits remove any fees paid to "losing" blocks and therefore can be ignored.  This is why the authentication must happen in the same chain as the transaction.  Either that is in Bitcoin or a parallel currency, but if it is with Bitcoin, the authentication must happen within the Bitcoin network too.  Otherwise, there isn't a way to get payment to the miner with an outside currency that is similar to Bitcoin without fraud and a significant attack on the payment system.  This is fraud because a service is being claimed and paid for, but the service isn't being rendered.

Hacking the data into Bitcoin transactions does not perform authentication of the data and pushes that need somewhere else.  In effect, it permits "double spending" of a domain name or allocation of a domain name to more than one person with ambiguity over who actually owns that domain.
The reason why the payment is irreversible is because it is derived from a completely different chain.

Got you now. Yes, keeping two chains synchronised is fraught with difficulty.
Piling every proof-of-work quorum system in the world into one dataset doesn't scale.

Bitcoin and BitDNS can be used separately.  Users shouldn't have to download all of both to use one or the other.  BitDNS users may not want to download everything the next several unrelated networks decide to pile in either.

The networks need to have separate fates.  BitDNS users might be completely liberal about adding any large data features since relatively few domain registrars are needed, while Bitcoin users might get increasingly tyrannical about limiting the size of the chain so it's easy for lots of users and small devices.

Fears about securely buying domains with Bitcoins are a red herring.  It's easy to trade Bitcoins for other non-repudiable commodities.

If you're still worried about it, it's cryptographically possible to make a risk free trade.  The two parties would set up transactions on both sides such that when they both sign the transactions, the second signer's signature triggers the release of both.  The second signer can't release one without releasing the other.
Piling every proof-of-work quorum system in the world into one dataset doesn't scale.

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.
Fears about securely buying domains with Bitcoins are a red herring.  It's easy to trade Bitcoins for other non-repudiable commodities.

I dont see how this was a red herring.  Unfortuantely if you use a Bitcoin-like system of authentication of a transaction, you can't conduct that transaction in Bitcoins, at least for authentication transaction fees.

Quote
If you're still worried about it, it's cryptographically possible to make a risk free trade.  The two parties would set up transactions on both sides such that when they both sign the transactions, the second signer's signature triggers the release of both.  The second signer can't release one without releasing the other.

I'm really curious about how you make this sort of transaction risk-free without having it integral to Bitcoin as some sort of authentication mechanism.

One thing that really makes this nasty is that the "miner" is unknown until the block is added into an authentication hash tree.  You don't have the two key release mechanism because one of the parties in the transaction is unknown until after the hash is successfully put in, and even that is conditional.

It makes it much more secure and coincidentally easier to scale to treat it as a simple exchange between two currencies, something that happens entirely outside of the system as evidenced by the various exchanges that already exist between Bitcoin and other currencies.  BTW, I agree that Bitcoin or any other monolithic application should not be the ultimate repository of all human knowledge and interaction, as I don't think any sort of system can possibly scale to that size.  I'm not even sure TCP/IP itself can scale to that size.

This is much of what Jgarzik has said that it is unworkable, but going from a different perspective.  The problem is that everybody is trying to get these fees paid for with bitcoins, and I don't think that can be done at all, at least directly.  As an indirect mechanism, perhaps, such as a floating currency that isn't locked down until after the exchange takes place.

BTW, the idea of a "locking exchange" would be a fantastic idea for a peer-to-peer currency exchange network, particularly for electronic currencies like Bitcoin or Liberty Reserve.  I just don't see how you can put any sort of authentication transaction fee in a block that is denominated by a currency other than the currency represented by that block itself.
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.
Satoshi, are you endorsing the idea that additional block chains would each create their own flavor of coins, which would trade with bitcoins on exchanges? These chain-specific coins would be used to reward miners on those chains, and to purchase some kinds of rights or privileges within the domain of that 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.
Satoshi, are you endorsing the idea that additional block chains would each create their own flavor of coins, which would trade with bitcoins on exchanges? These chain-specific coins would be used to reward miners on those chains, and to purchase some kinds of rights or privileges within the domain of that chain?

It might be coins, but it doesn't have to be.  Your reward could be a portion of namespace, ie. the domains themselves.

The possibilities are endless.

Bitcoin rewards you, essentially, with a piece of [digital] property.
It might be coins, but it doesn't have to be.  Your reward could be a portion of namespace, ie. the domains themselves.

The possibilities are endless.

Bitcoin rewards you, essentially, with a piece of [digital] property.

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.
bitcoin itself is artificial scarcity.
additional block chains would each create their own flavor of coins, which would trade with bitcoins on exchanges? These chain-specific coins would be used to reward miners on those chains, and to purchase some kinds of rights or privileges within the domain of that chain?
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.
bitcoin itself is artificial scarcity.

The supply of bitcoin is just an integer determined by network. Otherwise, bitcoin are non-scarce. I can copy a wallet a millllllllllllioooooooooon of time and it will contain the same integer. It's a very weird form of scarcity and non-scarcity.
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.)
I agree.  All transactions, IP changes, renewals, etc. should have some fee that goes to the miners.

You might consider a certain amount of work to generate a domain, instead of a fixed total circulation.  The work per domain could be on a schedule that grows with Moore's Law.  That way the number of domains would grow with demand and the number of people using it.
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.

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.
It seems like killing two birds with one stone isn\u0092t enough on the bitcoin forum; one has to kill three.

Firstly, I would like to commend nanotube's+theymos proposal.  I like it because it makes economic sense, and it is simple.
The design that I am proposing in this post is backwards compatible with nanotube's+theymos proposal, however solves all the \u0091issues\u0092 said. (I still think there is really nothing wrong about how it is proposed to work as it is.  However, if there is a better way of doing it, why not?)

Before we start, one must state that domain names a fundamentally different to currency, as they obtain their value in a very different manner; currency obtains values from being something that has restricted supply.  Domain names, rather have values from the quality of the name, i.e. a short dictionary word has more value that a long random sequence.

If a restriction of the total number of domain names is made, it would be an arbitrary restriction, causing a lower efficiency market, thus reducing the attractiveness of using that market.
So with this in mind, lets design a system that can have an unlimited number of domain names; providing people are willing to pay for the service of claiming the domain name.


The main concern on the forum is the inclusion of \u0091other data\u0092 in the block chain; the problem isn\u0092t a fundamental one, as the bitcoin transactions block chain is indeed data in its own right.
In discussions elsewhere, it has been shown that:
1.   Generators will happily include any data that is profitable to include.
2.   The block size will grow to a size that balances data demands and the profitably of the miners.
3.   Clients only need to \u0091keep\u0092 data that they interested in.  Data that is irrelevant to the client may be forgotten once processed.
4.   Transaction balances may be used to cull the chain of old transactions.
Therefore it has already been shown that the amount of data in the chain is not an issue with: generation (they get paid for it), or storage (they only keep what they want).  The only outstanding issue is: transfers.

What has been discussed is that every client must download the entire block chain (before it is culled) then, every new block generated and check it.  Only after processing may a client delete any data that it doesn\u0092t want.  This accounts for a small amount of work while the chain is small, however the fear is when large amounts of irrelevant data (to any particular client) is included in the chain this task will become overly taxing.


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\u0092s compensation to the miners as a bitcoin transaction fee).
Group the transactions by templates.  For example:  Put the \u0091vanilla template\u0092 bitcoin transactions into the vanilla group, the \u0091bitdns template\u0092 bitcoin transactions into the bitdns group, the \u0091bitpgp template\u0092 bitcoin transactions into the bitpgp group, and so on.

Finally include a \u0091summary\u0092 group that contains only the changes to the transaction balances accumulated in all the other groups.

A Block could contain something like this:


Once one block has confirmed the previous block (checking that all the accounting is correct in the summary block), only downloading the merkle tree and the summary group is required to keep up2date about the changes.  This is in-effect less data than is required to download now! If the client decides that it needs some in-particular bit of data from one of the other groups after checking the summary, it can optionally download that also.

The important thing to notice is it that there is no free lunch, every bit of data must still include the appropriate transaction fees, in bitcoins.


Nanotube and Teymos\u0092s design fits very nicely on top of this design, as the transactions that the BitDNS system makes will simply be automatically grouped by the template that the generators use to check the BitDNS transactions before accepting them. Allowing clients to download the BitDNS data if they want it, or just download the transaction summaries.
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).
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.
I cannot find the nanotube+theymos proposal

It's here. The simpler DomainChain proposal is here.
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.
@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