Changing domain renewal handling

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

Re: Changing domain renewal handling

Post by phelix »

biolizard89 wrote: [...]
namecoind should stay as simple as feasible, i.e. anything that can be implemented at the NMControl level should be done there.
this
domob wrote:
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.
this
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

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

Re: Changing domain renewal handling

Post by biolizard89 »

Draft spec posted here:

https://wiki.namecoin.info/index.php?ti ... ireWarning

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

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

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

Re: Changing domain renewal handling

Post by phelix »

biolizard89 wrote:Draft spec posted here:

https://wiki.namecoin.info/index.php?ti ... ireWarning

Any comments?
TBH I don't quite get it.

Code: Select all

Unexpired name:
{
"expires_in" : 34436
}

Expired name:
{
"expires_in" : -25024,
"expired" : 1
}
Why not simply say: if expires_in < 1000: raise Bail("Name is about to expire")

phelix
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

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

Re: Changing domain renewal handling

Post by biolizard89 »

phelix wrote:
biolizard89 wrote:Draft spec posted here:

https://wiki.namecoin.info/index.php?ti ... ireWarning

Any comments?
TBH I don't quite get it.

Code: Select all

Unexpired name:
{
"expires_in" : 34436
}

Expired name:
{
"expires_in" : -25024,
"expired" : 1
}
Why not simply say: if expires_in < 1000: raise Bail("Name is about to expire")

phelix
Are you talking about Namecoin-Qt? My spec is aimed to address the use case where the name owner forgets to run Namecoin-Qt.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

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

Re: Changing domain renewal handling

Post by phelix »

I think I understood now what you mean to do with the expires field. It is like a best before date. Why not use a fixed number of blocks forced on all names? Would be way simpler. Does NMControl currently know the block height? It would also have to check whether the blockchain is up to date.

So: NMControl and the like should stop working if a name is about to expire.

Should namecoinq do anything? Include a warning in the reply?
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

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

Re: Changing domain renewal handling

Post by biolizard89 »

phelix wrote:I think I understood now what you mean to do with the expires field. It is like a best before date. Why not use a fixed number of blocks forced on all names? Would be way simpler. Does NMControl currently know the block height? It would also have to check whether the blockchain is up to date.

So: NMControl and the like should stop working if a name is about to expire.

Should namecoinq do anything? Include a warning in the reply?
The ideal value for this field is dependent on the habits of the name owner. If an owner is confident that he will notice an outage within 24 hours, he can set the field to a small value, and therefore not have to renew as often. On the other extreme, if a user is sometimes without access to his wallet for a month at a time, setting the field to 2 months may be desirable (but would require more frequent renewals). A well-designed GUI would make this simple for the name owner to configure.

I don't think NMControl looks at the block height for names, but this is easy to add, I think. Checking if the blockchain is up to date should be done by namecoind/Namecoin-Qt; I think I made a GitHub issue for that.

namecoind shouldn't do anything special in the RPC reply. Namecoin-Qt might want to show 2 "expires in" numbers: the existing one, and the one that this proposal makes.

I'd suggest that the GUI refer to this proposed field as "will black out", and the existing expire date as "control will be lost". If we add auto-renew, then a 3rd field would be labeled as "will renew".
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

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

Re: Changing domain renewal handling

Post by phelix »

Seems relatively complicated to me. Using a fixed blackout period would be much simpler.
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

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

Re: Changing domain renewal handling

Post by biolizard89 »

phelix wrote:Seems relatively complicated to me. Using a fixed blackout period would be much simpler.
I honestly don't think it's very complicated to implement this in NMControl. It's doing a single JSON read of the name's value rather than using a hardcoded string; I think it's only 1-2 lines of extra code.

GUI changes are *slightly* more complex, but it's perfectly doable to put a default value into the GUI if we want.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

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

Re: Changing domain renewal handling

Post by indolering »

biolizard89 wrote: NMControl should stop resolving after N blocks, not N days, otherwise the warning might occur a varying duration before expiration. (Worst case, the hashpower of the network increases fast enough that the warning occurs after expiration.) Also I think the NMControl warning should be configurable by the name owner (via a reserved JSON field).
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.

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.

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.*

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.

Worse case scenario: I screwed up the stats or China decides to become a Namecoin super power and domains start expiring PRIOR to 12 months. 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.

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.

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.

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. By then, we should have auto-renewals figured out and all of the registrars will handle this for their customers anyway.

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.

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

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

Post Reply