Bitcoin Wiki - User contributions [en]

Identity protocol v1

2015-05-14T04:50:27Z

Jgarzik: /* Implementations */

==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==

* MPK: Master Public Key. ECDSA, using same curve as bitcoin (secp256k1).
* Hash160: ripemd160(sha256(data))
* base58_encode_check: see bitcoin source code, https://github.com/bitcoin/bitcoin/blob/master/src/base58.h

==Creating a SIN==

# 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.

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.

# 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==

# B1 = block w/ T1
# B2 = block w/ 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
* 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:
* 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.

Identity protocol v1

2014-09-14T19:31:49Z

Jgarzik: /* Creating a SIN */

==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==

* MPK: Master Public Key. ECDSA, using same curve as bitcoin (secp256k1).
* Hash160: ripemd160(sha256(data))
* base58_encode_check: see bitcoin source code, https://github.com/bitcoin/bitcoin/blob/master/src/base58.h

==Creating a SIN==

# 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.

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.

# 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==

# B1 = block w/ T1
# B2 = block w/ 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
* 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
https://github.com/gasteve/node-libcoin/blob/master/SIN.js
https://github.com/gasteve/node-libcoin/blob/master/SINKey.js
https://github.com/ionux/php-ectools/blob/master/ecsingen.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.

Identity protocol v1

2014-09-14T19:12:46Z

Jgarzik: /* Design goals */

==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==

* MPK: Master Public Key. ECDSA, using same curve as bitcoin (secp256k1).
* Hash160: ripemd160(sha256(data))
* base58_encode_check: see bitcoin source code, https://github.com/bitcoin/bitcoin/blob/master/src/base58.h

==Creating a SIN==

# Prefix = 0x0F
# SIN_Type = [0x01 | 0x02 | 0x11] -- See below 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.

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.

# 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==

# B1 = block w/ T1
# B2 = block w/ 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
* 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
https://github.com/gasteve/node-libcoin/blob/master/SIN.js
https://github.com/gasteve/node-libcoin/blob/master/SINKey.js
https://github.com/ionux/php-ectools/blob/master/ecsingen.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.

Identity protocol v1

2014-09-14T19:11:19Z

Jgarzik: /* Design goals */ merkle mention

==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.
** One or more of theese hashes may be the root of a merkle tree, enabling 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==

* MPK: Master Public Key. ECDSA, using same curve as bitcoin (secp256k1).
* Hash160: ripemd160(sha256(data))
* base58_encode_check: see bitcoin source code, https://github.com/bitcoin/bitcoin/blob/master/src/base58.h

==Creating a SIN==

# Prefix = 0x0F
# SIN_Type = [0x01 | 0x02 | 0x11] -- See below 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.

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.

# 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==

# B1 = block w/ T1
# B2 = block w/ 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
* 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
https://github.com/gasteve/node-libcoin/blob/master/SIN.js
https://github.com/gasteve/node-libcoin/blob/master/SINKey.js
https://github.com/ionux/php-ectools/blob/master/ecsingen.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.

Identity protocol v1

2014-09-14T19:09:56Z

Jgarzik: /* Design goals */ Secure Identity Number

==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.
* 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==

* MPK: Master Public Key. ECDSA, using same curve as bitcoin (secp256k1).
* Hash160: ripemd160(sha256(data))
* base58_encode_check: see bitcoin source code, https://github.com/bitcoin/bitcoin/blob/master/src/base58.h

==Creating a SIN==

# Prefix = 0x0F
# SIN_Type = [0x01 | 0x02 | 0x11] -- See below 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.

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.

# 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==

# B1 = block w/ T1
# B2 = block w/ 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
* 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
https://github.com/gasteve/node-libcoin/blob/master/SIN.js
https://github.com/gasteve/node-libcoin/blob/master/SINKey.js
https://github.com/ionux/php-ectools/blob/master/ecsingen.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.

Identity protocol v1

2014-09-14T19:01:54Z

Jgarzik: /* SIN record */ no longer under "heavy development"

==Design goals==

Fully decentralized, anonymous, secure identity.

