Extend renewals to circa 1 year

[JeremyRand]

Name renewals should be increased to circa a year (maybe with some extra time thrown in just in case a bunch of extra mining power comes on board). I think @indolering did some preliminary research on this. The current default (36 kiloblocks ~= 250 days) is confusing to newcomers, because it differs from the policy of ICANN domains (for no obvious engineering/technical reason).

This would be a hardfork change, so we should be very careful to make sure we get it right the first time.

(Posting in meta since it affects all Namecoin implementations such as libcoin, not just Namecoin Core.)

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/9346505-extend-renewals-to-circa-1-year?utm_campaign=plugin&utm_content=tracker%2F6562918&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F6562918&utm_medium=issues&utm_source=github).

[indolering]

The relevant forum thread is here. The conclusion of the discussion was to create a more advanced algorithm that would provide us with some high degree of assurance that the renewal period would last at least 12 months with a target of 13 months. This would mimic ICANN domain renewal period of 12 months + a grace period in which the domain stops resolving but is still renewable by the original owner.

Analysis of the current algorithm showed that it accumulates distortions over time because it only attempts to correct for the block discovery rate while ignoring the total number of blocks. I suggested altering the algorithm to adjust the difficulty according to a target blockcount calculated using the date.

@domob1812 wanted to create a difficulty adjustment algorithm that does not require tracking a target blockcount but is still resilient to large changes in hashing power. Domob took a month off of his PhD program to research the topic and wrote a paper on it. Unfortunately, he was unable to test his proposed algorithms against historical data. I requested 6 weeks of funding to test and implement the algorithm in my last OTF grant request. If we do not get that grant, I will include it in my May 1st grant to NLNet.

The last remaining point of disagreement was expiration handling. I proposed having resolvers (NMControl, etc) simply stop resolving the domain at 12 months. Jeremy prefers an expiration tag to be included in the domain record.

[indolering]

@domob1812 Has that paper been published yet? If not, are you comfortable putting up a link to a prepublication draft?

[domob1812]

No, not yet (getting peer review is a very slow process). However, I actually believe (after more thoughts) that it is much better to base name expiration on the block timestamps instead of a fixed expiration period in terms of block count if we want to achieve a real-world expiration time. I. e., as soon as a block is accepted which has a timestamp more than a year from my name's last update time, the name expires. This probably also needs a lot of thought to make sure it does not create any problems, but is probably much easier (and safer) to do than using my academic retargeting algorithm.

(The paper itself is still interesting, of course, both for the proposed algorithm and for the general mdoelling of mining that it does.)

[indolering]

@domob1812 That sounds great, could you give me a work estimate (days/weeks @ full time) for how long it would take to implement this logic?

Can we all agree on 12.5 months for the registration period? Twelve months resolving, 2 weeks of non-resolving (but still renewable)?

@JeremyRand should we move discussion of expiration tag vs middle ware to a new ticket?

[indolering]

Note that we want to enable people to renew the domain on the same date every year. So if I renew a domain early, it should still expire on the same date the next year. I'm worried that a naïve implementation will count the additional 2 weeks and shift the renewal period forward by 2 weeks. We also need to worry about leap years (although we can safely ignore leap hours/minutes/seconds).

Do we need to discuss maximum registration periods and should that reside in a new ticket? We don't want people using domain registrations as a hedge, there should be some maximum of 2-5 years. I'm also worried about people losing a private key and having to wait 5 years to get the domain back.

[domob1812]

Wait a moment, please. Before we can talk about work estimates (presumably because you want to include that into a grant proposal), can we please first discuss whether we actually want to do this change? Whether there are risks involved? Problems I don't yet see? After all, this is so far just a rough idea without much further thought. Please, before going into details, can we try to get a good internal consensus about what we actually want to do?

[domob1812]

