Changing domain renewal handling

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

Re: Changing domain renewal handling

Post by domob »

biolizard89 wrote:
indolering wrote: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).
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

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

Re: Changing domain renewal handling

Post by 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.
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

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

Re: Changing domain renewal handling

Post by indolering »

biolizard89 wrote:
indolering wrote: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! :P
biolizard89 wrote:
indolering wrote:*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.
biolizard89 wrote:
indolering wrote: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?
biolizard89 wrote:
indolering wrote: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?
...
biolizard89 wrote:
indolering wrote: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 : )
DNS is much more than a key->value datastore.

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

Re: Changing domain renewal handling

Post by 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.
DNS is much more than a key->value datastore.

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

Re: Changing domain renewal handling

Post by 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 : )
DNS is much more than a key->value datastore.

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

Re: Changing domain renewal handling

Post by 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.
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

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

Re: Changing domain renewal handling

Post by indolering »

domob wrote: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.
domob wrote: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.
DNS is much more than a key->value datastore.

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

Re: Changing domain renewal handling

Post by biolizard89 »

indolering wrote: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.)
indolering wrote: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.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

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

Re: Changing domain renewal handling

Post by domob »

biolizard89 wrote:
indolering wrote: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. ;)
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

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

Re: Changing domain renewal handling

Post by 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.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

Post Reply