Discussion: name expiration periods

[shea256]

We've noticed one topic that keeps coming up - the name expiration period for the .id namespace.

The name expiration period for the .id namespace (which is meant to be used for personal usernames) was initially set for 1 year, which means that names would expire after a year if they weren't renewed.

While this period seems to work very well for domain names, some have argued that it is an undue burden for users to have to renew their usernames after a year. Based on this, we'd like to ask the community whether the expiration period for .id or some other namespace for usernames should be 1 year, 2 years, or more.

Keep in mind that this parameter is a tradeoff between (1) the convenience of users to not to have to renew their names very often and (2) the ability for the system to turnover unused usernames. With this in mind, please answer the poll question below.

What should the name expiration period be for a namespace for people and their usernames?

• 1 year
• 1.5 years
• 2 years
• 5 years
• Infinity years (names never expire)
• Other

[rjstone]

I agree. Something like an identity should generally follow the lifetime of whatever it is identifying. It would probably be a little too dystopian to consider a blockstack ID to be like a birth certificate that never expires, especially since it's allocated out of a unique namespace, and it has symbolic meaning unlike an ID number (like an SSN), but perhaps it should be treated more like a driver's license.

I don't know how driver's licenses work everywhere but I think that first time drivers get licenses that expire sooner than someone who has renewed their license one time. Perhaps a capped exponentially increasing renewal period would be appropriate.

So say that after initial creation, the ID goes into a hold down period after one year at which point someone has period/4 (3 months in this case) amount of time to renew it. If they renew it then the expiry time increases to 5 years and they have another period/4 amount of time to renew it. If they renew it again then it increases to 10 years. After that it's either capped at 10 years or increases to 20.

At this point I still know almost nothing about blockstack or block chain protocols in general, so I don't know how difficult this would be to manage or enforce cryptographically. But there's my naive suggestion.

(Edit: part of the usefulness of a hold down period, or whatever you call it, is that it puts into question whether or not the person still exists without writing them off immediately. This could be used to assign a lower trust level to the ID and possibly trigger other heuristics that look for other evidence of whether anyone is still there. This state would also discourage renewal procrastination.)

[csuwildcat]

This issue is a multi-headed hydra, so I'll try to address each aspect in segments:

Expiration is uniquely perilous in a system without restorative overrides.

Because IDs cannot be forcibly taken in this system (good), they are also ~permanently lost once acquired by another entity (potentially very bad). The vision is that this system's IDs will come to serve as the most prominent and long-lasting form if identifier/identity anchor the user ever owns. Because of this the stakes are very high.

Signing to IDs, not keys, is a blessing and a curse

To rid ourselves of the need for attestation and data resigning loops in coordination with the entities the user has accumulated signed payloads from, it is desirable to have attestations and data signed in relation to the ID, not a key. This is great for many parts of the system UX/ops, but puts an even greater burden on retaining control of your ID, as a irrevocable loss of control becomes far more damaging to the individual.

I'm always skeptical of subjective thresholds and intervals

Why is the chronological progression of renewal the right basis, even if we think it could provide some of benefits we want? I understand the inference of essentially testing the user's resolve with timed ownership challenges, then rewarding with extensions, but is that the best we can do? I always like to see systems based on more deterministic mechanisms, checks, or validations, or no renewal at all (unless an ID was voluntarily released).

I can't really provide a solid answer yet about the time strategy, because I need to think for a while on whether there is any more accurate, empirical, objective basis to achieve the goals, or if renewal should be required at all.

Note: If valuable names cost way more to begin with, it would mitigate some of the need for renewal.

[cpacia]

I would probably prefer infinite.

[ChairmanTubeAmp]

Is it possible to set a TTL on an individual record? Then you could ask the user upon creation of the record. Fees could be set accordingly.

[rjstone]

I'd need to do some more thinking about using attention vs surrendering value as proof for this particular purpose, but I wanted to point out that while, from a mathematical perspective, a period like 1 year or 1 month is totally arbitrary, these time periods track ubiquitous billing cycle periods for continuous services in real life. Basically, people are used to having to pay and renew things in these increments. So they track with existing legal contracts, habits people are used to, etc. x/4 is rather arbitrary but probably tracks a typical time period after which unpaid bills are turned over to collections, at least if x = 1 year.

[drwasho]

I think from a protocol perspective, I'd allow users to indicate how long they'd like to register their name. This allows unsure users to register for 3 months or whatever, while power users who know what they're getting into can create 'infinite' identities.

[parkan]