Also, your last comment sounds as if we already agreed that this is what we want. I don't agree here. While a one-year period is nice to have, I don't think we should complicate matters by requiring that an early renewal is possible without shifting the deadline, for instance. I suggest to stick to the "expiration after (some time) after the last update" logic we have now. If someone is really forgetting to renew the domain because the date shifted, they should be using some external service that renews for them (possibly with @JeremyRand's name permission proposal).

[JeremyRand]

@domob1812 What would the possible attacks be if block timestamps are used? I'm not familiar with how block validation handles timestamps. My assumption is that this would decrease the security of name expirations to SPV-level... is that correct?

[JeremyRand]

And yes, I agree with @domob1812 that any such proposals are "scratchpad-quality", and should not be considered official without getting a lot of peer review.

[indolering]

I'm fine with more discussion, I thought it would be a fairly straightforward change. We can ignore my suggestion for variable renewal times if it simplifies things.

I think we are all agreed on having a 12.5 month renewal period with 2 week virtual grace period in which the middleware stops resolving but the domain is still renewable, at least everyone seemed to be okay with it in the initial forum thread. Since the non-resolving bit is handled by the middleware, I think it would be fairly easy to implement (as Namecore doesn't need to be aware of the 2 week period of non-resolving).

From TFM,

A timestamp is accepted as valid if it is greater than the median timestamp of previous 11 blocks, and less than the network-adjusted time + 2 hours. "Network-adjusted time" is the median of the timestamps returned by all nodes connected to you.

Whenever a node connects to another node, it gets a UTC timestamp from it, and stores its offset from node-local UTC. The network-adjusted time is then the node-local UTC plus the median offset from all connected nodes. Network time is never adjusted more than 70 minutes from local system time, however.

So it looks like an attacker could push the date forward by (at most) two hours. Given the "grace" period, this shouldn't be a problem as the domain should have been renewed weeks ago.

The BitShares architect was fine with relying on the accuracy of the NTP because if NTP breaks the internet breaks. I think they have an even stricter requirements for their timestamps. I will ask one of them for comment.

[JeremyRand]

@indolering I prefer a 1-month grace period. People who have active websites will notice within a few days, but I wouldn't expect to notice if my website was down for quite a while. So targeting a 13-month renewal period seems like a good idea.

Variable renewal periods would be a separate ticket. (I don't think it's a good idea though.)

[indolering]

The only reason I suggested a 1-1.5 month grace period previously was because I wanted to make sure we gave the difficulty adjustment algorithm some wiggle room. I was hoping to get a week or two of reliable renewal time out of that. But I have not problem with a full month.

[phelixbtc]

The relevant forum thread is here. The conclusion of the discussion was to create a more advanced algorithm that would provide us with some high degree of assurance that the renewal period would last at least 12 months with a target of 13 months.

This was not the conclusion of that discussion. I don't think there even was a conclusion.

And yes, I agree with @domob1812 that any such proposals are "scratchpad-quality", and should not be considered official without getting a lot of peer review. this

It would be nice to be able to update only once a year but switching to timestamps is way too complicated to attempt now. We could double the amount of blocks a name_update lasts.

In any case this issue is low priority IMHO and there are other much more pressing things to do. E.g. implement an expiry warning and the grace period in peripheral applications.

[indolering]

I disagree that this is a low priority item, it is essential that Namecoin domains act predictably and that means copying the behavior of traditional domain names. The variable renewal period is a major source of confusion for new users.

[JeremyRand]

It is a prerequisite for mass adoption, I think. However, I think at this point we don't want mass adoption -- that should wait until other aspects are more secure. Projects which are very usable but not secure are a dangerous trap -- don't make it too usable too fast. NMControl support for a grace period seems to make more sense short-term, as it doesn't affect block validation.

I definitely would like to get this done at some point -- I just don't think it's called for in the next 6 months (unless we somehow get a lot further than I expect... funding would make a difference).

[indolering]

The BitShares team didn't run into any time warp attacks.

I found this while skimming the Bitcoin developers guide:

Care must be taken near the expiry time of a time lock. The peer-to-peer network allows block time to be up to two hours ahead of real time, so a locktime transaction can be added to the block chain up to two hours before its time lock officially expires. Also, blocks are not created at guaranteed intervals, so any attempt to cancel a valuable transaction should be made a few hours before the time lock expires.

If the network is capable of enforcing locktimes to within two hours, shouldn't we be able to enforce renewal periods to within two hours as well? If the expiration occurs, as Domob suggested, "as soon as a block is accepted which has a timestamp more than a year from [the] name's last update time" even a DDoS attack would only delay the expiration to the end of the attack.

[JeremyRand]

FYI, there was some discussion about using timestamps on IRC, with Luke, Ryan, and someone else.