BitDNS and Generalizing Bitcoin

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

BitDNS

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

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

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

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

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

Generalizing Bitcoin: BitX

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

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

1. The payload in a block is a mapping from application names to hashes: [“bitcoin”: , “bitDNS”: , “bitHaiku”: , …]

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

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.

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…

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

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.

Quote from: nanotube on December 09, 2010, 12:20:40 PM UTC

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.

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.

Quote from: satoshi on December 09, 2010, 1:46:50 PM UTC

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.

Quote from: Anonymous on December 06, 2010, 2:53:37 AM UTC

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.

Quote from: bitcoinex on December 10, 2010, 5:51:50 AM UTC

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

Quote from: RHorning on December 10, 2010, 4:39:27 AM UTC

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

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?

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’t 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 ‘issues’ 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 ‘other data’ in the block chain; the problem isn’t 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 ‘keep’ 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’t 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’s compensation to the miners as a bitcoin transaction fee). Group the transactions by templates. For example: Put the ‘vanilla template’ bitcoin transactions into the vanilla group, the ‘bitdns template’ bitcoin transactions into the bitdns group, the ‘bitpgp template’ bitcoin transactions into the bitpgp group, and so on.

Finally include a ‘summary’ 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’s 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).

From what I can tell, the proposal located on domainchain: (see http://domainchain.org/wiki/doku.php?id=start#proposal ) goes against Satoshi’s wishes to keep the bitcoin blockchain unencumbered and ties domain assignments directly to bitcoin. Many community members have stated that this is impractical and will leave bitcoin if attempts continue to include domainchain into bitcoin directly. Satoshi asked that a new tree be created with a separate currency that floats its value according to demand with the bitcoin service.

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.

What we have here are dedicated coders/hackers that are racing ahead of theorists. The theory must be bulletproof before any proposals are launched. I think we need mathematical theorists to begin the process and then hand off to coders the basic structure while pointing out weaknesses.

A new chain with grassroot development should excite the miners and coders and calm the fears of the thinkers/theorists among the community. The funny thing is, once the theory is solid the porting of a new BitDNS(Domainchain?) will be very simple. All the stumbling blocks appear to be centered around including Domainchain into the Bitcoin structure instead of branching it into its own chain.

Domainchain is dead, long live Domainchain! 😊