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 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 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 > >