Changing domain renewal handling

[domob]

If you are REALLY worried about the variability of the hashing power – since we are talking about a hardfork anyway – we could just increase the rate adjustment limits from 1/4-4x to 1/8-8x and/or reduce the adjustment periods from 2 weeks down to one. I don't have the graph on me but I believe that would effectively smooth out the long-term variation in block discovery rates.

There are altcoins that handle this better; I vaguely recall that Primecoin has a nice solution which does retargeting every block using a moving average. I don't know what the full implications of this are.

Also HUC uses "continuous" retargetting (based on PPC). snailbrain raised some concerns, though, whether it actually works as desired (only from his "gut feeling", though).

[phelix]

Should we create a new thread about the "expiry warning time"? Or what should we call it? Expiry grace period? IMHO it's a good idea and deserves it's own thread.

[indolering]

If you are REALLY worried about the variability of the hashing power – since we are talking about a hardfork anyway – we could just increase the rate adjustment limits from 1/4-4x to 1/8-8x and/or reduce the adjustment periods from 2 weeks down to one. I don't have the graph on me but I believe that would effectively smooth out the long-term variation in block discovery rates.

There are altcoins that handle this better; I vaguely recall that Primecoin has a nice solution which does retargeting every block using a moving average. I don't know what the full implications of this are.

I was unsure if this was due to the nature of their mathematical problem or if they had just altered the adjustment mechanism. If it's straightforward to do then it would certainly make our lives easier : )

Should we create a new thread about the "expiry warning time"? Or what should we call it? Expiry grace period? IMHO it's a good idea and deserves it's own thread.

We need an NEP!

*Sadly, I lost the files I used to calculate all this in my last computer wipe and I would have to manually dig into my old backups to find them.

I hate to be "that person", but it would be helpful if you could find the backups of the math involved. A large hardfork is already hard enough to justify to miners and users without telling them that we're relying on math that only one person has ever seen.

Then don't, I'm not trying to justify a hard fork on these stats I'm justifying NOT creating an expiry tag based on them.

If an adversary wanted to force domains to expire two weeks early they would need to double the hashing power of the entire network for two weeks. After two weeks, the network would adjust the difficulty rating by 2x and the adversary would again have to double their hashing rates.

At current hashrates, it is entirely plausible that a well-resourced adversary could do this. The hashrate of Namecoin can be matched for under a billion USD last time I checked; this is well within the means of the NSA if they really wanted to steal a name. (Whether they really want to steal a name that badly is of course not proven.)

A billion dollars to force a domain to expire a week early? Can someone better at math than myself figure out the cost to erase 6 weeks from the block-chain given 12 months?

It is true that the incredible growth of the hashing power has recently outstripped the rate adjustment limits (1/4-4x) this is an unsustainable long-term trend. Midnightmagic has done the numbers on this and one quickly runs into a situation where all the power of the world is dedicated to mining Bitcoin.

Does one run into that limit before or after a high-target name is forced to expire?

...

An expires tag fixes this problem at the wrong layer: it should be done at the level of DNS resolution and NOT within the record itself.

I assume you don't actually mean DNS resolution, but I think I understand what you mean.

I'm sorry if I came across as arrogant or condescending my response. I just spent a lot of time on this and I rarely offer technical insight on problems in this forum. I'm usually the one getting schooled by you : )

[indolering]

Of course, now I want to look at the block discovery rates for primecoin/huntercoin. I'll make sure to dig the code out when I get a chance.

[indolering]

So I dug out my backup and looked over everything and I owe Jeremy and apology; there was a reason I didn't post those findings earlier : /

I did a simple averaging of the block discovery rate over 12 months and the speedup was as high as 20%. I couldn't install Primecoin locally but this Average Block Rate over Time chart (when shifted to a full year) doesn't look much better, with huge peaks not being followed up by dips.

I suspect that we are accruing additional blocks because the adjustment mechanism only attempts to correct for rate while ignoring the total number of blocks. Since we are talking about altering the algorithm anyway we could adjust the difficulty according to the total number of blocks mined. So, for example, if it finds that 2x the number of blocks were mined in the last period it would increase difficulty by 4x for the next period to compensate. This would be handled by simply calculating the target blockcount for the current date according to blocks/millisecond since the changeover. However, I think this would require bounding so that the block discovery rate doesn't slow down by too much.

To compensate, we should probably cut the target discovery time, limits, and the adjustment period.

• Rate Adjustment Limits 1/4-4x -> 1/8-8x
• Average Block Discovery Time 10 minutes -> 5 minutes
• Adjustment Period 2 weeks -> 1 week or a moving average.

I still think an expires tag would just be additional clutter and that this should be handled by middleware (NMControl, NamecoinToBind, etc) but check both the timestamp X number of blocks prior to expiration, whichever occurs first. I was thinking that the expiration should be set 14 months instead of 13. The timestamp check would be at 12 months and the blockchain count would be set to (what should be) 13 or 13.5 months. Even with a 20% speedup domains would stop resolving over a week before expiring.

