name claims: allowing soft-fork to increase name reservation period.

[kilpatty]

I wanted to open an issue to discuss the actual implementation of this change as discussed in #294 and #256. I began implementing this, but wanted to run some design decisions past the community before committing to them.

What needs to be changed:

• Opens are changed to be valid only if the "claimPeriod" has ended.
• Claims are changed to be valid as long as a name has not been opened, rather than if the name is still reserved. See: https://github.com/handshake-org/hsd/blob/master/lib/covenants/rules.js#L699

How we can do this:

• I was trying to discover an easy way to indicate whether a name has been opened or not. I thought that we might have some luck with height being set on name state (See:

  hsd/lib/blockchain/chain.js

  Line 909 in 17db508

  ns.set(name, height);

  ), but in practice when I was querying name state, height would be reset on a name that was opened, but not bid on (See: https://hnscan.com/name/test15).

My thought process is that it might be easier to add a field to name state similar to claimed. It would simply indicate whether or not this name has been opened before, and then we can use that to validate or invalidate claims (opened) (https://github.com/handshake-org/hsd/blob/master/lib/covenants/namestate.js#L60)

Would love to hear some thoughts on if we think this is a good way of approaching the problem, and if so, I'll push up my PR for more review.

[pinheadmz]

Why not call chainDB.getNameState(name) and if the answer is === null then it is ok to claim? (Assuming the name is also on the reserved list, etc)

[kilpatty]

Dang, that is a good point. For some reason I thought that wasn't exactly possible, but I only thought that due to a bug in hnscan :(. That is much much easier than I thought, so will make that change to my PR now.

[pinheadmz]

This will not be addressed. If an attacker acquires a gTLD in four years and misbehaves with it, it will be the responsibility of the user / application layer to blacklist the name at that time. Other options will be available such as a community-supported soft fork or -- who knows what the network will look like in 4 years -- maybe we'll be ready for a unique com on Handshake?!