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