Actually one of the criteria for SHA-3 is speed, which is not particularly important for Bitcoin. We might consider using a different approach.

http://en.wikipedia.org/wiki/Provably_secure_cryptographic_hash_function

These hash functions are slow but have a degree of provable security.

There have also been various proposals for proof of work (POW) systems, including some that were designed to resist hardware optimization. Perhaps this could produce "fairer" generation where graphics cards and specialized hardware wouldn't have such an advantage. (However people with access to large networks of computers might dominate then.)

I'd like to hear some specific criticisms of the code. To me it looks like an impressive job, although I'd wish for more comments. Now I've mostly studied the init, main, script and a bit of net modules. This is some powerful machinery.

... is an ATI Radeon HD 5970...

Anyone else putting graphics cards on their Christmas lists for some serious mining?

Actually the 5970 is a little pricey, newegg.com has it from $500 to $1200 dollars. But even lower end cards should be able to generate a few blocks a month hopefully.

Somewhere I got the idea that the number of "stream processors" would be proportional to hashes/sec. Probably clock rate would be proportional too. So I've gone through and divided # stream processors by price to get a "bang for the buck" measure. The 5970 has 3200 stream processors so the $500 card would have 6.4 processors per dollar. Actually most of the Radeon cards are in the 5-7 ratio so for the most part you get what you pay for.

The best ratio I found was for an HD5850 which has 1440 stream processors for as little as $200. That gives it a ratio of 7.2 and the price is closer to my budget. This has been reported at http://bitcointalk.org/index.php?topic=1628.msg24699#msg24699 to get as much as 300 Mhash/sec. At current difficulty the calculator predicts a block every two days.

With bitcoins at about $0.20, a block of 50 is worth $10, so after 40 days the card would be paid for. That may be a little optimistic (especially if everyone gets 5850s for Christmas) but at least it would be fun to be generating blocks.

I like the suggestion, hadn't heard it before. I'm trying to follow it now.

I though it was funny that calling this an RFC is kind of a play on words. RFC means Request For Comments, and in this case you're requesting that comments be added to transactions. So it's a request for comments in both senses.

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

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?

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.

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.

jgarzik makes a good argument that the complexity of the scripting system is not being used and is unnecessary. Simple in/out transactions are all that are needed. I'm not convinced that there is anything that can be done with Bitcoin scripting that can't be done with a crypto layer on top of Bitcoin to share/split keys, etc.

Anyway fancy scripts won't be able to be used until everyone upgrades their clients, after this last change. All the future-proofing that the scripting was meant to enable is lost. So there's even less reason to keep it.

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 -

We're at block 96,000+ now and block 100,000 is in sight. At current rates it should show up by Christmas, depending on how much computing power increases by then.

Anybody up for a pool betting on when block 100,000 will appear? Say 1 Bitcoin per person? Post your guess here (UTC only) and commit to paying 1 btc to whomever's closest. Let's close the guessing after block 98000 so late guessers don't have too much advantage.

I'll start and pick noon Christmas day, for fun.

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.

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.

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.

Good point, I'm going to quote this in the BitDNS thread, hope you don't mind.

There exists a cryptographic technique called split keys which could be used on top of Bitcoin to solve some problems in needing to trust people to make Bitcoin transfers. The idea is for the payor and payee to jointly generate a Bitcoin address that will receive the payment. Bitcoin addresses are essentially public keys, and knowledge of the corresponding private keys are what let you spend the coins. In this case, though, a public key is jointly generated between the payor and payee, such that each only ends up with, in effect, half the private key. Neither party will be able to spend coins sent to the address corresponding to this split key.

The payor then makes a payment of the agreed amount to this special address. Once this is done, the payor has lost the Bitcoins. He can't spend them anymore; they belong to this new address which is split between the two of them. The payee can't spend the coins either, at this point.

To complete the transfer, the second step is for the payor to reveal his part of the private key to the payee. Then the payee knows the full private key, which gives him control of the address that received the payment. They are now his Bitcoins to spend as he likes.

The advantage of splitting up the payment into two steps like this is that the first step, where the payor makes a payment to the split key, represents a very strong commitment on his part to see the deal through. After that step, typically the payee must hold up his end of the bargain and perform some action he is being paid for. Once that is completed, the second step of the transfer occurs and the payee receives his payment.

Throughout, no one has any financial incentive to cheat. The first step does not benefit the payee, and the only way he gets paid is to perform. And the second step does not harm the payor; he is out the coins already and gains no benefit from failing to follow through.

It is analogous to tearing a $100 bill in half and giving half to someone, with a promise to deliver the other half if he cooperates. This is a credible commitment and a strong inducement. You have no financial incentive to cheat him if he holds up his end.

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.

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.

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.