Once renewal fees are implemented, we could increase price exponentially (year-over-year) for up to 3 years. Then if someone is really paranoid, they could put it in for a few months or even years but not use that as a monetary hedge for the value of the coin. Please, do not let discussion regarding renewal fees hijack this thread : )

[domob]

I think that it is fine to control the rate instead of the total number of blocks mined. This is what effects confirmation times, and IMHO the network should try to ensure that transactions are confirmed as expected. While I understand your concern about "real-life expiration times", I think it is more important to control the block rate instead of that. Is it really so hard to calculate with a sufficient error margin for yourself so that you don't lose your domains even if the block rate is not as expected? You can renew them for free even if they still have 10,000 blocks to go, so why not just do that? Also, it would be trivial to set up a web service somewhere (I think khal even had one) that sends out reminder emails 1,000 blocks before a name expires. I'd rather not experiment with the block rate algorithm without a real need for it, TBH.

[indolering]

I think that it is fine to control the rate instead of the total number of blocks mined. This is what effects confirmation times, and IMHO the network should try to ensure that transactions are confirmed as expected. While I understand your concern about "real-life expiration times", I think it is more important to control the block rate instead of that.

Just introduce an upper limit on the target average block discovery time. It would still converge on the target blockcount but over a longer period; say 2 weeks at half speed instead of 1 week at 1/4 speed.

If you are worried about confirmation times, decrease the target average block discovery time from 10 minutes to 5 minutes. Then the rate could be throttled to 1/2 speed while still matching Bitcoin's discovery time (and its associated confirmation times).

I would think that this would be a small tweak compared to switching to an entirely different hashing difficulty algorithm, i.e. Primecoin or Huntercoin.

Is it really so hard to calculate with a sufficient error margin for yourself so that you don't lose your domains even if the block rate is not as expected?.

I just don't want to push the expiration period to 18 months. The primary goal of this proposal is to introduce a non-arbitrary renewal period loosely tied to a year. The non-resolving component is a convenience feature that should not be relied upon for domain renewals.

The historical speedup peeks at 20% or 2.4 months (over a 12 month expiration period). Back-of-the-envelope math would suggest that increasing the adjustment limits (1/4-4x -> 1/8-8x) and decreasing the adjustment period (2 weeks -> 1 week) would push the acceleration we have seen down by 50% or more (and thus a speedup of 5%-10% or 18 days - 1.2 months).

But I don't have the time to actually model that based on hashing power. Without the ability for the algorithm to adjust based on the blockcount itself I would not endorse any proposal that lacks proper statistical analysis.

[biolizard89]

I just don't want to push the expiration period to 18 months. The primary goal of this proposal is to introduce a non-arbitrary renewal period loosely tied to a year. The non-resolving component is a convenience feature that should not be relied upon for domain renewals.

For what it's worth, as a domain owner whose domains don't get a lot of traffic, I'd really like my domain to stop resolving a month before I lose control of the domain (with high certainty). If that timeframe is optimal for the general user base, then it should be set up that way. If it's not, then it should be configurable by the name owner. (I suspect the latter is the case.)

The historical speedup peeks at 20% or 2.4 months (over a 12 month expiration period). Back-of-the-envelope math would suggest that increasing the adjustment limits (1/4-4x -> 1/8-8x) and decreasing the adjustment period (2 weeks -> 1 week) would push the acceleration we have seen down by 50% or more (and thus a speedup of 5%-10% or 18 days - 1.2 months).

But I don't have the time to actually model that based on hashing power. Without the ability for the algorithm to adjust based on the blockcount itself I would not endorse any proposal that lacks proper statistical analysis.

Yeah, statistical analysis would be useful here.

[domob]

The historical speedup peeks at 20% or 2.4 months (over a 12 month expiration period). Back-of-the-envelope math would suggest that increasing the adjustment limits (1/4-4x -> 1/8-8x) and decreasing the adjustment period (2 weeks -> 1 week) would push the acceleration we have seen down by 50% or more (and thus a speedup of 5%-10% or 18 days - 1.2 months).

But I don't have the time to actually model that based on hashing power. Without the ability for the algorithm to adjust based on the blockcount itself I would not endorse any proposal that lacks proper statistical analysis.

Yeah, statistical analysis would be useful here.

There may be something in the works (or at least planning) here.

[biolizard89]

FYI, I have slightly revised the "expire" field specification NEP: https://wiki.namecoin.info/index.php?ti ... ireWarning

The revision is because the previous spec would have undefined behavior if multiple imported names resulted in a conflicting "expire" field. It also simplifies the behavior by only allowing "expire" to occur in the root context of a name (KISS Principle FTW).

I still believe that this spec is useful, regardless of what we do regarding automated domain renewals and/or registration periods.