Daniel Lidstrom [ARCHIVE] on Nostr: 📅 Original date posted:2013-10-03 📝 Original message:Names clearly solve a ...
📅 Original date posted:2013-10-03
📝 Original message: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 <mike at plan99.net> 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 <lidstrom83 at gmail.com>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 <mike at plan99.net> 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 <lidstrom83 at gmail.com>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 <lidstrom83 at 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!
>>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> 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 at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131003/c437c1d1/attachment.html>;
📝 Original message: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 <mike at plan99.net> 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 <lidstrom83 at gmail.com>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 <mike at plan99.net> 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 <lidstrom83 at gmail.com>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 <lidstrom83 at 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!
>>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> 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 at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131003/c437c1d1/attachment.html>;