Identity protocol v1

Design goals

Decentralized identity.

A SIN ("System Identification Number") is the unique record identifier by which this identity will be known.

Attributes:

• Has some creation cost
• Sacrifice may be digitally proven, bootstrapping root of trust from blockchain data
• Start as anonymous; opt out of anonymity by attaching identifying key-value pairs (real.name = "John Smith", gov.us.ssn = "123-45-6789").
• Forms the basis of distributed reputation systems
• Third parties may offer digital attestions: Identity Verification, Inc. digitally signs a SIN as passing their Not A Criminal/Level-1 check.
• Controlled by the SIN's owner (key holder) at all times.

Creating sacrifice transactions

An implementation of Announce/Commit Sacrifices. That author's feedback on this protocol was very helpful.

1. MPK = master public key
2. TM = current block height
3. Create and sign transaction T2. Broadcast if desired.
   1. must include Hash160(MPK) OP_TRUE anyone-can-spend output with value >= 0.001BTC
   2. nlocktime = TM + 144 blocks
   3. no more than 1000 bytes in size
4. Create, sign and broadcast transaction T1
   1. must include OP_RETURN serialized(T2) output as last txout

Creating a SIN

1. Prefix = 0x18
2. SIN_Version = 0x01, similar to how a UUID's form is dictated by a UUID's self-identified version
3. MD = Hash160(MPK)
4. SIN = base58_encode_check( Prefix + SIN_Version + MD )
5. Hyphenate or space SIN for easier human reading

Validating the root identity information

1. B1 = block w/ T1
2. B2 = block w/ T2
3. Verify B2 height - 144 >= B1 height.
4. Verify announced T2 is valid
5. Verify mined T2 spends same inputs as announced T2 (not equal to account for Transaction Malleability)
6. Fail and waste sacrifice if not.

Thus a minimal root record is MPK and is provably

• linked to the sacrifices
• MPK starts a new chain of digital signature trust, for further record updates

Future work

After creation, the root identity and key-value pairs must be stored $somewhere.

After that root identity is created, additional key-value pairs may be associated with the root record via updates verified by MPK, stored in an alt-blockchain or DHT somewhere. That is outside the scope of this minimal document, at this time.