Mike Hearn [ARCHIVE] on Nostr: 📅 Original date posted:2013-10-03 📝 Original message:Interesting observation, ...
📅 Original date posted:2013-10-03
📝 Original message: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/f5469bbd/attachment.html>;
📝 Original message: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/f5469bbd/attachment.html>;