public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Daniel Lidstrom <lidstrom83@gmail.com>
To: Mike Hearn <mike@plan99.net>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Identity protocol observation
Date: Thu, 3 Oct 2013 09:16:51 -0600	[thread overview]
Message-ID: <CADjHg8G8v_oN=CWCVy8agvjP6cAMkACav74SaYRrTGf+c0nVeA@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP3NekFg-czGGnEiyomCigMcY=beg-+X61_LLg9kqAPy-w@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4332 bytes --]

Fair enough, though people still manage okay with phone numbers.  And a
decentralized naming system seems to come at great cost - with namecoin you
need the whole blockchain to resolve names without trust.  Strip out a bell
and whistle - meaningfulness and transferability of names - and you get a
simple, rudimentary (spam killing!) system that scales on any device.  I'll
only argue that it seems to be Good Enough *for the types of people who
might care about decentralized names*.  Probably a very small set :)


On Thu, Oct 3, 2013 at 8:00 AM, Mike Hearn <mike@plan99.net> wrote:

> Interesting observation, thanks.
>
> I'd think any competent implementation of such an identity scheme would
> not involve end users directly handling randomized nonsense words, however.
> I always imagined a sacrifice as being a file that you make with a GUI tool
> and load into a browser extension.
>
>
> On Thu, Oct 3, 2013 at 3:35 PM, Daniel Lidstrom <lidstrom83@gmail.com>wrote:
>
>> A couple more thoughts on this:
>>
>> 1) Both c and k can be kept if c is pronounced 'ch', giving ~10.9 bits
>> per phoneme.
>> 2) An extra phoneme (4 encode 43 bits total) gives room to put extra
>> information into the name, e.g. the first 5 bits could be input as the key
>> to a PRP that permutes the last 38 back to a standard encoding of a tx
>> location.  This would give the user 32 random names per sacrifice to choose
>> from, and 38 bits to encode its location in the blockchain, which is enough
>> for pretty large blocks.
>>
>> Sample 4 phoneme names:
>> ~milmoz-vyrnyx
>> ~mypnoz-fojzas
>> ~sawfex-bovlec
>> ~fidhut-guvgis
>> ~bobfej-jessuk
>> ~furcos-diwhuw
>> ~wokryx-wilrox
>> ~bygbyl-caggos
>> ~vewcyv-jyjsal
>> ~daxsaf-cywkul
>>
>> They're not that bad IMHO, especially if you get to pick a decent one
>> from a bunch.
>>
>>
>> On Thu, Oct 3, 2013 at 3:35 AM, Daniel Lidstrom <lidstrom83@gmail.com>wrote:
>>
>>> The location of a tx in the blockchain can be encoded in
>>> n=log2(h)+log2(t) bits, where h is the block height, and t is the number of
>>> transactions in the block.  Currently h~250,000 and t~500, so n~27.  A CVC
>>> phoneme encodes ~10.7 bits *, so a transaction today can be located in the
>>> blockchain with 3 of these, e.g. reb-mizvig.  This is reasonably short,
>>> readable and memorable.
>>>
>>> The identity protocol Jeff Garzik is working on will link a public key
>>> fingerprint to a miner sacrifice transaction.  This tx could in turn be
>>> uniquely described with a short name as above.  Associating this name with
>>> the public key becomes secure once the tx is sufficiently buried in the
>>> blockchain.  In the identity protocol, lightweight clients check the
>>> validity of a sacrifice tx by checking that its merkle path is valid.  But
>>> this path encodes, via the ordering of the hashes at each level, the
>>> location of the transaction in the block, so the lightweight client can
>>> verify the sacrifice tx's short name using only the information he already
>>> has.
>>>
>>> Some more random names:
>>> vec-halhic
>>> wom-vizpyd
>>> guv-zussof
>>> jog-copwug
>>> seg-rizges
>>> jyg-somgod
>>> pax-synjem
>>> zyg-zuxdyj
>>> gid-mutdyj
>>> rel-hyrdaj
>>>
>>> Sources of inspiration:
>>> urbit.org
>>> https://en.bitcoin.it/wiki/Identity_protocol_v1
>>>
>>> * This is somewhat restricted: I disallowed q for obvious reasons and k
>>> because it conflicts with c, and c looks much softer and less like
>>> Klingon.  H is allowed for the first consonant, but not the second, and x
>>> is allowed for the last one, but not the first one.  Y is a vowel, but not
>>> a consonant.  Maybe these weren't quite the right choices.  Paint away!
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> October Webinars: Code for Performance
>> Free Intel webinars can help you accelerate application performance.
>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
>> from
>> the latest Intel processors and coprocessors. See abstracts and register >
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 5815 bytes --]

  reply	other threads:[~2013-10-03 15:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-03  9:35 [Bitcoin-development] Identity protocol observation Daniel Lidstrom
2013-10-03 13:35 ` Daniel Lidstrom
2013-10-03 14:00   ` Mike Hearn
2013-10-03 15:16     ` Daniel Lidstrom [this message]
2013-10-03 15:22       ` Mike Hearn
2013-10-03 16:16         ` Daniel Lidstrom

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CADjHg8G8v_oN=CWCVy8agvjP6cAMkACav74SaYRrTGf+c0nVeA@mail.gmail.com' \
    --to=lidstrom83@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=mike@plan99.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox