<div dir="ltr">Hi Ben-<div><br></div><div>Is what you're describing similar to Onename (<a href="https://onename.io/">https://onename.io/</a>)? They use Namecoin instead of Bitcoin so that transferring/updating your info is more straightforward and you can have a human-readable handle, but otherwise I think they have the same idea of using a blockchain and collecting verification of your social media accounts.</div><div><br></div><div>Joe</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 12, 2014 at 9:24 PM, Ben Harris <span dir="ltr"><<a href="mailto:mail@bharr.is" target="_blank">mail@bharr.is</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi All,<br><br>I love the idea of KeyBase, but as I'm still waiting in 
the invite queue I'd also love a de-centralised version. I've just 
thrown some ideas around and would like to see if it holds up to the 
scrutiny of the group.<br><br>The rough idea is to use the 40 socially-responsible bytes in OP_RETURN to encode something that allows:<br>  - Me to see that my key-information has been published (block chain is public, so yay).<br>  - Me to see that other people aren't trying to imitate me.<br>  - Everyone to see when I have revoked a key.<br>  - My contacts to find my key-information.<br><br>The
 simplest KeyBase-esq design is just to publish on your Twitter - "my 
key fingerprint is X". The problem is that Twitter might change that to 
mention fingerprint Y for select users.<br><br>So instead we take all 
our keys (A), our supported social profiles (B) and a SHA224 of a 224 
bit revocation code (X), concatenate them and hash the result with 
SHA224 (C). Concatenate will probably just mean place in sorted JSON.<br><br>C is then your 224 bit key ID.<br>Next
 we take all your profiles in B, calculate the SHA224 of the [account 
type] || [account id] (e.g. "twitteruser1") and take the 32 least 
significant bits of each to get D (which has the same number of entries 
as B, but only 32 bits for each).<br><br>Now we publish a transaction to
 bitcoin and encode the following in the OP_RETURN. The transaction 
contains C and D. It fits nicely when there are only two entries in D, 
otherwise we do the following.<br><br>For the first two profiles publish<br>"PK" 0 C |D| D(0) D(1)<br>Where
 "PK" is the two ascii bytes PK as a magic number. 0 is 0 byte as the 
packet type, |D| is the total number of social profiles, D(x) is the 
x-th social profile.<br><br>For subsequent packets in groups of 6, the packet type is 1, C is only the first 96-bits of C, and |D| is an incrementing number<br>"PK" 1 trunc(C) 0 D(x) ...<br>"PK" 1 trunc(C) 1 D(x) ...<br><br>Once
 this is confirmed in the blockchain, we publish C to our limited social
 profiles (Twitter), or ABCX to a full profile (gist/reddit). ABCX can 
also be sent to key directories (like KeyBase) or key-directories can 
just scrape social profiles.<br><br>## Lookup<br>To confirm someone's ID
 you start by finding ABCX on their full social profile (or searching 
their social name on a key directory). Once you have ABCX, you check the
 blockchain for revocation of X, then confirm the blockchain has D that 
matches B. Then look up proofs on all the social profiles mentioned in 
B.<br><br>If this all passes you have the keys for the user.<br><br>## Revocation<br>To revoke publicly, you post an OP_RETURN message with X and the first 80 bits of C.<br>"PX" trunc(C) X<br><br>X can probably be calculated with PBKDF using the hash of AB as the salt.<br><br>## Notes<br>The
 purpose of D is to detect when someone is planning to impersonate you. 
There will probably be collisions in 32-bits but we can only fit so much
 in. I expect keydirectories may have a notification service to email 
you when a matching D appears.<br><br>If OP_RETURN is increased to 80bytes we can fit 10 extra D into each packet.<br><br>Mobile
 apps may choose to trust a key-directory, if they have a list of block 
headers the key-directory can still prove that the responses to queries 
have been put in the blockchain. Revocation is much weaker here (as you 
can't prove it doesn't exist), but multiple independent key-directories 
logging PX messages should be as good as reasonably practicable.<br><br>The economic value in brute-forcing someone's revocation key should be close to 0. Users should still pick a good one though.<br><br>Putting
 all of ABCX into the blockchain is do-able (P2SH), but not a socially 
acceptable use of bitcoin resources (and might get plugged with P2SH2).<br><br>I
 looked at better ways of encoding D - bloom tables, golomb coding, 
matrix filter. In the end this was the simplest and good enough (I 
think?).<br><br>I'd love some feedback, and I would still rather hear 
the feedback even if it will take too much time/effort to reword it in a
 nice way (so don't delete it just because you think it is too harsh).<br><br>Thanks<span class="HOEnZb"><font color="#888888"><br>-Ben<br></font></span></div>
<br>_______________________________________________<br>
Messaging mailing list<br>
<a href="mailto:Messaging@moderncrypto.org">Messaging@moderncrypto.org</a><br>
<a href="https://moderncrypto.org/mailman/listinfo/messaging" target="_blank">https://moderncrypto.org/mailman/listinfo/messaging</a><br>
<br></blockquote></div></div>