A SIN ("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.
* 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==

* MPK: Master Public Key. ECDSA, using same curve as bitcoin (secp256k1).
* Hash160: ripemd160(sha256(data))
* base58_encode_check: see bitcoin source code, https://github.com/bitcoin/bitcoin/blob/master/src/base58.h

==Creating a SIN==

# Prefix = 0x0F
# SIN_Type = [0x01 | 0x02 | 0x11] -- See below 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.

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.

# 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==

# B1 = block w/ T1
# B2 = block w/ 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
* 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
https://github.com/gasteve/node-libcoin/blob/master/SIN.js
https://github.com/gasteve/node-libcoin/blob/master/SINKey.js
https://github.com/ionux/php-ectools/blob/master/ecsingen.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.

Identity protocol v1

2014-09-14T19:01:04Z

Jgarzik: /* Design goals */ prettyify

==Design goals==

Fully decentralized, anonymous, secure identity.

A SIN ("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.
* 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==

* MPK: Master Public Key. ECDSA, using same curve as bitcoin (secp256k1).
* Hash160: ripemd160(sha256(data))
* base58_encode_check: see bitcoin source code, https://github.com/bitcoin/bitcoin/blob/master/src/base58.h

==Creating a SIN==

# Prefix = 0x0F
# SIN_Type = [0x01 | 0x02 | 0x11] -- See below 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.

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.

# 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==

# B1 = block w/ T1
# B2 = block w/ 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
* linked to the sacrifices
* MPK starts a new chain of digital signature trust, for further record updates

==SIN record==

DANGER: This section is under heavy development and discussion.

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/gasteve/node-libcoin/blob/master/SIN.js
https://github.com/gasteve/node-libcoin/blob/master/SINKey.js
https://github.com/ionux/php-ectools/blob/master/ecsingen.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.

Identity protocol v1

2014-09-14T19:00:29Z

Jgarzik: improve summary

==Design goals==

Fully decentralized, anonymous, secure identity.

A SIN ("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 '''and''' hashes to your SIN record.
* 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==

* MPK: Master Public Key. ECDSA, using same curve as bitcoin (secp256k1).
* Hash160: ripemd160(sha256(data))
* base58_encode_check: see bitcoin source code, https://github.com/bitcoin/bitcoin/blob/master/src/base58.h

==Creating a SIN==

# Prefix = 0x0F
# SIN_Type = [0x01 | 0x02 | 0x11] -- See below 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.

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.

# 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==

# B1 = block w/ T1
# B2 = block w/ 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
* linked to the sacrifices
* MPK starts a new chain of digital signature trust, for further record updates

==SIN record==

DANGER: This section is under heavy development and discussion.

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/gasteve/node-libcoin/blob/master/SIN.js
https://github.com/gasteve/node-libcoin/blob/master/SINKey.js
https://github.com/ionux/php-ectools/blob/master/ecsingen.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.

Identity protocol v1

2013-09-20T20:42:47Z

Jgarzik: /* SIN record */

==Design goals==

Fully decentralized, anonymous, secure identity.

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

Attributes:
* Ownership may be digitally proven
* 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==

* MPK: Master Public Key. ECDSA, using same curve as bitcoin (secp256k1).
* Hash160: ripemd160(sha256(data))
* base58_encode_check: see bitcoin source code, https://github.com/bitcoin/bitcoin/blob/master/src/base58.h

==Creating a SIN==

# Prefix = 0x0F
# SIN_Type = [0x01 | 0x02 | 0x11] -- See below 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.

==Creating sacrifice transactions==

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

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.

# 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==

# B1 = block w/ T1
# B2 = block w/ 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
* linked to the sacrifices
* MPK starts a new chain of digital signature trust, for further record updates

==SIN record==

DANGER: This section is under heavy development and discussion.

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/gasteve/node-libcoin/blob/master/SIN.js
https://github.com/gasteve/node-libcoin/blob/master/SINKey.js

==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.

Identity protocol v1

2013-08-28T22:21:15Z

Jgarzik: /* SIN record */

==Design goals==

Fully decentralized, anonymous, secure identity.

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

Attributes:
* Ownership may be digitally proven
* 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==

* MPK: Master Public Key. ECDSA, using same curve as bitcoin (secp256k1).
* Hash160: ripemd160(sha256(data))
* base58_encode_check: see bitcoin source code, https://github.com/bitcoin/bitcoin/blob/master/src/base58.h

==Creating a SIN==

# Prefix = 0x0F
# SIN_Type = [0x01 | 0x02 | 0x11] -- See below 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.

==Creating sacrifice transactions==

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

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.

# 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==

# B1 = block w/ T1
# B2 = block w/ 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
* linked to the sacrifices
* MPK starts a new chain of digital signature trust, for further record updates

==SIN record==

DANGER: This section is under heavy development and discussion.

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.

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/gasteve/node-libcoin/blob/master/SIN.js
https://github.com/gasteve/node-libcoin/blob/master/SINKey.js

==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.

Identity protocol v1

2013-08-28T22:19:51Z

Jgarzik: /* SIN record */

==Design goals==

Fully decentralized, anonymous, secure identity.

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

Attributes:
* Ownership may be digitally proven
* 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==

* MPK: Master Public Key. ECDSA, using same curve as bitcoin (secp256k1).
* Hash160: ripemd160(sha256(data))
* base58_encode_check: see bitcoin source code, https://github.com/bitcoin/bitcoin/blob/master/src/base58.h

==Creating a SIN==

# Prefix = 0x0F
# SIN_Type = [0x01 | 0x02 | 0x11] -- See below 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.

==Creating sacrifice transactions==

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

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.

# 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==

# B1 = block w/ T1
# B2 = block w/ 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
* linked to the sacrifices
* MPK starts a new chain of digital signature trust, for further record updates

==SIN record==

DANGER: This section is under heavy development and discussion. It might morph into merkle roots or another form.

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.

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/gasteve/node-libcoin/blob/master/SIN.js
https://github.com/gasteve/node-libcoin/blob/master/SINKey.js

==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.

Identity protocol v1

2013-08-28T22:18:08Z

Jgarzik: /* SIN record */

==Design goals==

Fully decentralized, anonymous, secure identity.

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

Attributes:
* Ownership may be digitally proven
* 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==

* MPK: Master Public Key. ECDSA, using same curve as bitcoin (secp256k1).
* Hash160: ripemd160(sha256(data))
* base58_encode_check: see bitcoin source code, https://github.com/bitcoin/bitcoin/blob/master/src/base58.h

==Creating a SIN==

# Prefix = 0x0F
# SIN_Type = [0x01 | 0x02 | 0x11] -- See below 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.

==Creating sacrifice transactions==

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

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.

# 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==

# B1 = block w/ T1
# B2 = block w/ 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
* linked to the sacrifices
* MPK starts a new chain of digital signature trust, for further record updates

==SIN record==

DANGER: This section is under heavy development and discussion. It might morph into merkle roots or another form.

A SIN record is a series of key/value pairs, validated by MPK digital signature. Each SIN record has a stable binary encoding designed to ensure stable hash values.

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/gasteve/node-libcoin/blob/master/SIN.js
https://github.com/gasteve/node-libcoin/blob/master/SINKey.js

==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.

Identity protocol v1

2013-08-28T22:17:00Z

Jgarzik: /* SIN record */

==Design goals==

Fully decentralized, anonymous, secure identity.

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

Attributes:
* Ownership may be digitally proven
* 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==

* MPK: Master Public Key. ECDSA, using same curve as bitcoin (secp256k1).
* Hash160: ripemd160(sha256(data))
* base58_encode_check: see bitcoin source code, https://github.com/bitcoin/bitcoin/blob/master/src/base58.h

==Creating a SIN==

# Prefix = 0x0F
# SIN_Type = [0x01 | 0x02 | 0x11] -- See below 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.

==Creating sacrifice transactions==

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

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.

# 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==

# B1 = block w/ T1
# B2 = block w/ 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
* linked to the sacrifices
* MPK starts a new chain of digital signature trust, for further record updates

==SIN record==

DANGER: This section is under heavy development and discussion. It might morph into merkle roots or another form.

A SIN record is a series of key/value pairs, validated by MPK digital signature. Each SIN record has a stable binary encoding designed to ensure stable hash values.

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]

The order of key/value pairs must be preserved, to ensure hash stability.

Duplicate keys are not permitted.

==Implementations==

See
https://github.com/gasteve/node-libcoin/blob/master/SIN.js
https://github.com/gasteve/node-libcoin/blob/master/SINKey.js

==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.

Identity protocol v1

2013-08-28T22:16:26Z

Jgarzik: /* SIN record */

==Design goals==

Fully decentralized, anonymous, secure identity.

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

Attributes:
* Ownership may be digitally proven
* 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==

* MPK: Master Public Key. ECDSA, using same curve as bitcoin (secp256k1).
* Hash160: ripemd160(sha256(data))
* base58_encode_check: see bitcoin source code, https://github.com/bitcoin/bitcoin/blob/master/src/base58.h

==Creating a SIN==

# Prefix = 0x0F
# SIN_Type = [0x01 | 0x02 | 0x11] -- See below 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.

==Creating sacrifice transactions==

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

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.

# 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==

# B1 = block w/ T1
# B2 = block w/ 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
* linked to the sacrifices
* MPK starts a new chain of digital signature trust, for further record updates

==SIN record==

DANGER: This section is under heavy development and discussion. It might morph into merkle roots or another form.

A SIN record is a series of key/value pairs, validated by MPK digital signature. Each SIN record has a stable binary encoding designed to ensure stable hash values.

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]

The order of key/value pairs must be preserved, to ensure hash stability.

Duplicate keys are not permitted.

==Implementations==

See
https://github.com/gasteve/node-libcoin/blob/master/SIN.js
https://github.com/gasteve/node-libcoin/blob/master/SINKey.js

==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.

Identity protocol v1

2013-08-28T22:16:05Z

Jgarzik: /* SIN record */

==Design goals==

Fully decentralized, anonymous, secure identity.

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

Attributes:
* Ownership may be digitally proven
* 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==

* MPK: Master Public Key. ECDSA, using same curve as bitcoin (secp256k1).
* Hash160: ripemd160(sha256(data))
* base58_encode_check: see bitcoin source code, https://github.com/bitcoin/bitcoin/blob/master/src/base58.h

==Creating a SIN==

# Prefix = 0x0F
# SIN_Type = [0x01 | 0x02 | 0x11] -- See below 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.

==Creating sacrifice transactions==

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

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.

# 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==

# B1 = block w/ T1
# B2 = block w/ 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
* linked to the sacrifices
* MPK starts a new chain of digital signature trust, for further record updates

==SIN record==

DANGER: This section is under heavy development and discussion. It might morph into merkle roots or another form.

A SIN record is a series of key/value pairs, validated by MPK digital signature. Each SIN record has a stable binary encoding designed to ensure stable hash values.

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]

