Changing domain renewal handling

indolering
Posts: 801
Joined: Sun Aug 18, 2013 8:26 pm
os: mac

Changing domain renewal handling

Post by indolering »

I would like to propose that we adjust how expiration is handled on the backend. Basically, I think we should try to more closely mimic normal domain name expiration as outlined by ICANN here. Basically, registrants get 1 year and a 45 day grace period to renew the domain.

To calculate the expiration block, analyze the blocks/week over the past year and 13.5 months with X% of confidence. Renewals and such would, of course, still be based on 12 month periods with the 45 day calculation being fixed to the end.

There are a couple of ways to handle the grace period. One is for name_show and friends to just start returning an error code after 1 year from the date of registration.

A more complex solution would be to require each domain to specify a record which would be used as an import statement after the domain expires. We could provide a default expiry record pointing users to bit.namecoin.info/renew.html with instructions on how to renew as well as links to registrars. Registrars could override this field and insert their own import record which would direct the client to their renewal process. We could restrict the expiry record to an HTTP only record and continue to generate error codes for other protocols.
DNS is much more than a key->value datastore.

domob
Posts: 1129
Joined: Mon Jun 24, 2013 11:27 am
Contact:

Re: Changing domain renewal handling

Post by domob »

Sounds complicated. What is wrong with the current situation? If you renew some thousand blocks before the name expires, I see no problems. If you forget to renew, then that's your own fault. Why would we need a "grace period"?
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

crosser
Posts: 18
Joined: Thu Apr 03, 2014 7:05 am
os: linux
Contact:

Re: Changing domain renewal handling

Post by crosser »

My two cents:
- I don't think that expiration time needs to be more complicated than "N blocks"
- I see value in the concenpt of "grace period", to wake up forgetful owners some time before they lose ownership. This may be achieved as simple as by a recommendation that the name resolution stops M blocks before expiration.
Eugene; id/crosser

phelix
Posts: 1634
Joined: Thu Aug 18, 2011 6:59 am

Re: Changing domain renewal handling

Post by phelix »

crosser wrote:My two cents:
- I don't think that expiration time needs to be more complicated than "N blocks"
- I see value in the concenpt of "grace period", to wake up forgetful owners some time before they lose ownership. This may be achieved as simple as by a recommendation that the name resolution stops M blocks before expiration.
this

The "wake up grace period" is a really good idea. We should implement that somehow.
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

virtual_master
Posts: 541
Joined: Mon May 20, 2013 12:03 pm
Contact:

Re: Changing domain renewal handling

Post by virtual_master »

domob wrote:Sounds complicated. What is wrong with the current situation? If you renew some thousand blocks before the name expires, I see no problems. If you forget to renew, then that's your own fault. Why would we need a "grace period"?
Good question. I fully agree.
I also don't see any reason to make a development with counterproductive effects. That would encourage even more unnecessary name squatting and a massive shift toward new namespaces.
We should better resolve the fee balancing.
We could also have by the actual basic fee a length dependent registration/renewing period:
-- 10-14 characters - the actual expiration period T
-- 1-5 characters - T/4
-- 6-9 characters - T/2
-- 15-19 characters - 2T
-- 20- .. characters - 4T

id/ namespace entries could have double expiration time to give more security
If somebody wants to have longer expiration time should register a longer name. Shorter name would have a better recycling.
http://namecoinia.org/
Calendars for free to print: 2014 Calendar in JPG | 2014 Calendar in PDF Protect the Environment with Namecoin: 2014 Calendar in JPG | 2014 Calendar in PDF
BTC: 15KXVQv7UGtUoTe5VNWXT1bMz46MXuePba | NMC: NABFA31b3x7CvhKMxcipUqA3TnKsNfCC7S

John Kenney
Posts: 94
Joined: Sat Mar 29, 2014 2:20 pm
os: linux
Location: Sheffield, England
Contact:

Re: Changing domain renewal handling

Post by John Kenney »

I don't think there's much reason to have this in the blockchain. A reminder warning in client apps would be better. Maybe a period when expired names can't be re-registered would be better to protect against expired name squatters.

Increasing registration fees & renewal fees would help against squatters too.

indolering
Posts: 801
Joined: Sun Aug 18, 2013 8:26 pm
os: mac

Re: Changing domain renewal handling

Post by indolering »

VM, no hijacking my thread! ツ

After rereading this, I overcomplicated the problem and the solution, so let me try again:

I'm worried that the current system is too complex for end-users. This question is hard enough to answer as is but with .bit, we are asking them to learn all about the blockchain, mining, and variations in mining speed just to answer the simple question: when will I have to renew my domain?

A window of not resolving but not expired would be a really important feature for .bit domain holders, even big tech companies with dedicated staff forget to renew their domains. But I agree with everyone that trying to calculate this on the fly and shove it into the blockchain is probably a bad idea. We should figure out a way to emulate this without hard-coding it into the blockchain.

