Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VRj4L-0000Fr-Ct for bitcoin-development@lists.sourceforge.net; Thu, 03 Oct 2013 13:35:53 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.223.174 as permitted sender) client-ip=209.85.223.174; envelope-from=lidstrom83@gmail.com; helo=mail-ie0-f174.google.com; Received: from mail-ie0-f174.google.com ([209.85.223.174]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VRj46-0005jZ-7B for bitcoin-development@lists.sourceforge.net; Thu, 03 Oct 2013 13:35:53 +0000 Received: by mail-ie0-f174.google.com with SMTP id u16so5425026iet.33 for ; Thu, 03 Oct 2013 06:35:32 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.39.51 with SMTP id m19mr2101718igk.51.1380807332735; Thu, 03 Oct 2013 06:35:32 -0700 (PDT) Received: by 10.64.135.2 with HTTP; Thu, 3 Oct 2013 06:35:32 -0700 (PDT) In-Reply-To: References: Date: Thu, 3 Oct 2013 07:35:32 -0600 Message-ID: From: Daniel Lidstrom To: Bitcoin Dev Content-Type: multipart/alternative; boundary=047d7bdc13129230fd04e7d64282 X-Spam-Score: -0.3 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (lidstrom83[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (lidstrom83[at]gmail.com) 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: bitcoin.it] 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.0 TIME_LIMIT_EXCEEDED Exceeded time limit / deadline X-Headers-End: 1VRj46-0005jZ-7B Subject: Re: [Bitcoin-development] Identity protocol observation X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 13:35:53 -0000 --047d7bdc13129230fd04e7d64282 Content-Type: text/plain; charset=ISO-8859-1 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 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! > --047d7bdc13129230fd04e7d64282 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
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) gi= ves room to put extra information into the name, e.g. the first 5 bits coul= d be input as the key to a PRP that permutes the last 38 back to a standard= encoding of a tx location.=A0 This would give the user 32 random names per= sacrifice to choose from, and 38 bits to encode its location in the blockc= hain, which is enough for pretty large blocks.

Sample 4 phoneme names:
~milmoz-vyrnyx
~mypnoz-fojzas<= br>~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.

<= br>
On Thu, Oct 3, 2013 at 3:35 AM, Daniel Lidstr= om <lidstrom83@gmail.com> wrote:
The location of a tx in the= blockchain can be encoded in n=3Dlog2(h)+log2(t) bits, where h is the bloc= k height, and t is the number of transactions in the block.=A0 Currently h~= 250,000 and t~500, so n~27.=A0 A CVC phoneme encodes ~10.7 bits *, so a tra= nsaction today can be located in the blockchain with 3 of these, e.g. reb-m= izvig.=A0 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.=A0 This tx could in turn be u= niquely described with a short name as above.=A0 Associating this name with= the public key becomes secure once the tx is sufficiently buried in the bl= ockchain.=A0 In the identity protocol, lightweight clients check the validi= ty of a sacrifice tx by checking that its merkle path is valid.=A0 But this= path encodes, via the ordering of the hashes at each level, the location o= f the transaction in the block, so the lightweight client can verify the sa= crifice tx's short name using only the information he already has.

Some more random names:
vec-halhic
wom-vizpyd
guv-zussof
jo= g-copwug
seg-rizges
jyg-somgod
pax-synjem
zyg-zuxdyj
gid-mut= dyj
rel-hyrdaj

Sources of inspiration:
urbit.org
https://en.bitcoin.it/wiki/Identity_protocol_v1

* This is som= ewhat restricted: I disallowed q for obvious reasons and k because it confl= icts with c, and c looks much softer and less like Klingon.=A0 H is allowed= for the first consonant, but not the second, and x is allowed for the last= one, but not the first one.=A0 Y is a vowel, but not a consonant.=A0 Maybe= these weren't quite the right choices.=A0 Paint away!

--047d7bdc13129230fd04e7d64282--