The order of key/value pairs must be preserved, to ensure hash stability.

Duplicate keys are not permitted.

==Implementations==

See
https://github.com/gasteve/node-libcoin/blob/master/SIN.js
https://github.com/gasteve/node-libcoin/blob/master/SINKey.js

==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.

Identity protocol v1

2013-08-28T22:05:19Z

Jgarzik: /* SIN record */

==Design goals==

Fully decentralized, anonymous, secure identity.

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

Attributes:
* Ownership may be digitally proven
* 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==

* MPK: Master Public Key. ECDSA, using same curve as bitcoin (secp256k1).
* Hash160: ripemd160(sha256(data))
* base58_encode_check: see bitcoin source code, https://github.com/bitcoin/bitcoin/blob/master/src/base58.h

==Creating a SIN==

# Prefix = 0x0F
# SIN_Type = [0x01 | 0x02 | 0x11] -- See below 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.

==Creating sacrifice transactions==

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

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.

# 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==

# B1 = block w/ T1
# B2 = block w/ 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
* linked to the sacrifices
* MPK starts a new chain of digital signature trust, for further record updates

==SIN record==

DANGER: This section is under heavy development and discussion. It might morph into merkle roots or another form.

A SIN record is a series of key/value pairs, validated by MPK digital signature. Each SIN record has a stable binary encoding designed to ensure stable hash values.

uint32_t: an unsigned, little endian integer

Basic layout:
* uint32_t magic number (and/or version number) == 0x88, 0x41, 0x92, 0xA4
* uint32_t pair count
* [list of key/value pairs]
* Hash160(prior data)

Basic layout of a key/value pair:
* uint32_t key length
* uint32_t value length
* [key-length bytes of valid UTF8-encoded data]
* [value-length bytes of opaque data]

The order of key/value pairs must be preserved, to ensure hash stability.

Duplicate keys are not permitted.

==Implementations==

See
https://github.com/gasteve/node-libcoin/blob/master/SIN.js
https://github.com/gasteve/node-libcoin/blob/master/SINKey.js

==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.

Identity protocol v1

2013-08-28T21:32:50Z

Jgarzik: /* SIN record */

==Design goals==

Fully decentralized, anonymous, secure identity.

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

Attributes:
* Ownership may be digitally proven
* 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==

* MPK: Master Public Key. ECDSA, using same curve as bitcoin (secp256k1).
* Hash160: ripemd160(sha256(data))
* base58_encode_check: see bitcoin source code, https://github.com/bitcoin/bitcoin/blob/master/src/base58.h

==Creating a SIN==

# Prefix = 0x0F
# SIN_Type = [0x01 | 0x02 | 0x11] -- See below 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.

==Creating sacrifice transactions==

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

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.

# 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==

# B1 = block w/ T1
# B2 = block w/ 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
* 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 key/value pairs, validated by MPK digital signature. Each SIN record has a stable binary encoding designed to ensure stable hash values.

uint32_t: an unsigned, little endian integer

Basic layout:
* uint32_t magic number (and/or version number) == 0x88, 0x41, 0x92, 0xA4
* uint32_t pair count
* [list of key/value pairs]
* Hash160(prior data)

Basic layout of a key/value pair:
* uint32_t key length
* uint32_t value length
* [key-length bytes of valid UTF8-encoded data]
* [value-length bytes of opaque data]

