@larry and I actually came up with this format last night.
It’s:
"blockstack key":<bitcoin-address>:<name-index>
…where the “name index” translates to an index in the list of keys ever owned by this address.
Here’s how it should be interpreted:
- If the name index (N) is “-1” or absent:
- The signing/authentication address is equal to the bitcoin address.
- If the name index (N) is >= 0:
- The name is the Nth name ever owned by the address.
- Walk the name transfer operations of the name. Stop if you see a delete operation. The final address that currently owns the name is the signing/authentication address.
This format was created to solve a few issues:
- A user should be able to create a unique identifier without ever needing to spend coins or send a transaction on the blockchain.
- A user about to register a name should be able to use a unique identifier immediately while waiting for the name registration to go through.
- A user should be able to change addresses/keysets without having to get a unique identifier (and thus start from scratch with app accounts). Put another way, the identifier should be long-lived and should be able to survive compromises of the original keys.
As an added bonus feature, we could even allow users to both rotate keys and update usernames. If a name was sent to an address and then deleted and a new key was registered after that, the ID could be transferred to the new key.
Most systems struggle with being able to have all the following 3 properties for IDs:
- Globally unique
- Decentralized
- Key-rotation friendly
Take a look at existing systems:
- Centralized systems can allow for key changes and name changes because they can keep a centralized DB of UUIDs.
- PGP does not have long-lived identifiers that can survive key changes.
We’re in a very interesting position here because we can offer globally unique IDs in a decentralized way, without requiring money to be spent, without requiring users to wait for hours, and optionally with support for username updating.