<div dir="ltr">Looks similar, but pushing the whole object onto the blockchain instead of a tiny amount. Probably a better solution than trying to cram as much as possible into 40 bytes on a protocol that is hostile to non-transactional data.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 17 December 2014 at 21:59, Joseph Bonneau <span dir="ltr"><<a href="mailto:jbonneau@gmail.com" target="_blank">jbonneau@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Ben-<div><br></div><div>Is what you're describing similar to Onename (<a href="https://onename.io/" target="_blank">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"><div><div class="h5">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:</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><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><font color="#888888"><br>-Ben<br></font></span></div>
<br></div></div>_______________________________________________<br>
Messaging mailing list<br>
<a href="mailto:Messaging@moderncrypto.org" target="_blank">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>
</blockquote></div><br></div>