The order of key/value pairs must be preserved, to ensure hash stability.

Duplicate keys are not permitted.

==Implementations==

See
https://github.com/gasteve/node-libcoin/blob/master/SIN.js
https://github.com/gasteve/node-libcoin/blob/master/SINKey.js

==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.

Identity protocol v1

2013-08-28T21:31:19Z

Jgarzik: /* SIN record */

==Design goals==

Fully decentralized, anonymous, secure identity.

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

Attributes:
* Ownership may be digitally proven
* 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==

* MPK: Master Public Key. ECDSA, using same curve as bitcoin (secp256k1).
* Hash160: ripemd160(sha256(data))
* base58_encode_check: see bitcoin source code, https://github.com/bitcoin/bitcoin/blob/master/src/base58.h

==Creating a SIN==

# Prefix = 0x0F
# SIN_Type = [0x01 | 0x02 | 0x11] -- See below 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.

==Creating sacrifice transactions==

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

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.

# 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==

# B1 = block w/ T1
# B2 = block w/ 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
* 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 key/value pairs, validated by MPK digital signature. Each SIN record has a stable binary encoding designed to ensure stable hash values.

uint32_t: an unsigned, little endian integer

Basic layout:
* uint32_t pair count
* [list of key/value pairs]
* Hash160(prior data)

Basic layout of a key/value pair:
* uint32_t key length
* uint32_t value length
* [key-length bytes of valid UTF8-encoded data]
* [value-length bytes of opaque data]

The order of key/value pairs must be preserved, to ensure hash stability.

Duplicate keys are not permitted.

==Implementations==

See
https://github.com/gasteve/node-libcoin/blob/master/SIN.js
https://github.com/gasteve/node-libcoin/blob/master/SINKey.js

==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.

Identity protocol v1

2013-08-28T21:30:33Z

Jgarzik: /* SIN record */

==Design goals==

Fully decentralized, anonymous, secure identity.

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

Attributes:
* Ownership may be digitally proven
* 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==

* MPK: Master Public Key. ECDSA, using same curve as bitcoin (secp256k1).
* Hash160: ripemd160(sha256(data))
* base58_encode_check: see bitcoin source code, https://github.com/bitcoin/bitcoin/blob/master/src/base58.h

==Creating a SIN==

# Prefix = 0x0F
# SIN_Type = [0x01 | 0x02 | 0x11] -- See below 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.

==Creating sacrifice transactions==

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

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.

# 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==

# B1 = block w/ T1
# B2 = block w/ 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
* 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 key/value pairs, validated by MPK digital signature. Each SIN record has a stable binary encoding designed to ensure stable hash values.

uint32_t: an unsigned, little endian integer

Basic layout:
uint32_t pair count
[list of key/value pairs]
Hash160(prior data)

Basic layout of a key/value pair:
uint32_t key length
uint32_t value length
[key-length bytes of valid UTF8-encoded data]
[value-length bytes of opaque data]

The order of key/value pairs must be preserved, to ensure hash stability.

Duplicate keys are not permitted.

==Implementations==

See
https://github.com/gasteve/node-libcoin/blob/master/SIN.js
https://github.com/gasteve/node-libcoin/blob/master/SINKey.js

==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.

Identity protocol v1

2013-08-28T21:18:20Z

Jgarzik: /* SIN record */

==Design goals==

Fully decentralized, anonymous, secure identity.

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

Attributes:
* Ownership may be digitally proven
* 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==

* MPK: Master Public Key. ECDSA, using same curve as bitcoin (secp256k1).
* Hash160: ripemd160(sha256(data))
* base58_encode_check: see bitcoin source code, https://github.com/bitcoin/bitcoin/blob/master/src/base58.h

==Creating a SIN==

# Prefix = 0x0F
# SIN_Type = [0x01 | 0x02 | 0x11] -- See below 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.

==Creating sacrifice transactions==

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

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.

# 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==

# B1 = block w/ T1
# B2 = block w/ 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
* 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 key/value pairs, validated by MPK digital signature. Each SIN record has a stable binary encoding designed to ensure stable hash values.

==Implementations==

See
https://github.com/gasteve/node-libcoin/blob/master/SIN.js
https://github.com/gasteve/node-libcoin/blob/master/SINKey.js

==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.

Identity protocol v1

2013-08-28T21:17:28Z

Jgarzik: add SIN record section

==Design goals==

Fully decentralized, anonymous, secure identity.

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

Attributes:
* Ownership may be digitally proven
* 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==

* MPK: Master Public Key. ECDSA, using same curve as bitcoin (secp256k1).
* Hash160: ripemd160(sha256(data))
* base58_encode_check: see bitcoin source code, https://github.com/bitcoin/bitcoin/blob/master/src/base58.h

==Creating a SIN==

# Prefix = 0x0F
# SIN_Type = [0x01 | 0x02 | 0x11] -- See below 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.

==Creating sacrifice transactions==

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

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.

# 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==

# B1 = block w/ T1
# B2 = block w/ 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
* 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 key/value pairs, validated by MPK digital siganture. Each SIN record has a stable binary encoding designed to ensure stable hash values.

==Implementations==

See
https://github.com/gasteve/node-libcoin/blob/master/SIN.js
https://github.com/gasteve/node-libcoin/blob/master/SINKey.js

==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.

Identity protocol v1

2013-08-17T05:27:09Z

Jgarzik: /* Creating a SIN */ hyphenation guidelines

==Design goals==

Fully decentralized, anonymous, secure identity.

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

Attributes:
* Ownership may be digitally proven
* 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==

* MPK: Master Public Key. ECDSA, using same curve as bitcoin (secp256k1).
* Hash160: ripemd160(sha256(data))
* base58_encode_check: see bitcoin source code, https://github.com/bitcoin/bitcoin/blob/master/src/base58.h

==Creating a SIN==

# Prefix = 0x0F
# SIN_Type = [0x01 | 0x02 | 0x11] -- See below 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.

==Creating sacrifice transactions==

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

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.

# 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==

# B1 = block w/ T1
# B2 = block w/ 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
* linked to the sacrifices
* MPK starts a new chain of digital signature trust, for further record updates

