Names clearly solve a different problem than that, but we still use them, so they must be solving _some_ problem :p In this case they're a unique identifier humans can remember after a bit of use and easily communicate to each other with little room for error. Securely mapping them to public keys would make key verification simpler. Simpler than checking a much larger key fingerprint, at least. Like I said, it's probably a niche product ;) I used to remember dozens of phone numbers before my phone did it for me, but maybe I was just weird. On Thu, Oct 3, 2013 at 9:22 AM, Mike Hearn wrote: > 1) Generate sacrifice proof file using an app > 2) Load file into browser > 3) Surf > > Where are the names in that design? I'm not sure where NameCoin comes into > this. The point of a sacrifice is it's an anonymous identity, there's no > point attaching a name to it. > > BTW I keep phone numbers in an address book ;) > > > > > On Thu, Oct 3, 2013 at 5:16 PM, Daniel Lidstrom wrote: > >> 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 >>>> >>>> >>> >> >