I like the idea of exponentially increasing registration length with repeated registration (i.e. continuous use)

I would also like to see a tombstone mechanism where expired ids and their associations are archived to address problems like Signing to IDs, not keys, is a blessing and a curse in @csuwildcat's comment

[csuwildcat]

If you pursue any timed renewal/forfeiture scheme, I believe it should at least include the following:

1. The system should throw warnings on GET of an ID that it is nearing expiration, so the app/service receiving the resolved payload can choose to notify the user (in the case it is their ID) or log it for the developer.
2. The system should have two phases of expiration:

Phase 1: The system detaches the zone file from the ID and renders it unresolvable, but ensures the ID is still under the ownership of the user (no one else can take it yet). This will cause just about everything to break for the user of the ID, and is a last ditch signal for them to handle their shit or lose what could literally amount to every attestation they have accumulated in life - the impact of this cannot be understated.

Phase 2: If the user does not comply within X time after the disconnect of their name from their data, the name is released into circulation.

Thoughts?

[muneeb-ali]

I'm all for long expiry (at least 2 years, and up to 5 years). The only thing that bothers me is that if a name is "lost" (i.e., the user no longer has access) then it won't expire and no one will be able to grab it. That's a downside, but maybe we can live with that. Every option is going to have pros and cons.

Another idea is to make name renewals free, but you need to show activity by doing a "renew" transaction (and anyone can pay the transaction fee e.g., some company you use to manage your ID). So registration fee for renewals is $0 and anyone can pay the transaction fee.

[jcnelson]

Regarding @csuwildcat's concerns about losing your ID, one way to provide "proof of continuity of identity" would be to put a signed video of yourself in your profile reciting the history of past IDs that you've owned. So for example, in my video you'd see me say something like "Hi, I'm judecn.id, but before that, I was jude.id, and my old address was XXX. My current address is YYY." I'd put the hash of the video into my name's zonefile, so you'd be sure that you got the latest such video.

[invix]

I like the idea of a longer than one year registration. Somewhere in the range of 2-5 years seems ideal. The 10-20 range seems far too long, and infinite is just a bad idea all around.

It may be best to somewhat follow domain registrations where you can register initially for 2 years or so, and then have the option to extend it up to something like 5 years for an additional fee.

People forgetting to renew will always be an issue, and having a "redemption period" like domains do and @csuwildcat noted would help with that. When the id expires, any client should treat any data for that id as invalid and notify the client. That way they are notified something is wrong if they are still using the id. However, the id will not be available to be registered by someone new for 6 months or so during which it can still be renewed by the original owner.

There could also be services in the future that could help by checking name expiration and reminding users via email to renew before the id expires.

[guylepage3]

I like the idea of a longer than one year registration. Somewhere in the range of 2-5 years seems ideal. It may be best to somewhat follow domain registrations where you can register initially for 2 years or so, and then have the option to extend it up to something like 5 years for an additional fee.

@invix +1

[john-light]

I think from a protocol perspective, I'd allow users to indicate how long they'd like to register their name. This allows unsure users to register for 3 months or whatever, while power users who know what they're getting into can create 'infinite' identities.

@drwasho +1. For the .id namespace (or whatever the "main" namespace will be) I would also prefer making the pricing cheaper for shorter periods (so people can try out the system or the name for size) and more expensive (within reason) for no expiration. I expect there to be entities with blockchain IDs that have the ability to be (virtually) immortal, and they should be able to have a name forever without worrying about it expiring should they be away from the internet for a while.

[rjstone]

Here's another idle thought that might address the desire to not lose valuable .ids, allow for near-infinite expiration periods, and possibly address the desire to have unused .ids expire after a time. What if the expiry time were calculated according to some sort of function like x^y where x could be BTC value, number of attestations, or something related to use or value while y... well, I don't know. Possibly some sort of constant.

The goal would be for an .id to expire rather quickly if unused but last effectively forever if used even a "moderate" amount. I have no idea how to come up with the math for this or what to base it on though.

[csuwildcat]

I was also going to suggest a system where the attestations of known entities bypassed expiration/renewal, but in the past some folks have said using external entities as a basis for evaluation would make the system more centralized. I disagree, and like you I believe it's a far more accurate, empirical way to assess legitimacy and usage.

On Sep 28, 2016 9:44 PM, "Robert Stone" notifications@github.com wrote:

Here's another idle thought that might address the desire to not lose valuable .ids, allow for near-infinite expiration periods, and possibly address the desire to have unused .ids expire after a time. What if the expiry time were calculated according to some sort of function like x^y where x could be BTC value, number of attestations, or something related to use or value while y... well, I don't know. Possibly some sort of constant.