==Implementations==

See
https://github.com/gasteve/node-libcoin/blob/master/SIN.js
https://github.com/gasteve/node-libcoin/blob/master/SINKey.js

==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.

Identity protocol v1

2013-08-17T05:18:38Z

Jgarzik: /* Definitions */

==Design goals==

Fully decentralized, anonymous, secure identity.

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

Attributes:
* Ownership may be digitally proven
* 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==

* MPK: Master Public Key. ECDSA, using same curve as bitcoin (secp256k1).
* Hash160: ripemd160(sha256(data))
* base58_encode_check: see bitcoin source code, https://github.com/bitcoin/bitcoin/blob/master/src/base58.h

==Creating a SIN==

# Prefix = 0x0F
# SIN_Type = [0x01 | 0x02 | 0x11] -- See below for discussion of SIN types.
# MD = Hash160(MPK)
# SIN = base58_encode_check( Prefix + SIN_Version + MD )
# Hyphenate SIN for easier human reading

==Creating sacrifice transactions==

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

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.

# 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==

# B1 = block w/ T1
# B2 = block w/ 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
* linked to the sacrifices
* MPK starts a new chain of digital signature trust, for further record updates

==Implementations==

See
https://github.com/gasteve/node-libcoin/blob/master/SIN.js
https://github.com/gasteve/node-libcoin/blob/master/SINKey.js

==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.

Identity protocol v1

2013-08-17T05:16:45Z

Jgarzik: Add link to example implementation

==Design goals==

Fully decentralized, anonymous, secure identity.

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

Attributes:
* Ownership may be digitally proven
* 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==

* MPK: Master Public Key. ECDSA, using same curve as bitcoin.
* Hash160: ripemd160(sha256(data))
* base58_encode_check: see bitcoin source code, https://github.com/bitcoin/bitcoin/blob/master/src/base58.h

==Creating a SIN==

# Prefix = 0x0F
# SIN_Type = [0x01 | 0x02 | 0x11] -- See below for discussion of SIN types.
# MD = Hash160(MPK)
# SIN = base58_encode_check( Prefix + SIN_Version + MD )
# Hyphenate SIN for easier human reading

==Creating sacrifice transactions==

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

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.

# 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==

# B1 = block w/ T1
# B2 = block w/ 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
* linked to the sacrifices
* MPK starts a new chain of digital signature trust, for further record updates

==Implementations==

See
https://github.com/gasteve/node-libcoin/blob/master/SIN.js
https://github.com/gasteve/node-libcoin/blob/master/SINKey.js

==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.

Identity protocol v1

2013-08-17T05:07:30Z

Jgarzik: /* Creating a SIN */ prefix changes to 0x0f

==Design goals==

Fully decentralized, anonymous, secure identity.

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

Attributes:
* Ownership may be digitally proven
* 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==

* MPK: Master Public Key. ECDSA, using same curve as bitcoin.
* Hash160: ripemd160(sha256(data))
* base58_encode_check: see bitcoin source code, https://github.com/bitcoin/bitcoin/blob/master/src/base58.h

==Creating a SIN==

# Prefix = 0x0F
# SIN_Type = [0x01 | 0x02 | 0x11] -- See below for discussion of SIN types.
# MD = Hash160(MPK)
# SIN = base58_encode_check( Prefix + SIN_Version + MD )
# Hyphenate SIN for easier human reading

==Creating sacrifice transactions==

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

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.

# 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==

# B1 = block w/ T1
# B2 = block w/ 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
* 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.

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.

Identity protocol v1

2013-07-23T17:21:40Z

Jgarzik: /* Definitions */

==Design goals==

Fully decentralized, anonymous, secure identity.

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

Attributes:
* Ownership may be digitally proven
* 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==

* MPK: Master Public Key. ECDSA, using same curve as bitcoin.
* Hash160: ripemd160(sha256(data))
* base58_encode_check: see bitcoin source code, https://github.com/bitcoin/bitcoin/blob/master/src/base58.h

==Creating a SIN==

# Prefix = 0x18
# SIN_Type = [0x01 | 0x02 | 0x11] -- See below for discussion of SIN types.
# MD = Hash160(MPK)
# SIN = base58_encode_check( Prefix + SIN_Version + MD )
# Hyphenate SIN for easier human reading

==Creating sacrifice transactions==

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

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.

# 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==

# B1 = block w/ T1
# B2 = block w/ 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
* 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.

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.

Identity protocol v1

2013-07-23T17:20:56Z

Jgarzik: add definitions section

==Design goals==

Fully decentralized, anonymous, secure identity.

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

Attributes:
* Ownership may be digitally proven
* 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==

MPK: Master Public Key. ECDSA, using same curve as bitcoin.
Hash160: ripemd160(sha256(data))
base58_encode_check: see bitcoin source code

==Creating a SIN==

# Prefix = 0x18
# SIN_Type = [0x01 | 0x02 | 0x11] -- See below for discussion of SIN types.
# MD = Hash160(MPK)
# SIN = base58_encode_check( Prefix + SIN_Version + MD )
# Hyphenate SIN for easier human reading

==Creating sacrifice transactions==

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

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.

# 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==

# B1 = block w/ T1
# B2 = block w/ 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
* 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.

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.

Identity protocol v1

2013-07-17T15:13:56Z

Jgarzik: Move down sacrifice section

==Design goals==

Fully decentralized, anonymous, secure identity.

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

Attributes:
* Ownership may be digitally proven
* 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.

==Creating a SIN==

# Prefix = 0x18
# SIN_Type = [0x01 | 0x02 | 0x11] -- See below for discussion of SIN types.
# MD = Hash160(MPK)
# SIN = base58_encode_check( Prefix + SIN_Version + MD )
# Hyphenate SIN for easier human reading

==Creating sacrifice transactions==

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

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.

# 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==

# B1 = block w/ T1
# B2 = block w/ 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
* 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.

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.

Identity protocol v1

2013-07-15T02:46:43Z

Jgarzik: /* Creating a SIN */

==Design goals==

Fully decentralized, anonymous, secure identity.

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

Attributes:
* Ownership may be digitally proven
* 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.

