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.
On 17 December 2014 at 21:59, Joseph Bonneau <[email protected]> wrote: > Hi Ben- > > Is what you're describing similar to Onename (https://onename.io/)? 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. > > Joe > > On Fri, Dec 12, 2014 at 9:24 PM, Ben Harris <[email protected]> wrote: > >> Hi All, >> >> 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. >> >> The rough idea is to use the 40 socially-responsible bytes in OP_RETURN >> to encode something that allows: >> - Me to see that my key-information has been published (block chain is >> public, so yay). >> - Me to see that other people aren't trying to imitate me. >> - Everyone to see when I have revoked a key. >> - My contacts to find my key-information. >> >> 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. >> >> 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. >> >> C is then your 224 bit key ID. >> 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). >> >> 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. >> >> For the first two profiles publish >> "PK" 0 C |D| D(0) D(1) >> 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. >> >> 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 >> "PK" 1 trunc(C) 0 D(x) ... >> "PK" 1 trunc(C) 1 D(x) ... >> >> 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. >> >> ## Lookup >> 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. >> >> If this all passes you have the keys for the user. >> >> ## Revocation >> To revoke publicly, you post an OP_RETURN message with X and the first 80 >> bits of C. >> "PX" trunc(C) X >> >> X can probably be calculated with PBKDF using the hash of AB as the salt. >> >> ## Notes >> 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. >> >> If OP_RETURN is increased to 80bytes we can fit 10 extra D into each >> packet. >> >> 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. >> >> The economic value in brute-forcing someone's revocation key should be >> close to 0. Users should still pick a good one though. >> >> 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). >> >> 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?). >> >> 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). >> >> Thanks >> -Ben >> >> _______________________________________________ >> Messaging mailing list >> [email protected] >> https://moderncrypto.org/mailman/listinfo/messaging >> >>
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