One way I can think of is just to use an expire tag of when the domain should stop resolving: "expire":"block". Another way would be to setup some community guidelines that we require* of domain registrars to handle everything on the backend.

However, in the big bag of "stuff we want to do on the next hard-fork" I think we should have a sane expiration default. After talking to people on IRC, the current figure of 36000 blocks was apparently arbitrary and it matches ~250 days. I think renewals should be in increments of about a year or just over, say 60000 blocks (~1 year + 50 days)? This, of course, could shrink to less than a year, but at least it's a non-arbitrary default with some safety margin.

*By controlling who is listed on the wiki.
DNS is much more than a key->value datastore.

virtual_master
Posts: 541
Joined: Mon May 20, 2013 12:03 pm
Contact:

Re: Changing domain renewal handling

Post by virtual_master »

John Kenney wrote: A reminder warning in client apps would be better.
.............
Increasing registration fees & renewal fees would help against squatters too.
I think this would be the easiest and most logical solution. A reminder in the client with 10 or 20 days before expiration.
indolering wrote: After talking to people on IRC, the current figure of 36000 blocks was apparently arbitrary and it matches ~250 days.
This is clear and you have right. Unfortunately Vinced is not any more available so we will never find out what was the logic behind 250 days.
Having 400 days (one year +10%) as expiration time would be better. But is it worth to make a risky hard fork only for this ? I don't think so.
But in connection with other changes this could be considered also.
indolering wrote:VM, no hijacking my thread! ツ
It was no hijacking. Scaling(eventually) the expiration time in dependence with the namespace and name entry length would interfere with a grace period.
John Kenney wrote: Maybe a period when expired names can't be re-registered would be better to protect against expired name squatters.
That wouldn't work as the program cannot differentiate between a name squatter and an active name user. Domain users who invested time and money for their websites need security. For IDs it is even more the case because even an inactive ID could be important. (some people don't use Namecoin ID because they consider risky if it will expire)
http://namecoinia.org/
Calendars for free to print: 2014 Calendar in JPG | 2014 Calendar in PDF Protect the Environment with Namecoin: 2014 Calendar in JPG | 2014 Calendar in PDF
BTC: 15KXVQv7UGtUoTe5VNWXT1bMz46MXuePba | NMC: NABFA31b3x7CvhKMxcipUqA3TnKsNfCC7S

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Changing domain renewal handling

Post by biolizard89 »

indolering wrote:VM, no hijacking my thread! ツ

After rereading this, I overcomplicated the problem and the solution, so let me try again:

I'm worried that the current system is too complex for end-users. This question is hard enough to answer as is but with .bit, we are asking them to learn all about the blockchain, mining, and variations in mining speed just to answer the simple question: when will I have to renew my domain?

A window of not resolving but not expired would be a really important feature for .bit domain holders, even big tech companies with dedicated staff forget to renew their domains. But I agree with everyone that trying to calculate this on the fly and shove it into the blockchain is probably a bad idea. We should figure out a way to emulate this without hard-coding it into the blockchain.

One way I can think of is just to use an expire tag of when the domain should stop resolving: "expire":"block". Another way would be to setup some community guidelines that we require* of domain registrars to handle everything on the backend.

However, in the big bag of "stuff we want to do on the next hard-fork" I think we should have a sane expiration default. After talking to people on IRC, the current figure of 36000 blocks was apparently arbitrary and it matches ~250 days. I think renewals should be in increments of about a year or just over, say 60000 blocks (~1 year + 50 days)? This, of course, could shrink to less than a year, but at least it's a non-arbitrary default with some safety margin.

*By controlling who is listed on the wiki.
I think a reasonable solution would be to implement an "expires" field at the nmcontrol level, which is equal to a number of blocks N. If N or fewer blocks remain before namecoind expires the name, then nmcontrol will refuse to resolve the name (and issue an error message saying that the name is almost expired). If "expires" is not present, it is assumed to be 0. I would suggest implementing this at the getValueProcessed level rather than in a certain namespace, since name expiration is an issue for pretty much all namespaces.

Thoughts?
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

domob
Posts: 1129
Joined: Mon Jun 24, 2013 11:27 am
Contact:

Re: Changing domain renewal handling

Post by domob »

biolizard89 wrote:I think a reasonable solution would be to implement an "expires" field at the nmcontrol level, which is equal to a number of blocks N. If N or fewer blocks remain before namecoind expires the name, then nmcontrol will refuse to resolve the name (and issue an error message saying that the name is almost expired). If "expires" is not present, it is assumed to be 0. I would suggest implementing this at the getValueProcessed level rather than in a certain namespace, since name expiration is an issue for pretty much all namespaces.

Thoughts?
Sounds like a good idea from my point of view.
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

Post Reply