<div dir="ltr">Hi Ben, your proposed idea seems like one of many applications of what is being referred to as "proof of publication" applications of a blockchain.<br><br><div>Proof of Publication seems to be a fairly hot topic in both crypto startup land at the moment with the announcement of Ethereum fork Eris and a long thread on the bitcoin-dev mailing list.<br><br><a href="https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg06570.html">https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg06570.html</a><br><br>One of the central debates is the concept of keeping a tree headers in the blockchain like Keybase and Factom do allowing an efficient proof of timestamping of data. Or hashed directly into the blockchain as you and Peter Todd proposed to permit proof of non-publication.<br><br>Anyway here is the a link to the discussion. <br><br><a href="https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg06570.html">https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg06570.html</a><br><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">US number: +1 650-492-8286<div><a href="https://play.google.com/store/apps/details?id=org.thoughtcrime.securesms&hl=en" target="_blank">Text Secure</a>: +1650-862-5992</div><div>Surespot/Wickr: zmanian<br><a href="https://raw.github.com/zmanian/pub_keys/master/gpg/%3Czaki@manian.org%3E.public.gpg-key" target="_blank">Public Key</a></div></div></div></div>
<br><div class="gmail_quote">On Mon, Dec 22, 2014 at 8:11 PM, Ben Harris <span dir="ltr"><<a href="mailto:mail@bharr.is" target="_blank">mail@bharr.is</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">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="HOEnZb"><div class="h5"><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>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><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>
</div></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><br></div>