The goal would be for an .id to expire rather quickly if unused but last effectively forever if used even a "moderate" amount. I have no idea how to come up with the math for this or what to base it on though.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/blockstack/blockstack-core/issues/244#issuecomment-250369089, or mute the thread https://github.com/notifications/unsubscribe-auth/AAICyi7Pe4RH6LfArUKiShAwq0KGAj1tks5qu0JJgaJpZM4KHUke .

[shea256]

Thanks everyone! I'd like to summarize the ideas posted so far and present my assessments:

@rjstone: Names should go into hold down periods after their expiration date

This makes a lot of sense. And the hold down period should be a fraction of the expiration period that is >= 1/12 and <= 1/4.

@rjstone: Name renewal periods should be exponentially increasing

This complicates things. It becomes harder to track and reason about periods across names. I generally prefer simpler solutions. Thus I'd advise against this.

@ChairmanTubeAmp: Users should be able to set their expiration period by paying the base registration fee multiple times

I would support this as long as the minimum period is a large enough period, like 1 year. It is essentially saying one can pay 10x up front to not have to renew the name for 10 years instead of 1 year.

@parkan: If names expire, they should be "tombstoned" instead of being released back into the wild

This makes sense for usernames. I'd support this if (1) it was combined with @rjstone's hold down period system (2) users could un-tombstone their names by renewing again. This goes against the idea of having names released into circulation of course, so it's a tradeoff.

@csuwildcat: Names that have passed their expiration period should be detached from their zone files and rendered unresolvable

Totally agree with this.

@muneeb-ali Have a finite expiration period like 1, 2 or 5 years but remove the cost, so only transaction fees need to be paid

This is nice because it reduces the amount of money required to stay active. It doesn't address the "sleeper user" issue, though. It depends what we want to optimize for. This may be a happy medium.

@jcnelson Video attestations could be used to provide continuity between lost accounts and new accounts

This could be useful at a higher level, as long as there's some ability for identities to be defined with human judgement. It highly depends on the use case. The protocol itself, though, has no knowledge of these attestations and thus I'd say it's an application-specific concern. There's no way to have a sovereign identity transfer continuity to another sovereign identity that is not linked in history at the protocol level. That said, one could use attestations like video attestations and in person testimonies and fingerprints and signatures and such in situations where officials have the ability to exercise judgement and update identity records.

@rjstone Expiry time could be variable and based on the number of attestations

The protocol level has no knowledge of attestations, nor should it. It's an higher application-level detail. Violating this would remove a guarantee of state consistency across nodes and would open up a lot of attack vectors. Thus it should be avoided.

[shea256]

I'd like to nudge everyone in the direction of simplicity.

Here are a two options I can think of that have synthesized your feedback (one is actually much simpler than the other):

1. Names expire after a minimum of 1 year. Multiple years can be paid for up front. After the expiration period names may enter a lockdown period of 2 months, during which they may still be renewed.
   1. They can then expire and can be picked up again
   2. They can then be tombstoned and can be renewed and reactivated.
2. Names don't expire. They just cost 2x or 3x what they otherwise would have cost for a 1 year period (squatting disincentive) and then they can be kept forever. Simple logic. No weird rules. You just register a name and you have it until you lose your private key.

[shea256]

I'd also note that I like the idea of non-expiring names only for usernames. Domain names definitely should have a reasonable expiration period (1 year, more or less).

Another way to look at this is that user ID numbers should be long lasting, but usernames should be changeable. This is how Facebook and Twitter work. You get a permanent ID number you can't ever change. But you can always change your username. It's for this reason that I kind of like @ChristopherA's idea of having 1 namespace for registering user ID #'s and 1 namespace for mapping usernames to these ID #'s.

That said, this greatly overcomplicates things and it should be avoided.

[shea256]

@waynevaughan @jprichardson @hoffmabc @demibrener would love your input on this as well.

[demibrener]

Both options give users the convenience to not have to renew their names very often: either by paying for many years up front (1), or by buying and keeping it forever (2). In the long run, option 1 will be more expensive though.

But what happens if you lose your private key? If I understood correctly, in case 2 you would lose your name forever. While, in case 1, you would have the option to un-tombstone it after the upfront payment period ends. If that's the case, I prefer option 1.

I also don't know if there will be any data or wallet associated to usernames, and what would happen when they are tombstoned (or un-tombstoned).

[shea256]