==Creating sacrifice transactions==

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

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.

# 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

==Creating a SIN==

# Prefix = 0x18
# SIN_Type = [0x01 | 0x02 | 0x11] -- See below for discussion of SIN types.
# MD = Hash160(MPK)
# SIN = base58_encode_check( Prefix + SIN_Version + MD )
# Hyphenate SIN for easier human reading

==Validating the root identity information==

# B1 = block w/ T1
# B2 = block w/ 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
* 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.

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.

Identity protocol v1

2013-07-11T21:11:53Z

Jgarzik: /* Types of SIN addresses */

==Design goals==

Fully decentralized, anonymous, secure identity.

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

Attributes:
* Ownership may be digitally proven
* 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.

==Creating sacrifice transactions==

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

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.

# 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

==Creating a SIN==

# Prefix = 0x18
# SIN_Type = {0x01 | 0x02 | 0x11] -- See below for discussion of SIN types.
# MD = Hash160(MPK)
# SIN = base58_encode_check( Prefix + SIN_Version + MD )
# Hyphenate SIN for easier human reading

==Validating the root identity information==

# B1 = block w/ T1
# B2 = block w/ 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
* 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.

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.

Identity protocol v1

2013-07-11T21:11:32Z

Jgarzik: /* Design goals */

==Design goals==

Fully decentralized, anonymous, secure identity.

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

Attributes:
* Ownership may be digitally proven
* 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 SIN addresses==

===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.

==Creating sacrifice transactions==

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

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.

# 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

==Creating a SIN==

# Prefix = 0x18
# SIN_Type = {0x01 | 0x02 | 0x11] -- See below for discussion of SIN types.
# MD = Hash160(MPK)
# SIN = base58_encode_check( Prefix + SIN_Version + MD )
# Hyphenate SIN for easier human reading

==Validating the root identity information==

# B1 = block w/ T1
# B2 = block w/ 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
* 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.

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.

Identity protocol v1

2013-07-11T21:10:16Z

Jgarzik: /* Creating a SIN */

==Design goals==

Fully decentralized, anonymous, secure identity.

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

Attributes:
* Ownership may be digitally proven
* 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
* Has some creation cost, deterring spam.
* 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 SIN addresses==

===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.

==Creating sacrifice transactions==

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

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.

# 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

==Creating a SIN==

# Prefix = 0x18
# SIN_Type = {0x01 | 0x02 | 0x11] -- See below for discussion of SIN types.
# MD = Hash160(MPK)
# SIN = base58_encode_check( Prefix + SIN_Version + MD )
# Hyphenate SIN for easier human reading

==Validating the root identity information==

# B1 = block w/ T1
# B2 = block w/ 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
* 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.

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.

Identity protocol v1

2013-07-11T21:10:04Z

Jgarzik: /* Type 2 (ephemeral) */

==Design goals==

Fully decentralized, anonymous, secure identity.

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

Attributes:
* Ownership may be digitally proven
* 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
* Has some creation cost, deterring spam.
* 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 SIN addresses==

===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.

==Creating sacrifice transactions==

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

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.

# 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

==Creating a SIN==

# Prefix = 0x18
# SIN_Type = {0x01 | 0x02 | 0x11 | 0x12] -- See below for discussion of SIN types.
# MD = Hash160(MPK)
# SIN = base58_encode_check( Prefix + SIN_Version + MD )
# Hyphenate SIN for easier human reading

==Validating the root identity information==

# B1 = block w/ T1
# B2 = block w/ 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
* 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.

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.

Identity protocol v1

2013-07-11T21:08:44Z

Jgarzik: Add sin type section

==Design goals==

Fully decentralized, anonymous, secure identity.

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

Attributes:
* Ownership may be digitally proven
* 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
* Has some creation cost, deterring spam.
* 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 SIN addresses==

===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)===

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

==Creating sacrifice transactions==

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

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.

# 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

==Creating a SIN==

# Prefix = 0x18
# SIN_Type = {0x01 | 0x02 | 0x11 | 0x12] -- See below for discussion of SIN types.
# MD = Hash160(MPK)
# SIN = base58_encode_check( Prefix + SIN_Version + MD )
# Hyphenate SIN for easier human reading

==Validating the root identity information==

# B1 = block w/ T1
# B2 = block w/ 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
* 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.

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.

Identity protocol v1

2013-07-11T21:03:02Z

Jgarzik: /* Creating a SIN */

==Design goals==

Fully decentralized, anonymous, secure identity.

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

Attributes:
* Ownership may be digitally proven
* 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
* Has some creation cost, deterring spam.
* 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.

==Creating sacrifice transactions==

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

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.

# MPK = master public key
# 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

==Creating a SIN==

# Prefix = 0x18
# SIN_Type = {0x01 | 0x02 | 0x11 | 0x12] -- See below for discussion of SIN types.
# MD = Hash160(MPK)
# SIN = base58_encode_check( Prefix + SIN_Version + MD )
# Hyphenate SIN for easier human reading

==Validating the root identity information==

# B1 = block w/ T1
# B2 = block w/ 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
* 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.

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.

Identity protocol v1

2013-07-02T04:12:16Z

Jgarzik: /* Design goals */

==Design goals==

Fully decentralized, anonymous, secure identity.

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

Attributes:
* Ownership may be digitally proven
* 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
* Has some creation cost, deterring spam.
* 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.

==Creating sacrifice transactions==

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

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.

# MPK = master public key
# 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

==Creating a SIN==

# Prefix = 0x18 (mainnet) or 0x19 (testnet)
# SIN_Version = 0x01, similar to how a [http://en.wikipedia.org/wiki/Universally_unique_identifier UUID's] form is dictated by a UUID's self-identified version
# MD = Hash160(MPK)
# SIN = base58_encode_check( Prefix + SIN_Version + MD )
# Hyphenate SIN for easier human reading

==Validating the root identity information==

# B1 = block w/ T1
# B2 = block w/ 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
* 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.

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.

Identity protocol v1

2013-07-02T04:11:49Z

Jgarzik: /* Design goals */

==Design goals==

Fully decentralized, anonymous, secure identity.

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

