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.

I don't think a proof-of-work chain is useful for distributed storage. There are much easier ways to implement distributed storage.

The proof-of-work chain is a great way to do distributed allocation though, which is why it's useful for rationing limited digital codes (bitcoins, domain names, etc).

Here's how it looks on the phone, in case anyone's interested:

The swipe gesture is awkward, I agree. You can also easily make precise selections by tapping at the start of the selection then typing shift-rightarrow to extend the selection, or shift-tap to set the end of the selection.

What's more generic than bitcoin? Coins represented by digital bits.

If the wiki page is correct, data can be embedded into a transaction without using OP_DROP. A transaction is valid if "nothing in the script triggers failure, and the top stack item is true". Therefore the embedded data can just be left on the script stack. No need to drop it.

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.

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.

I've now studied the theymos/nanotube spec in more depth, and my questions and comments are starting to flow.


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

It's only socialism if you are forced to do it.

Most anarcho-capitalists, in their private life, are quite socially-aware and always happy to help out someone deserving who is less fortunate than they are.

Go for it, Artforz!

I'm surprised to hear you say that.

To send the bitcoin to you, I just browsed your forum post on my phone, double-tapped on your bitcoin address to select it, pressed control-C on the keyboard to copy it, then used the "Paste" menu option in XTerminal. Not at all painful!

I have found though, that bitcoin addresses in Gmail have a nonbreaking space added after the 16th character. To copy those cleanly, click "show original" in Gmail and copy from the raw message text.

I wouldn't do it that way, because venture capitalists are hoping to eventually extract at least as much value as they put in "up front".

If I found $10,000,000 in the street, I would work on the domain name registration idea. Although this makes some people uneasy, I think it would be fantastic for bitcoin by entrenching it as something of economic relevance.

How do you feel about allowing cars to use roads that were originally designed for horses? That causes congestion, death, and massive expense, but most people still feel it's worth it.

If I put 100 bitcoins on my phone, I don't regard that as personal data. If my phone gets lost or stolen, the value of the phone is much greater than the value of the bitcoins it holds.

I sent 0.42 BTC from my N900 at 10.55 GMT. If you receive it, that's the first ph2ph bitcoin transfer!

Doublec's bitcoind seems to work perfectly. It took me ten hours to get the block chain. I had the phone plugged in to USB all that time, and occasionally a warning flashed up saying that the phone was using more power than the USB was supplying. But now that the block chain is up to date it's fine, even with generating. I think writing the block chain to flash memory was pushing the power consumption up.

Like doublec's phone, mine hashes at between 130 and 150 khash/s. The predicted "average time to generate a block" is 2869 days at the current difficulty level of 8078. That's almost 8 years, so I'm not holding my breath. However, if we had 2869 people generating on phones, someone would generate a block on their phone every day, so it's possible that a block will be generated on someone's phone one day.

For those who don't know the N900, it runs a reasonably standard Linux with root access. The shell is "ash" which is basically a cut-down bash. The utilities are mostly cut-down versions from the BusyBox project, so for example you have to use "more" rather than "less", and the commands don't have so many options, but it's not a big limitation.

Programming for the N900 is generally done in C++ on a Linux PC using a cross-compiler. GUIs are GTK+ or Qt. Masochists have even managed to install gcc on the phone and do their development on-device. The phone comes with Python, and you can install PyQt which provides a straightforward way to develop GUI apps on-device. The phone comes with 32GB onboard, and you can add another 32GB using the microSD socket, so there's plenty of space to develop stuff.

You have to create bitcoin.conf yourself if you want it. It's not created by default.

Wallet.dat is normally in ~/.bitcoin

I don't know what tools you used to search your filesystem, but some tools require an extra flag or checkbox to include directories that start with a dot ("hidden" directories).

What do you suggest is a better way to decide who gets sex.domain?

If the economic system has a different name, then "bitcoin:" will serve as a generic identifier like "mailto:".

0000 hours, Christmas day (i.e. midnight Christmas Eve)