Frequently Asked Questions

How do you get IP addresses? Are the keys IP addresses?

No, the keys are cryptographic keys. (Well, more likely, fingerprints of cryptographic keys.) You can use the cryptographic key to sign a statement about what the IP address of your server is or to sign documents themselves or whatever you like. I'm just solving the naming problem, not the file distribution problem. For the file distribution problem, I have another article.

How do you update a record?

To change a name from one key to another, you can just have the old key sign a statement executing a transfer to the new key, then append this with a nonce as a new line to the scroll.

What if your key is cracked? Well, you should transfer it to a longer key before computers get fast enough to crack your key.

What if you've lost your key or it gets stolen? Be more careful. What if you lose your PGP key or it gets stolen? Not much you can do about it.

You can also set names to expire after a certain time, unless they're renewed -- just like with domain names. For example, let each coined name last 12 months, allow "renewals" (signed transfer statements to a new key) from month 11 to month 13, then ignore the domain after month 13 and allow new registrations.

Won't the file be really big?

Yes, but people download big movies all the time. This is something you only need to download once. Here's Daniel Colascione:

Total size doesn't seem to actually be a problem, surprisingly. We have 1.9e8 domains right now; if we suppose each name is 20 bytes long, has a 20 byte nonce, a 20 byte revocation key, an 8-bit timestamp, and maps to an IPv6 address, we're looking at a per-node total database size of about 16GB --- big, but not unthinkable.

By the time this system gets implemented, I suspect people will have plenty of bandwidth and space. If not, then they can hire a server that they trust to store it and answer queries for them (like ISP's DNS resolvers do today).

How do you pick the right value of N, especially given the amount of available computing power changes over time?

I have a couple ideas, but I think the best way is to have an algorithm for gradually increasing N if new names get minted "too quickly" -- i.e. if you see more than X new lines within Y seconds, increase N by 1. You may want to tie Y to the the value of M discussed above.

What happens if two people find valid nonces at the same time?

You save both lines as "disputed" and let the next valid line settle the dispute.

More formally: Let M be an upper bound on the propagation delay for the network. If you receive two valid lines within M seconds of each other, store both valid lines as disputed -- but don't add either to your scroll. Eventually you will receive another line, but it will only work with one of the two disputed lines. Add it and whichever line it works with to your scroll.

Don't you know what nonce means?

Yes. But this is the term the security world has adopted. It comes from the phrase "for the nonce" which long predates the slang meaning.

How do you publish a new line?

The propagation question is just a simpler form of the introduction question: you need to be talking to at least one node which is a) in the network and b) not censoring the scroll. The easiest thing is probably just to use the nodes you trusted for introduction, although this will create some lopsided network topologies.

There may be ways to optimize against this.

What do we call this system?

People seem to be calling it "square triangle". It could also be called Nakanames, after BitCoin inventor Satoshi Nakamura.

changed January 14, 2011