66. On a Distributed Domain Name Server

66

On a DistributedDomain Name Server

SOMEONE SUGGESTED creating a Bitcoin clone (an alternative currency) that would allow for a distributed peer-to-peer domain name server system (DNS). In addition to containing currencies, transactions stored in the block chain would also contain DNS information and could be updated with new transactions.

Such alternative currency exists today and is called Namecoin (see http://www.namecoin.org/), which allows people to register domain names ending in “.bit” and associate them with an IP address. Satoshi shares his thoughts regarding this type of system here. One of the major benefits of such decentralized domain name servers would bypass a government attempt at disrupting Internet communications to its citizens, as we have seen occur in Egypt in 2011.

Re: BitDNS and Generalizing Bitcoin

Posted by satoshi, December 09, 2010, 09:02:42 PM

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 wouldsubscribe 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 ifthere are multiple networks, they are a danger to each other if the available CPU power gangs up on one. Instead, all networks inthe 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.

Re: BitDNS and Generalizing Bitcoin

Posted by nanotube, December 09, 2010, 09:20:40 PM

Quote from: satoshi on December 09, 2010, 09:02:42 PM

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 from: satoshi on December 09, 2010, 09:02:42 PM

The networks wouldn’t need any coordination. Miners wouldsubscribe 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. : )

Re: BitDNS and Generalizing Bitcoin

Posted by satoshi, December 09, 2010, 10:46:50 PM

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

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), whatwould 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 50BTC 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 insidetheir blocks. This is inverted from the common timestamp server arrangement, where the chain is on top and then the MerkleTree, because that creates one common master chain. This is two timestamp servers not sharing a chain.

Re: BitDNS and Generalizing Bitcoin

Posted by satoshi, December 10, 2010, 05:29:28 PM

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.

Re: BitDNS and Generalizing Bitcoin

Posted by Hal, December 10, 2010, 07:14:04 PM

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?

Re: BitDNS and Generalizing Bitcoin

Posted by satoshi, December 10, 2010, 07:55:12 PM

Quote from: Hal on December 10, 2010, 07:14:04 PM

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

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

Re: BitDNS and Generalizing Bitcoin

Posted by Hal, December 10, 2010, 08:12:02 PM

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

Re: BitDNS and Generalizing Bitcoin

Posted by satoshi, December 10, 2010, 08:19:39 PM

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.

Re: BitDNS and Generalizing Bitcoin

Posted by dtvan, December 11, 2010, 07:43:08 AM

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 theroot. 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 establisha trusted, distributed authority that can form the root ofDNSSEC, 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 samekey would prove that I’ve reached the correct server. But Idigress . . .

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 wouldbe 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-yournew-benevolent-dictator).

Re: BitDNS and Generalizing Bitcoin

Posted by satoshi, December 10, 2010, 08:19:39 PM

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

Quote from: joe on December 11, 2010, 10:53:58 AM

However, thinking more about this now I support inclusion ofadditional 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 andhttp://bitcointalk.org/index.php?topic=1790.msg28715#msg28715

(Note, two of Satoshi’s earlier posts are included in this thread)

Another thread came up on the same subject:

Re: Fees in BitDNS confusion

Posted by galeru, December 09, 2010, 07:45:38 PM

A bunch of the current debate about including BitDNS or BitX makes assumptions that miners will include transactions or not based on some rather fine-grained conditions, while none of the standard code includes any sort of implementation that allows non-programmers to make decisions like that. How will I, the user, figure out what sort of fees have to go into a transaction?

Re: Fees in BitDNS confusion

Posted by jgarzik, December 09, 2010, 11:07:04 PM

Quote from: davout on December 09, 2010, 09:08:55 PM

Just wondering about the following example :I broadcast a transaction, sending X coins to some address. Doesn’t get included in blocks for a while because I don’t include a fee.

Do I have a way to cancel it and broadcast it again with a fee this time ?

See the discussion of locktime (https://bitcointalk.org/index. php?topic=1786.msg22119#msg22119)

for transaction replacement.

Re: Fees in BitDNS confusion

Posted by satoshi, December 09, 2010, 11:58:54 PM

Not locktime.

There’s a possible design for far in the future:

You intentionally write a double-spend. You write it with the same inputs and outputs, but this time with a fee. When your doublespend gets into a block, the first spend becomes invalid. The payee does not really notice, because at the moment the new transaction becomes valid, the old one becomes invalid, and the new transaction simply takes its place.

It’s easier said than implemented. There would be a fair amount of work to make a client that correctly writes the double-spend, manages the two versions in the wallet until one is chosen,handles all the corner cases. Every assumption in the existing code is that you’re not trying to write double-spends.

There would need to be some changes on the Bitcoin Miner side also, to make the possibility to accept a double-spend into the transaction pool, but only strictly if the inputs and outputs match and the transaction fee is higher. Currently, double-spends are never accepted into the transaction pool, so every node bears witness to which transaction it saw first by working to put it into a block.