Changing domain renewal handling

[biolizard89]

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.

Cool. Anyone else have comments on this proposal? Would be nice to get it added to the spec in a week or two if there aren't any objections.

[indolering]

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?

Ahh, but this doesn't solve it for anyone NOT using NMControl and given how well documented/integrated NMControl is... And if you have direct access to the blockchain anyway, why not just keep tabs on expires in real time?

I'm just going to crunch the numbers and figure out the amount of variance. Then we can come up with some nth percentile number and use that as the expire value.

Could we make a change on the the next hard/soft fork to improve the recalibration algorithm?

[biolizard89]

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?

Ahh, but this doesn't solve it for anyone NOT using NMControl and given how well documented/integrated NMControl is... And if you have direct access to the blockchain anyway, why not just keep tabs on expires in real time?

I'm just going to crunch the numbers and figure out the amount of variance. Then we can come up with some nth percentile number and use that as the expire value.

Could we make a change on the the next hard/soft fork to improve the recalibration algorithm?

Um, then people should start using NMControl. Why reimplement all of that yourself? Documenting NMControl is far safer than patching namecoind. namecoind should stay as simple as feasible, i.e. anything that can be implemented at the NMControl level should be done there.

[indolering]

Um, then people should start using NMControl. Why reimplement all of that yourself? Documenting NMControl is far safer than patching namecoind. namecoind should stay as simple as feasible, i.e. anything that can be implemented at the NMControl level should be done there.

I think we are on two slightly different trains of thought ....

I was trying to emulate a world in which we could rely on the underlying dates and I was proposing just figuring out sane defaults for the renewal period, akin the the analysis I did on minimum pricing. Have 1 year + enough padding to ensure someone has a week or whatever to reorder with 99% confidence. Then client just stop resolving at one year.

I'm not familiar with this statistical analysis so I will wait to post any definitive analysis until after I'm told what to use. The hash rate is not deterministic, but it's a very constrained range of values and we only need to ensure we have enough time to reorder. Using some adapted stock inventory calculations, we would need to pad some 33 days with really, really high confidence values. We can emulate the existing domain purchaing cycle really, really well.

And that's great for consumers because it's just like purchasing a normal domain!

However, at an API level, you are totally right. No lite client would go more than an hour or so without a refresh, so I agree in that we should just handle this at the client API level. The most logical thing is probably just to do as you suggest and stop resolving a domain X blocks before the actual expiration.

For browser clients, we should just hand them a record which redirects to an official page about renewing the domain. I don't think we need to add anything into the Namecoin specification.

What the "client API level" means is in flux. You use NMControl, but that's not documented and the VAST majority of API's for Namecoin are simple adaptations of Bitcoin RPC libraries. I'm basically not using NMControl because of those two items and so that's why I was advocating for implementation in Namecoind. We will converge on a standard client API eventually.

[biolizard89]

Um, then people should start using NMControl. Why reimplement all of that yourself? Documenting NMControl is far safer than patching namecoind. namecoind should stay as simple as feasible, i.e. anything that can be implemented at the NMControl level should be done there.

I think we are on two slightly different trains of thought ....

I was trying to emulate a world in which we could rely on the underlying dates and I was proposing just figuring out sane defaults for the renewal period, akin the the analysis I did on minimum pricing. Have 1 year + enough padding to ensure someone has a week or whatever to reorder with 99% confidence. Then client just stop resolving at one year.

I'm not familiar with this statistical analysis so I will wait to post any definitive analysis until after I'm told what to use. The hash rate is not deterministic, but it's a very constrained range of values and we only need to ensure we have enough time to reorder. Using some adapted stock inventory calculations, we would need to pad some 33 days with really, really high confidence values. We can emulate the existing domain purchaing cycle really, really well.

And that's great for consumers because it's just like purchasing a normal domain!

However, at an API level, you are totally right. No lite client would go more than an hour or so without a refresh, so I agree in that we should just handle this at the client API level. The most logical thing is probably just to do as you suggest and stop resolving a domain X blocks before the actual expiration.

For browser clients, we should just hand them a record which redirects to an official page about renewing the domain. I don't think we need to add anything into the Namecoin specification.

What the "client API level" means is in flux. You use NMControl, but that's not documented and the VAST majority of API's for Namecoin are simple adaptations of Bitcoin RPC libraries. I'm basically not using NMControl because of those two items and so that's why I was advocating for implementation in Namecoind. We will converge on a standard client API eventually.

I'm willing to write some docs for NMControl if no one else does it before I find the time.

As an aside... in Bitcoin, it is possible to use real-world times to specify expiration, rather than block numbers (in particular with the nLockTime feature). How secure is this? I'm assuming it's not at all secure (I vaguely recall that the time-based nLockTime only applies to the isStandard check rather than block validation)... am I correct there?

[indolering]

As an aside... in Bitcoin, it is possible to use real-world times to specify expiration, rather than block numbers (in particular with the nLockTime feature). How secure is this? I'm assuming it's not at all secure (I vaguely recall that the time-based nLockTime only applies to the isStandard check rather than block validation)... am I correct there?

Would you mind posing this question on the dev mailing list?

I think this whole thread points to the need to integrate NMControl or another middleware into our default deployment packaging. This sort of stuff needs to be handled at that layer.

[John Kenney]

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.

Cool. Anyone else have comments on this proposal? Would be nice to get it added to the spec in a week or two if there aren't any objections.

Sounds like a good idea. I'd like to see an expiration warning in whatever new GUI is used for registering names too.

[indolering]

I checked with Midnightmagic and s/he confirmed that the timestamps will be off by an order hours. I propose the following:

• Refactor renewal period to 60,000 blocks (~13.5 months).
• Have the middleware stop resolving at 1 year from the initial registration date.
• Allow renewals to occur either after the 11 month timestamp or 50,000 blocks, whichever occurs first.

This, of course, assumes that we have worked out renewal fess and the anyone pays renewal scheme.

[tosh0]

I checked with Midnightmagic and s/he confirmed that the timestamps will be off by an order hours. I propose the following:

• Refactor renewal period to 60,000 blocks (~13.5 months).
• Have the middleware stop resolving at 1 year from the initial registration date.
• Allow renewals to occur either after the 11 month timestamp or 50,000 blocks, whichever occurs first.

This, of course, assumes that we have worked out renewal fess and the anyone pays renewal scheme.

i strongly agree with all this, a dependable fee scheme should be worked out.

here i attach an .xls excel file i made with various proposals for future name-new and tx fees.
(slash the name-new price in half every halving and the tx fee in half or /4)
and their effects in the USD value of name-new and tx fee.
(the nmc price is highly speculative thought)
name-renew and name-update should be the same as name-new i guess, that i can't comment.

your comments

[biolizard89]

I checked with Midnightmagic and s/he confirmed that the timestamps will be off by an order hours. I propose the following:

• Refactor renewal period to 60,000 blocks (~13.5 months).
• Have the middleware stop resolving at 1 year from the initial registration date.
• Allow renewals to occur either after the 11 month timestamp or 50,000 blocks, whichever occurs first.

This, of course, assumes that we have worked out renewal fess and the anyone pays renewal scheme.

I'm fine with extending renewal period in namecoind, although since this is presumably a hardfork care should be taken to do it right.

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 enoughh that the warning occurs after expiration.) Also I think the NMControl warning should be configurable by the name owner (via a reserved JSON field).