Attributes:
* Ownership may be digitally proven
* 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 auction users digitally sign one another's SINs
* Has some creation cost, deterring spam.
* 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.

==Creating sacrifice transactions==

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

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.

# MPK = master public key
# 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

==Creating a SIN==

# Prefix = 0x18 (mainnet) or 0x19 (testnet)
# SIN_Version = 0x01, similar to how a [http://en.wikipedia.org/wiki/Universally_unique_identifier UUID's] form is dictated by a UUID's self-identified version
# MD = Hash160(MPK)
# SIN = base58_encode_check( Prefix + SIN_Version + MD )
# Hyphenate SIN for easier human reading

==Validating the root identity information==

# B1 = block w/ T1
# B2 = block w/ 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
* 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.

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.

Identity protocol v1

2013-07-01T15:00:44Z

Jgarzik: /* Design goals */

==Design goals==

Fully decentralized, anonymous, secure identity.

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

Attributes:
* Ownership may be digitally proven
* 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.
* Has some creation cost, deterring spam.
* 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.

==Creating sacrifice transactions==

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

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.

# MPK = master public key
# 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

==Creating a SIN==

# Prefix = 0x18 (mainnet) or 0x19 (testnet)
# SIN_Version = 0x01, similar to how a [http://en.wikipedia.org/wiki/Universally_unique_identifier UUID's] form is dictated by a UUID's self-identified version
# MD = Hash160(MPK)
# SIN = base58_encode_check( Prefix + SIN_Version + MD )
# Hyphenate SIN for easier human reading

==Validating the root identity information==

# B1 = block w/ T1
# B2 = block w/ 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
* 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.

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.

Identity protocol v1

2013-07-01T14:18:19Z

Jgarzik: /* Design goals */

==Design goals==

Fully decentralized, anonymous, secure identity.

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

Attributes:
* Ownership may be digitally proven
* 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").
* Disposable
* Third parties may offer digital attestions: Identity Verification, Inc. digitally signs a SIN as passing their Not A Criminal/Level-1 check.
* Has some creation cost, deterring spam.
* All key-value pair updates digitally signed by SIN owner (key holder)

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

==Creating sacrifice transactions==

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

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.

# MPK = master public key
# 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

==Creating a SIN==

# Prefix = 0x18 (mainnet) or 0x19 (testnet)
# SIN_Version = 0x01, similar to how a [http://en.wikipedia.org/wiki/Universally_unique_identifier UUID's] form is dictated by a UUID's self-identified version
# MD = Hash160(MPK)
# SIN = base58_encode_check( Prefix + SIN_Version + MD )
# Hyphenate SIN for easier human reading

==Validating the root identity information==

# B1 = block w/ T1
# B2 = block w/ 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
* 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.

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.

Identity protocol v1

2013-06-28T14:05:56Z

Jgarzik: /* Design goals */

==Design goals==

Fully decentralized, anonymous, secure identity.

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

Attributes:
* Has some creation cost, deterring spam.
* 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").
* Third parties may offer digital attestions: Identity Verification, Inc. digitally signs a SIN as passing their Not A Criminal/Level-1 check.
* All key-value pair updates digitally signed by SIN owner (key holder)

==Creating sacrifice transactions==

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

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.

# MPK = master public key
# 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

==Creating a SIN==

# Prefix = 0x18 (mainnet) or 0x19 (testnet3)
# SIN_Version = 0x01, similar to how a [http://en.wikipedia.org/wiki/Universally_unique_identifier UUID's] form is dictated by a UUID's self-identified version
# MD = Hash160(MPK)
# SIN = base58_encode_check( Prefix + SIN_Version + MD )
# Hyphenate SIN for easier human reading

==Validating the root identity information==

# B1 = block w/ T1
# B2 = block w/ 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
* 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.

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.

Identity protocol v1

2013-06-28T14:04:57Z

Jgarzik: /* Creating a SIN */

==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, deterring spam.
* 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").
* Third parties may offer digital attestions: Identity Verification, Inc. digitally signs a SIN as passing their Not A Criminal/Level-1 check.
* All key-value pair updates digitally signed by SIN owner (key holder)

==Creating sacrifice transactions==

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

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.

# MPK = master public key
# 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

==Creating a SIN==

# Prefix = 0x18 (mainnet) or 0x19 (testnet3)
# SIN_Version = 0x01, similar to how a [http://en.wikipedia.org/wiki/Universally_unique_identifier UUID's] form is dictated by a UUID's self-identified version
# MD = Hash160(MPK)
# SIN = base58_encode_check( Prefix + SIN_Version + MD )
# Hyphenate SIN for easier human reading

==Validating the root identity information==

# B1 = block w/ T1
# B2 = block w/ 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
* 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.

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.

Identity protocol v1

2013-06-28T06:01:26Z

Jgarzik: /* Creating sacrifice transactions */

==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, deterring spam.
* 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").
* Third parties may offer digital attestions: Identity Verification, Inc. digitally signs a SIN as passing their Not A Criminal/Level-1 check.
* All key-value pair updates digitally signed by SIN owner (key holder)

==Creating sacrifice transactions==

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

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.

# MPK = master public key
# 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

==Creating a SIN==

# Prefix = 0x18
# SIN_Version = 0x01, similar to how a [http://en.wikipedia.org/wiki/Universally_unique_identifier UUID's] form is dictated by a UUID's self-identified version
# MD = Hash160(MPK)
# SIN = base58_encode_check( Prefix + SIN_Version + MD )
# Hyphenate or space SIN for easier human reading

==Validating the root identity information==

# B1 = block w/ T1
# B2 = block w/ 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
* 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.

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.

Identity protocol v1

2013-06-28T06:00:25Z

Jgarzik: /* Design goals */

==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, deterring spam.
* 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").
* Third parties may offer digital attestions: Identity Verification, Inc. digitally signs a SIN as passing their Not A Criminal/Level-1 check.
* All key-value pair updates digitally signed by SIN owner (key holder)

==Creating sacrifice transactions==

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

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.

# MPK = master public key
# TM = 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 = TM + 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

==Creating a SIN==

