Namecoin Forum

What is a "Name Epoch"?

A name epoch is a period of 36,000 blocks. The epoch number would be floor(block height / 36,000), currently 5, soon to be 6.

A registration can be uniquely identified by (name, epoch of name_firstupdate). If the name expires and is re-registered the epoch will be different.

How can the epoch for a name be found?

Look at the transactions returned by name_history for a name, and find the most recent name_firstupdate transaction, then compute the epoch for that block. This value could easily be added to the result of name_show.

What's this good for?

My primary thought would be to use this for identity systems. When I create my account with ExampleSite using id/ryanc, it will record the current epoch for id/ryanc and require some verification procedure if the epoch changes.

For a .bit site, a .bit enabled browser could show an alert to the user if the epoch has changed since their last visit, protecting the user against a malicious re-registration.

Please let me know what you think, and if there's anything that I should clarify.

Sounds like a good idea. It could also work without history if the epoch value is saved in the namedb with every firstupdate.

phelix wrote:Sounds like a good idea. It could also work without history if the epoch value is saved in the namedb with every firstupdate.

Yes, ideally the namedb should just track the epoch value so it doesn't need to be looked up separately. The name history thing is just a way it could be implemented now.

It seems like you are trying to specify a unique ID for each owner of the name, so why not just count the number of public keys that have owned the address?

If you are trying to tie things to the initial registration, we could output a short hash of the public key, domain name, and the name_new hash. To keep things short, we would have to check the name's history to see if the hash matches any previous hashes and (if so) run it through the KDF one more time.

This would also help ameliorate the lack of revocation in our naming system.

Somewhat related to this discussion (insofar as I believe that part of the discussion that prompted this idea had to do with d/name and dd/name getting out of sync) is my proposal to allow owners of d/name to control the creation of d/name/child. We could just tie the child's registration period to the parent's.

indolering wrote:It seems like you are trying to specify a unique ID for each owner of the name, so why not just count the number of public keys that have owned the address?

If you are trying to tie things to the initial registration, we could output a short hash of the public key, domain name, and the name_new hash. To keep things short, we would have to check the name's history to see if the hash matches any previous hashes and (if so) run it through the KDF one more time.

This would also help ameliorate the lack of revocation in our naming system.

Every name_update generates a new public key, so I don't see how that would make any sense.

biolizard89 wrote: Every name_update generates a new public key, so I don't see how that would make any sense.

Ahh, well I didn't know that and it certainly doesn't!

biolizard89 wrote:

indolering wrote:It seems like you are trying to specify a unique ID for each owner of the name, so why not just count the number of public keys that have owned the address?

If you are trying to tie things to the initial registration, we could output a short hash of the public key, domain name, and the name_new hash. To keep things short, we would have to check the name's history to see if the hash matches any previous hashes and (if so) run it through the KDF one more time.

This would also help ameliorate the lack of revocation in our naming system.

Every name_update generates a new public key, so I don't see how that would make any sense.

You could count the firstupdates but Ryan's suggestion has the advantage of being independent from history.


Edge case: you can not always be sure of the epoch you get when registering. Should not matter too much, though.

It is *mandatory* to use the name_firstupdate block instead of the name_new. This is because the time from name_new to when the name expires depends solely on when the name_firstupdate happens.

As phelix says, I chose this method because it is independent of whether or when the name had been registered in the past.

Midnightmagic pointed out on IRC that this scheme does not provide a way for changes of ownership (or name theft) to be made clear. If that is a problem we want to solve, I have some ideas about how to do that (mostly involving BIP32).

ryanc wrote:It is *mandatory* to use the name_firstupdate block instead of the name_new. This is because the time from name_new to when the name expires depends solely on when the name_firstupdate happens.

As phelix says, I chose this method because it is independent of whether or when the name had been registered in the past.

Midnightmagic pointed out on IRC that this scheme does not provide a way for changes of ownership (or name theft) to be made clear. If that is a problem we want to solve, I have some ideas about how to do that (mostly involving BIP32).

I don't want to make changes of ownership publicly identifiable because that would harm anonymity.