Identity protocol v1: Difference between revisions

From Bitcoin Wiki
Jump to navigation Jump to search
Jgarzik (talk | contribs)
Jgarzik (talk | contribs)
 
(79 intermediate revisions by 3 users not shown)
Line 3: Line 3:
==Design goals==
==Design goals==


Decentralized identity.
Fully decentralized, anonymous, secure identity.
* 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").


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


==Creating sacrifice transactions==
Attributes:
* Ownership may be digitally proven
* Attach sequence of key-value pairs (public proof) and hashes (private proof) to your SIN record.
** A merkle root exists in each record, for even more private proofs.
* Start as anonymous; opt out of anonymity by attaching identifying key-value pairs (real.name = "John Smith", gov.us.ssn = "123-45-6789").
* Disposable
* All key-value pair updates digitally signed by SIN owner (key holder)
* Third parties may offer digital attestions:
** Identity Verification, Inc. digitally signs a SIN as passing their Not A Criminal/Level-1 check.
** Big Auction Provider, Inc. digitally signs a SIN as having a certain reputation score, on their website.
** Decentralized market users digitally sign one another's SINs, building a decentralized reputation
* Type-1 SINs:  have some creation cost, deterring spam.
* Type-1 SINs: Sacrifice may be digitally proven, bootstrapping root of trust from blockchain data
 
tl;dr: A “master public key” generated by the user forms the root of digital trust.
 
==Types of SINs==
 
===Type 1 (persistent)===
 
SIN_Type 0x01 (bitcoin main chain) or 0x11 (testnet)
 
Type-1 SINs are intentionally scarce resources, much like bitcoins themselves.  All Type-1 SINs must conform to the sacrifice protocol described in this specification, to be considered valid.
 
===Type 2 (ephemeral)===
 
SIN_Type 0x02
 
Type-2 SINs may be generated at any time, without network activity, much like bitcoin addresses.