# Prefix = 0x18
# SIN_Version = 0x01, similar to how a [http://en.wikipedia.org/wiki/Universally_unique_identifier UUID's] form is dictated by a UUID's self-identified version
# MD = Hash160(MPK)
# SIN = base58_encode_check( Prefix + SIN_Version + MD )
# Hyphenate or space SIN for easier human reading

==Validating the root identity information==

# B1 = block w/ T1
# B2 = block w/ 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
* 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.

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.

Identity protocol v1

2013-06-28T05:57:48Z

Jgarzik: /* Design goals */

==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, deterring spam.
* 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").
* Third parties may offer digital attestions: Identity Verification, Inc. digitally signs a SIN as passing their Not A Criminal/Level-1 check.
* All data updates digitally signed by SIN owner (key holder)

==Creating sacrifice transactions==

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

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.

# MPK = master public key
# TM = 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 = TM + 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

==Creating a SIN==

# Prefix = 0x18
# SIN_Version = 0x01, similar to how a [http://en.wikipedia.org/wiki/Universally_unique_identifier UUID's] form is dictated by a UUID's self-identified version
# MD = Hash160(MPK)
# SIN = base58_encode_check( Prefix + SIN_Version + MD )
# Hyphenate or space SIN for easier human reading

==Validating the root identity information==

# B1 = block w/ T1
# B2 = block w/ 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
* 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.

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.

Identity protocol v1

2013-06-28T05:54:44Z

Jgarzik: /* Design goals */

==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, deterring spam.
* 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").
* 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==

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

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.

# MPK = master public key
# TM = 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 = TM + 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

==Creating a SIN==

# Prefix = 0x18
# SIN_Version = 0x01, similar to how a [http://en.wikipedia.org/wiki/Universally_unique_identifier UUID's] form is dictated by a UUID's self-identified version
# MD = Hash160(MPK)
# SIN = base58_encode_check( Prefix + SIN_Version + MD )
# Hyphenate or space SIN for easier human reading

==Validating the root identity information==

# B1 = block w/ T1
# B2 = block w/ 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
* 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.

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.

Identity protocol v1

2013-06-28T05:54:32Z

Jgarzik: /* Creating sacrifice transactions */

==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").
* 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==

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

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.

# MPK = master public key
# TM = 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 = TM + 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

==Creating a SIN==

# Prefix = 0x18
# SIN_Version = 0x01, similar to how a [http://en.wikipedia.org/wiki/Universally_unique_identifier UUID's] form is dictated by a UUID's self-identified version
# MD = Hash160(MPK)
# SIN = base58_encode_check( Prefix + SIN_Version + MD )
# Hyphenate or space SIN for easier human reading

==Validating the root identity information==

# B1 = block w/ T1
# B2 = block w/ 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
* 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.

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.

Identity protocol v1

2013-06-28T05:53:02Z

Jgarzik: /* Future work */

==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").
* 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 [https://en.bitcoin.it/wiki/Fidelity_bonds#Announce.2FCommit_Sacrifices Announce/Commit Sacrifices]. That author's feedback on this protocol was very helpful.

# MPK = master public key
# TM = 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 = TM + 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

==Creating a SIN==

# Prefix = 0x18
# SIN_Version = 0x01, similar to how a [http://en.wikipedia.org/wiki/Universally_unique_identifier UUID's] form is dictated by a UUID's self-identified version
# MD = Hash160(MPK)
# SIN = base58_encode_check( Prefix + SIN_Version + MD )
# Hyphenate or space SIN for easier human reading

==Validating the root identity information==

# B1 = block w/ T1
# B2 = block w/ 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
* 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.

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.

Identity protocol v1

2013-06-28T05:50:55Z

Jgarzik: /* Design goals */

==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").
* 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 [https://en.bitcoin.it/wiki/Fidelity_bonds#Announce.2FCommit_Sacrifices Announce/Commit Sacrifices]. That author's feedback on this protocol was very helpful.

# MPK = master public key
# TM = 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 = TM + 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

==Creating a SIN==

# Prefix = 0x18
# SIN_Version = 0x01, similar to how a [http://en.wikipedia.org/wiki/Universally_unique_identifier UUID's] form is dictated by a UUID's self-identified version
# MD = Hash160(MPK)
# SIN = base58_encode_check( Prefix + SIN_Version + MD )
# Hyphenate or space SIN for easier human reading

==Validating the root identity information==

# B1 = block w/ T1
# B2 = block w/ 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
* 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.

Identity protocol v1

2013-06-28T05:49:28Z

Jgarzik: /* Future work */

==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 [https://en.bitcoin.it/wiki/Fidelity_bonds#Announce.2FCommit_Sacrifices Announce/Commit Sacrifices]. That author's feedback on this protocol was very helpful.

# MPK = master public key
# TM = 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 = TM + 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

==Creating a SIN==

# Prefix = 0x18
# SIN_Version = 0x01, similar to how a [http://en.wikipedia.org/wiki/Universally_unique_identifier UUID's] form is dictated by a UUID's self-identified version
# MD = Hash160(MPK)
# SIN = base58_encode_check( Prefix + SIN_Version + MD )
# Hyphenate or space SIN for easier human reading

==Validating the root identity information==

# B1 = block w/ T1
# B2 = block w/ 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
* 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.

Identity protocol v1

2013-06-28T05:47:41Z

Jgarzik: /* Creating a SIN */

==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 [https://en.bitcoin.it/wiki/Fidelity_bonds#Announce.2FCommit_Sacrifices Announce/Commit Sacrifices]. That author's feedback on this protocol was very helpful.

# MPK = master public key
# TM = 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 = TM + 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

==Creating a SIN==

# Prefix = 0x18
# SIN_Version = 0x01, similar to how a [http://en.wikipedia.org/wiki/Universally_unique_identifier UUID's] form is dictated by a UUID's self-identified version
# MD = Hash160(MPK)
# SIN = base58_encode_check( Prefix + SIN_Version + MD )
# Hyphenate or space SIN for easier human reading

==Validating the root identity information==

# B1 = block w/ T1
# B2 = block w/ 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
* linked to the sacrifices
* MPK starts a new chain of digital signature trust, for further record updates

==Future work==

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.