@demibrener thanks for the input!

In option 1-i, you can pick up your name again as long as a squatter doesn't beat you to it. In option 1-ii, featuring tombstoning, there is no way to get your name back. It's gone.

[waynevaughan]

I agree with many of the previous proposals. Here's my input:

First time registrations are fixed at a one year. This sets a clear expectation that the registration must be renewed. A fixed time period simplifies pricing registrations. This approach gives a disincentive to squatters by forcing them to do work to lock up large sets of identities for long periods of time.

Authentications within 90 days of expiration should return a renewal notice This could be standardized at the protocol level such that a renewal notice is returned, a link to renewal instructions is included, and the application knows that the user is in the expiration period. This gives application developers a hook to remind users to renew.

First time renewals occur within 90 days of the expiration I think this is a sufficiently long period for convenience, yet still creates a sense of urgency.

Renewals should be for two years This is a long enough period to not be inconvenient for users. A relatively short renewal period reduces the likelihood of squatters locking up identities for long periods of time. The renewal period can be extended in future updates to Blockstack.

Expired identities should be locked up for 90 days During this time period, the identity can be renewed by the original owner for double the renewal cost. After 90 days, the identity can be registered by another owner.

Expired identities can only be renewed for 1 year This is an additional penalty and reinforces the expectation that registrations must be renewed.

Registrations get a unique identifier This unique identifier helps differentiate between separate owners of the same identity. All identity attestations, events, data, etc. should be mapped to the unique identifier. Perhaps multiple identities should be able to map to the same unique identifier.

A lot of UX problems can be solved if registration and renewal rules are clear. If possible, map a payment address to each identity. This would allow the renewal process to be seamless. The W3C is currently working on some payment standards. This might eventually be useful.

[csuwildcat]

In terms of recovery, @shea256, can we at least include a passphrase-centric multi-sig recovery transaction at the onset to ensure there is at least a last ditch means to reacquire the keys necessary to control the identity regardless of expiration or other loss?

[shea256]

@csuwildcat Definitely. The key is to set up an advanced multi-sig arrangement from the outset, with a multi-sig arrangement of owner keys, admin keys and recovery keys.

But if all your keys are gone, including your recovery keys, you fall back to broadcasting the revocation certificate to accelerate the tombstoning of your account.

If all these are lost, you're done. But there can be many levels of protection and recovery.

[ChristopherA]

I think that having a unique root identifier (non-name) that is persistent and that is available separate from any name registration is very important. I'm working on a bitcoin-only hack (no layer 2) that uses P2PKH transactions with a short URL in the op_return that points to a self-signed verified claim signed by the revealed P2PKP public key, as well as some coloredcoin-like tricks for key rotation, that allows for a did:{method}:{uuid} that is minimally sufficient as a trust anchor for bootstrapping web-of-trust verifiable claims without a name/nym registration. I'd love for both Blockstack and uProve to support their own different methods for a did:{method}:{uuid} and use them as their own root identifiers that like the bitcoin-only one are persistent, that then allow each to bootstraps into their own different name registration approaches.

[shea256]

@waynevaughan I like a lot of those details but it still seems more complicated than it could be.

Several people have pointed out that it's better for user identities / usernames to be long-lived, rather than expiring by default in a year (as opposed to domain names). Account info can easily be cleared even in the case of a private key compromise, as users can just delete their signed statements that make up their profile.

One thing I like about unlimited lifetimes is it heavily simplifies the system. And we only need it to apply to this namespace. Entire mechanics around renewals can be avoided and software for users is simpler.

What do you think of this? What do you think of periods longer than a year but shorter than infinity?

[shea256]

@christophera Thanks for jumping in!

We actually do have unique root identifiers for entities. Every name registered gets its own 9+ digit number like 432121-347 which indicates the block number and transaction number where the entity was originally registered.

We've also planned on a "rename" operation where users could keep the same ID and change their username.

[waynevaughan]

@shea256 I see it as a tradeoff.

The easiest thing for you is to allow permanent ID registrations for a one time costs. This makes your life easy, but it sucks for everyone else. ;)

A fixed registration period of one year reinforces that identities have a cost and that they need to be renewed. Registering a identity for 10 years at a low cost encourages speculators and the development of a secondary identity market.

Whatever you decide, I recommend keeping it simple. You know best.

[csuwildcat]

@ChristopherA: I am interested in hearing your response to @shea256 to understand if their DID underpinning for registrations fits your requirements.

@shea256: shouldn't DIDs follow a format that is decoupled from any association with a specific, decentralized system (in this case, a certain blockchain), like your block + txn # scheme does?