Similar to [https://en.bitcoin.it/wiki/Fidelity_bonds#Announce.2FCommit_Sacrifices Announce/Commit Sacrifices]
==Definitions==


# MPK = master public key
* MPK: Master Public Key. ECDSA, using same curve as bitcoin (secp256k1).
# TM = current block height
* Hash160: ripemd160(sha256(data))
# create transaction T2.
* base58_encode_check: see bitcoin source code, https://github.com/bitcoin/bitcoin/blob/master/src/base58.h
## must include OP_RETURN ripemd160(MPK) output
## nlocktime = TM + 144 blocks
## no more than 1000 bytes in size
# create transaction T1
## must include >= 0.001 BTC fee
## must include OP_RETURN serialized(T2) output
# broadcast T1, T2 until confirmed


==Creating a SIN==
==Creating a SIN==


A SIN is the unique record identifier by which this identity will be known.
# Prefix = 0x0F
# SIN_Type = [0x01 | 0x02 | 0x11] -- See above for discussion of SIN types.
# MD = Hash160(MPK)
# SIN = base58_encode_check( Prefix + SIN_Version + MD )
# Hyphenate SIN for easier human reading if desired, inserting one hyphen after every 5th character.
 
 
For example, using the compressed public key:
 
<code>
02F840A04114081690223B7069071A70D6DABB891763B638CC20C7EC3BD58E6C86
</code>
 
 
Step 1 (SHA-256 of public key):
 
<code>
: cb05d0fd5e76ba8ea88323fc5d3eefd09a78d8e2a5fd4955307b549657a31330
</code>
 
Step 2 (RIPEMD-160 of Step 1):
 
<code>
: cb1f4a4d793731842732c153b8e9923bdb462553
</code>
 
Step 3 (Prefix + SIN_Version + Step 2):
 
<code>
: 0F02cb1f4a4d793731842732c153b8e9923bdb462553
</code>
 
Step 4 (Double SHA-256 of Step 3):
 
<code>
: 1a4214cdd79f55883263be8118d571c112cd4dbc9f8542d30daebd1231b522e9
</code>
 
Step 5 (Checksum):
 
<code>
: 1a4214cd
</code>
 
Step 6 (Step 5 + Step 3):
 
<code>
: 0F02cb1f4a4d793731842732c153b8e9923bdb4625531a4214cd
</code>
 
SIN (Base58 encoded):
 
<code>
: TfG4ScDgysrSpodWD4Re5UtXmcLbY5CiUHA
</code>
 
==Creating sacrifice transactions==
 
Creation cost is attached to decentralized identity by means of sacrificing a small amount of value.


# Prefix = 0x18
An implementation of [https://en.bitcoin.it/wiki/Fidelity_bonds#Announce.2FCommit_Sacrifices Announce/Commit Sacrifices].  That author's feedback on this protocol was very helpful.
# SIN_Version = 0x01
# MD = ripemd160(MPK)
# SIN = base58_encode_check( Prefix + SIN_Version + MD )


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


==Validating the root identity information==
==Validating the root identity information==


# B1 = block w/ T1, B2 = block w/ T2
# B1 = block w/ T1
# Verify B2 height - 144 >= B1 height. Fail and waste sacrifice if not.
# B2 = block w/ T2
# Verify mined T2 == announced T2
# Verify B2 height - 144 >= B1 height.
# Verify announced T2 is valid
# Verify mined T2 spends same inputs as announced T2 (not equal to account for [[Transaction Malleability]])
# Fail and waste sacrifice if not.
 


Thus a minimal root record is MPK and is provably
Thus a minimal root record is MPK and is provably
Line 44: Line 130:
* MPK starts a new chain of digital signature trust, for further record updates
* MPK starts a new chain of digital signature trust, for further record updates


After that, additional key-value pairs may be associated with the root record via updates verified by PPK, stored in an alt-blockchain or DHT somewhere.  That is outside the scope of this minimal document.
==SIN record==
 
A SIN record is a series of hashes or key/value pairs, validated by MPK digital signature.  Each SIN record has a stable binary encoding designed to ensure stable hash values.  This scheme is intentionally mirroring bitcoin's block header/merkle scheme.
 
Data types:
* uint32_t: an unsigned, little endian integer
* uint256_t: bitcoin-like 256-bit hash value
 
Layout of a SIN record:
* uint32_t magic number (and/or version number) == 0x88, 0x41, 0x92, 0xA4
* uint256_t merkle root
* uint32_t data record count
* [list of data records]
* Signature
 
Layout of a data record:
* uint32_t: record type (== 0x1 for hash, 0x2 for key/value pair)
* [data record-specific data]
 
Layout of a hash data record:
* [32 bytes of hash data]
 
Layout of a key/value data record:
* uint32_t key length
* uint32_t value length
* [key-length UTF8-encoded key]
* [value-length opaque data]
 
Duplicate keys are not permitted.
 
==Implementations==
 
See:
* https://github.com/bitpay/bitauth/blob/master/lib/bitauth.js
* https://github.com/gasteve/node-libcoin/blob/master/SIN.js
* https://github.com/gasteve/node-libcoin/blob/master/SINKey.js
* https://github.com/ionux/phactor/blob/master/src/Sin.php
 
==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.
 
Key attributes of this system, like price and transaction size, are hardcoded.  It is presumed that version 2+ will improve upon this, once field experience is gained and lessons are learned.

Latest revision as of 04:50, 14 May 2015


Design goals

Fully decentralized, anonymous, secure identity.

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

Attributes:

  • Ownership may be digitally proven
  • Attach sequence of key-value pairs (public proof) and hashes (private proof) to your SIN record.
    • A merkle root exists in each record, for even more private proofs.
  • Start as anonymous; opt out of anonymity by attaching identifying key-value pairs (real.name = "John Smith", gov.us.ssn = "123-45-6789").
  • Disposable
  • All key-value pair updates digitally signed by SIN owner (key holder)
  • Third parties may offer digital attestions:
    • Identity Verification, Inc. digitally signs a SIN as passing their Not A Criminal/Level-1 check.
    • Big Auction Provider, Inc. digitally signs a SIN as having a certain reputation score, on their website.
    • Decentralized market users digitally sign one another's SINs, building a decentralized reputation
  • Type-1 SINs: have some creation cost, deterring spam.
  • Type-1 SINs: Sacrifice may be digitally proven, bootstrapping root of trust from blockchain data

tl;dr: A “master public key” generated by the user forms the root of digital trust.

Types of SINs

Type 1 (persistent)

SIN_Type 0x01 (bitcoin main chain) or 0x11 (testnet)

Type-1 SINs are intentionally scarce resources, much like bitcoins themselves. All Type-1 SINs must conform to the sacrifice protocol described in this specification, to be considered valid.

Type 2 (ephemeral)

SIN_Type 0x02

Type-2 SINs may be generated at any time, without network activity, much like bitcoin addresses.

Definitions

Creating a SIN

  1. Prefix = 0x0F
  2. SIN_Type = [0x01 | 0x02 | 0x11] -- See above for discussion of SIN types.
  3. MD = Hash160(MPK)
  4. SIN = base58_encode_check( Prefix + SIN_Version + MD )
  5. Hyphenate SIN for easier human reading if desired, inserting one hyphen after every 5th character.


For example, using the compressed public key:

02F840A04114081690223B7069071A70D6DABB891763B638CC20C7EC3BD58E6C86


Step 1 (SHA-256 of public key):

cb05d0fd5e76ba8ea88323fc5d3eefd09a78d8e2a5fd4955307b549657a31330

Step 2 (RIPEMD-160 of Step 1):

cb1f4a4d793731842732c153b8e9923bdb462553

Step 3 (Prefix + SIN_Version + Step 2):

0F02cb1f4a4d793731842732c153b8e9923bdb462553

Step 4 (Double SHA-256 of Step 3):

1a4214cdd79f55883263be8118d571c112cd4dbc9f8542d30daebd1231b522e9

Step 5 (Checksum):

1a4214cd

Step 6 (Step 5 + Step 3):

0F02cb1f4a4d793731842732c153b8e9923bdb4625531a4214cd

SIN (Base58 encoded):

TfG4ScDgysrSpodWD4Re5UtXmcLbY5CiUHA

Creating sacrifice transactions

Creation cost is attached to decentralized identity by means of sacrificing a small amount of value.

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

  1. MPK = master ECDSA public key (compressed)
  2. BH = 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 = BH + 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

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

SIN record

A SIN record is a series of hashes or key/value pairs, validated by MPK digital signature. Each SIN record has a stable binary encoding designed to ensure stable hash values. This scheme is intentionally mirroring bitcoin's block header/merkle scheme.

Data types:

  • uint32_t: an unsigned, little endian integer
  • uint256_t: bitcoin-like 256-bit hash value

Layout of a SIN record:

  • uint32_t magic number (and/or version number) == 0x88, 0x41, 0x92, 0xA4
  • uint256_t merkle root
  • uint32_t data record count
  • [list of data records]
  • Signature

Layout of a data record:

  • uint32_t: record type (== 0x1 for hash, 0x2 for key/value pair)
  • [data record-specific data]

Layout of a hash data record:

  • [32 bytes of hash data]

Layout of a key/value data record:

  • uint32_t key length
  • uint32_t value length
  • [key-length UTF8-encoded key]
  • [value-length opaque data]

Duplicate keys are not permitted.

Implementations

See:

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.

Key attributes of this system, like price and transaction size, are hardcoded. It is presumed that version 2+ will improve upon this, once field experience is gained and lessons are learned.