From: Daniel Lidstrom <lidstrom83@gmail•com>
To: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Identity protocol observation
Date: Thu, 3 Oct 2013 07:35:32 -0600 [thread overview]
Message-ID: <CADjHg8GDqAFsmO-yNSPpgcvm4uRfwz4z7u-gm8Ur7ScuB=6joA@mail.gmail.com> (raw)
In-Reply-To: <CADjHg8Hh7Vm+CJpZH1-=0FsAxup7z42i2es-j2AW27OMt_SKTw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2539 bytes --]
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!
>
[-- Attachment #2: Type: text/html, Size: 3125 bytes --]
next prev parent reply other threads:[~2013-10-03 13:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-03 9:35 Daniel Lidstrom
2013-10-03 13:35 ` Daniel Lidstrom [this message]
2013-10-03 14:00 ` Mike Hearn
2013-10-03 15:16 ` Daniel Lidstrom
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='CADjHg8GDqAFsmO-yNSPpgcvm4uRfwz4z7u-gm8Ur7ScuB=6joA@mail.gmail.com' \
--to=lidstrom83@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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