[shea256]

@csuwildcat This conversation will go down a rabbit hole.

Let's have a discussion on DIDs here: https://github.com/blockstack/blockstack-core/issues/245.

[shea256]

OK it looks like we have several different perspectives and we must reconcile them.

I've distilled the comments down to a few core principles for us to balance:

• Allow users to get evergreen identifiers with minimal work
• Ensure users can get fairly desirable names by providing sufficient monetary disincentives to squatting and providing a mechanism for name recycling
• Allow users to detach all identity info from registered names, irrespective of their expiration periods

In the long term, here's a model that I believe would most appropriately fit these principles:

• All users get long-lived numerical IDs that look like this: 432121-347. Even when their names expire, they keep their numerical IDs forever.
• Users have usernames that last a certain amount of time and then expire. Their clients warn them within 3 months of their name expiration date and can auto-renew if they already loaded up with Bitcoins. Names stop resolving within 2 weeks of their expiration date. This is a more intense warning for users to push them to renew.

In order to accomplish this, I propose two phases:

Phase 1 (Blockstack Core 0.14)

• Simple short-term extension: we update the name period to 2 years.

Phase 2 (Blockstack Core 0.15)

• We update all clients so that they give a 3 month warning to users to either (a) manually renew their names or (b) enable auto-renewals and load up with Bitcoins.
• We update the rules for numerical IDs so that they are placed in a completely separate object class from names. That is, zero, one or many names can map to a single numerical ID.
• We add resolution endpoints for numerical IDs to all Blockstack explorers. In addition, we allow users to register evergreen numerical IDs without having to pick a name.
• We allow users to pay for multiple renewal periods up front.

Note: name recycling was chosen in favor of tombstone-ing (one can only have one or the other).

With this I believe we are able to reconcile everyone's preferences. Please let me know your thoughts.

[jcnelson]

+1 for @shea256's proposal.

[muneeb-ali]

I really like the idea of separating it into two phases and explicitly tackling the numerical ID (that doesn't expire) issue in the second phase. Once this is rolled out, everyone should be happy :-)

+1 for sure.

[csuwildcat]

Sounds good to me.

[invix]

I like most of this, but have a question about this part:

"Names stop resolving within 2 weeks of their expiration date. This is a more intense warning for users to push them to renew."

Is this 2 weeks BEFORE the expiration date? If so, this would be counter-intuitive as people would generally expect the names to stop working on the expiration date/block. It would be better if there was a 2 week or longer grace/redemption period AFTER expiration where the user can still renew the name before it becomes available for anyone to register again.

[shea256]

With this proposal, @rjstone's hold down period will be adopted, @csuwildcat will get his warnings on resolution plus two phases of expiration, @cpacia will get a longer period for names as well as evergreen numerical IDs, @drwasho and @ChairmanTubeAmp and @john-light will get the ability to pay for multiple periods up front, @invix will get his 2-5 year initial range, and @ChristopherA will have the ability to work with users that only have numerical IDs and not pickable names. It also looks very similar to @waynevaughan's proposal, where renewal periods are 2 years and hold down periods last 90 days.

@invix yes great point. We can make the period start after the official expiration date.

[ChristopherA]

On Mon, Oct 3, 2016 at 3:29 PM, Ryan Shea @shea256 wrote:

"and @ChristopherA will have the ability to work with users that only have numerical IDs and not pickable names.

A question — is it possible to make that number also work without using your Layer 2?

For instance, say by using the public key from a spent P2PKH transaction with colored coin like op_return and very short url or IPFS object has, that results in a self-signed verified claim of that that same public key? This has been what I've been thinking about for a minimal DID. For Blockstack purposes, the op_return would point to your Layer 2.

[jcnelson]

Is this 2 weeks BEFORE the expiration date? If so, this would be counter-intuitive as people would generally expect the names to stop working on the expiration date/block. It would be better if there was a 2 week or longer grace/redemption period AFTER expiration where the user can still renew the name before it becomes available for anyone to register again.

Version 0.17 (hard fork of 0.17) adds a 5000-block name expiration grace period, whereby the owner can send a NAME_RENEWAL transaction but do nothing else. The name will not resolve during the grace period.

[jackzampolin]

We have addressed this. If anyone would like to continue this discussion please re-open this issue.

[ChristopherA]

So in the end, is there a unique, unamamed value that can serve as a DID?

[jackzampolin]

@ChristopherA Yup! The name address. Its the same format as a BTC address.