indolering wrote:Just because the hashing power is not deterministic does not mean that we cannot create highly reliable estimates based on it. Over time, the rate at which new blocks are produced is highly variable within a very narrow range of values.
This is likely.
indolering wrote:I did the math on this by dumping every single block timestamp and rounding them off to a 24/hour period. First I simply created a prediction for the the expiration date based on a simple averaging of the recent hash rate for each day and then looked up the actual number of blocks that had been mined on the date predicted. These numbers were very, very close but I was using a correlational test to check how close they were. Obviously, a correlational can only give us an idea of how good the predictor was but it was very, very good.
Details would be nice here.
indolering wrote:Encouraged by the results I plugged the daily block counts into a stock renewal model used for calculating stock at a retail store with variable demand and reorder shipping delays. I put in a crazy high ~99.99% availability level and it returned a 33 day buffer.*
Details would be nice here as well. This is certainly interesting data if accurate.
indolering wrote:The bottom line is that if we just set the renewal period for 13.5 months NMControl could just stop resolving if 12 months have passed since the last renewal with >99.99% confidence that the domain will stop resolving before expiration date.
That's not the goal I described. My goal wasn't to make names stop resolving before they expire, it's to make names stop resolving sufficiently long before they expire that a name owner will notice and have sufficient time to react before the name expires. This requires a longer period than the goal you describe.
indolering wrote:Worse case scenario: I screwed up the stats
Data would help to determine that this is not the case.
indolering wrote:or China decides to become a Namecoin super power and domains start expiring PRIOR to 12 months.
Again, that's not the property I was going for. If the name stops resolving after 12 months and the name expires after 12 months and 1 day, that doesn't solve the problems that I was trying to solve.
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.)
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?
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.
indolering wrote:However, even under these extreme conditions we would have PLENTY of notice before domains started expiring and simply patch NMControl/NamecoinToBind to stop resolving domains at 11 months.
Relying on manual intervention would be unwise. Making NMControl automatically detect situations such as this, and automatically stop resolving early, would be much safer.
indolering wrote:By then, we should have auto-renewals figured out and all of the registrars will handle this for their customers anyway.
That would certainly be nice.
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.
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.