diff options
| author | Daniel Lidstrom <lidstrom83@gmail.com> | 2013-10-03 10:16:27 -0600 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2013-10-03 16:16:34 +0000 |
| commit | ae2e518f1fdb7d11da8bb0f90a6b4e600bb64327 (patch) | |
| tree | fe92919b2732d89048e81ca35079d51832f1dd24 | |
| parent | b3158ee90084c81bfe3f0da7f9dd7ad24b4a53f6 (diff) | |
| download | pi-bitcoindev-ae2e518f1fdb7d11da8bb0f90a6b4e600bb64327.tar.gz pi-bitcoindev-ae2e518f1fdb7d11da8bb0f90a6b4e600bb64327.zip | |
Re: [Bitcoin-development] Identity protocol observation
| -rw-r--r-- | 5d/d3c18fa9ef713259b3f4c083c5f5d7d0337fb7 | 388 |
1 files changed, 388 insertions, 0 deletions
diff --git a/5d/d3c18fa9ef713259b3f4c083c5f5d7d0337fb7 b/5d/d3c18fa9ef713259b3f4c083c5f5d7d0337fb7 new file mode 100644 index 000000000..aa2134c1a --- /dev/null +++ b/5d/d3c18fa9ef713259b3f4c083c5f5d7d0337fb7 @@ -0,0 +1,388 @@ +Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] + helo=mx.sourceforge.net) + by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <lidstrom83@gmail.com>) id 1VRlZq-0004GQ-HJ + for bitcoin-development@lists.sourceforge.net; + Thu, 03 Oct 2013 16:16:34 +0000 +Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.223.169 as permitted sender) + client-ip=209.85.223.169; envelope-from=lidstrom83@gmail.com; + helo=mail-ie0-f169.google.com; +Received: from mail-ie0-f169.google.com ([209.85.223.169]) + by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1VRlZp-000434-9O + for bitcoin-development@lists.sourceforge.net; + Thu, 03 Oct 2013 16:16:34 +0000 +Received: by mail-ie0-f169.google.com with SMTP id tp5so6026485ieb.14 + for <bitcoin-development@lists.sourceforge.net>; + Thu, 03 Oct 2013 09:16:27 -0700 (PDT) +MIME-Version: 1.0 +X-Received: by 10.42.82.196 with SMTP id e4mr1567624icl.58.1380816987793; Thu, + 03 Oct 2013 09:16:27 -0700 (PDT) +Received: by 10.64.135.2 with HTTP; Thu, 3 Oct 2013 09:16:27 -0700 (PDT) +In-Reply-To: <CANEZrP1Eb2DS7LOg_wp-H9y-WaSWKj1x7f4gE7mK7RyusaamyA@mail.gmail.com> +References: <CADjHg8Hh7Vm+CJpZH1-=0FsAxup7z42i2es-j2AW27OMt_SKTw@mail.gmail.com> + <CADjHg8GDqAFsmO-yNSPpgcvm4uRfwz4z7u-gm8Ur7ScuB=6joA@mail.gmail.com> + <CANEZrP3NekFg-czGGnEiyomCigMcY=beg-+X61_LLg9kqAPy-w@mail.gmail.com> + <CADjHg8G8v_oN=CWCVy8agvjP6cAMkACav74SaYRrTGf+c0nVeA@mail.gmail.com> + <CANEZrP1Eb2DS7LOg_wp-H9y-WaSWKj1x7f4gE7mK7RyusaamyA@mail.gmail.com> +Date: Thu, 3 Oct 2013 10:16:27 -0600 +Message-ID: <CADjHg8ECzpv8Yqy02eAcOQC0iTY_B2Wf4GOJQqbJfLCYL6Oi+A@mail.gmail.com> +From: Daniel Lidstrom <lidstrom83@gmail.com> +To: Mike Hearn <mike@plan99.net> +Content-Type: multipart/alternative; boundary=20cf30363fa10eb18d04e7d88265 +X-Spam-Score: -0.3 (/) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. + See + http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block + for more information. [URIs: doubleclick.net] + -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for + sender-domain + 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider + (lidstrom83[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in + digit (lidstrom83[at]gmail.com) + 1.0 HTML_MESSAGE BODY: HTML included in message + -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from + author's domain + 0.1 DKIM_SIGNED Message has a DKIM or DK signature, + not necessarily valid + -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature +X-Headers-End: 1VRlZp-000434-9O +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] Identity protocol observation +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Thu, 03 Oct 2013 16:16:34 -0000 + +--20cf30363fa10eb18d04e7d88265 +Content-Type: text/plain; charset=ISO-8859-1 + +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@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@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@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@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@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@lists.sourceforge.net +>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development +>>>> +>>>> +>>> +>> +> + +--20cf30363fa10eb18d04e7d88265 +Content-Type: text/html; charset=ISO-8859-1 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div>Names clearly solve a different problem than that, bu= +t we still use them, so they must be solving _some_ problem :p=A0 In this c= +ase they're a unique identifier humans can remember after a bit of use = +and easily communicate to each other with little room for error.=A0 Securel= +y mapping them to public keys would make key verification simpler.=A0 Simpl= +er than checking a much larger key fingerprint, at least.=A0 Like I said, i= +t's probably a niche product ;)<br> +<br></div>I used to remember dozens of phone numbers before my phone did it= + for me, but maybe I was just weird.<br></div><div class=3D"gmail_extra"><b= +r><br><div class=3D"gmail_quote">On Thu, Oct 3, 2013 at 9:22 AM, Mike Hearn= + <span dir=3D"ltr"><<a href=3D"mailto:mike@plan99.net" target=3D"_blank"= +>mike@plan99.net</a>></span> wrote:<br> +<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= +x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>1) Generate sacrifice = +proof file using an app</div><div>2) Load file into browser</div><div>3) Su= +rf</div> +<div><br></div><div>Where are the names in that design? I'm not sure wh= +ere NameCoin comes into this. The point of a sacrifice is it's an anony= +mous identity, there's no point attaching a name to it.</div> +<div><br></div><div>BTW I keep phone numbers in an address book ;)=A0</div>= +<div><br></div><div><br></div></div><div class=3D"HOEnZb"><div class=3D"h5"= +><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu, Oct = +3, 2013 at 5:16 PM, Daniel Lidstrom <span dir=3D"ltr"><<a href=3D"mailto= +:lidstrom83@gmail.com" target=3D"_blank">lidstrom83@gmail.com</a>></span= +> wrote:<br> + +<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= +x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Fair enough, though pe= +ople still manage okay with phone numbers.=A0 And a decentralized naming sy= +stem seems to come at great cost - with namecoin you need the whole blockch= +ain to resolve names without trust.=A0 Strip out a bell and whistle - meani= +ngfulness and transferability of names - and you get a simple, rudimentary = +(spam killing!) system that scales on any device.=A0 I'll only argue th= +at it seems to be Good Enough <i>for the types of people who might care abo= +ut=A0decentralized names</i>.=A0 Probably a very small set :)<br> + + +</div></div><div><div><div class=3D"gmail_extra"><br><br><div class=3D"gmai= +l_quote">On Thu, Oct 3, 2013 at 8:00 AM, Mike Hearn <span dir=3D"ltr"><<= +a href=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>>= +</span> wrote:<br> + + +<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= +x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Interesting observation, th= +anks.<div><br></div><div>I'd think any competent implementation of such= + an identity scheme would not involve end users directly handling randomize= +d nonsense words, however. I always imagined a sacrifice as being a file th= +at you make with a GUI tool and load into a browser extension.</div> + + + +</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote"><div><d= +iv>On Thu, Oct 3, 2013 at 3:35 PM, Daniel Lidstrom <span dir=3D"ltr"><<a= + href=3D"mailto:lidstrom83@gmail.com" target=3D"_blank">lidstrom83@gmail.co= +m</a>></span> wrote:<br> + + + +</div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo= +rder-left:1px #ccc solid;padding-left:1ex"><div><div><div dir=3D"ltr"><div>= +A couple more thoughts on this:<br><br></div><div>1) Both c and k can be ke= +pt if c is pronounced 'ch', giving ~10.9 bits per phoneme.<br> + + + +</div><div>2) An extra phoneme (4 encode 43 bits total) gives room to put e= +xtra 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.=A0 This would give the user 32 random names per sacrifice to cho= +ose from, and 38 bits to encode its location in the blockchain, which is en= +ough for pretty large blocks.<br> + + + + +<br></div><div>Sample 4 phoneme names:<br>~milmoz-vyrnyx<br>~mypnoz-fojzas<= +br>~sawfex-bovlec<br>~fidhut-guvgis<br>~bobfej-jessuk<br>~furcos-diwhuw<br>= +~wokryx-wilrox<br>~bygbyl-caggos<br>~vewcyv-jyjsal<br>~daxsaf-cywkul<br> + + + + +<br></div><div>They're not that bad IMHO, especially if you get to pick= + a decent one from a bunch.<br></div></div><div><div><div class=3D"gmail_ex= +tra"><br><br><div class=3D"gmail_quote">On Thu, Oct 3, 2013 at 3:35 AM, Dan= +iel Lidstrom <span dir=3D"ltr"><<a href=3D"mailto:lidstrom83@gmail.com" = +target=3D"_blank">lidstrom83@gmail.com</a>></span> wrote:<br> + + + + +<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= +x #ccc solid;padding-left:1ex"><div dir=3D"ltr">The location of a tx in the= + blockchain can be encoded in n=3Dlog2(h)+log2(t) bits, where h is the bloc= +k height, and t is the number of transactions in the block.=A0 Currently h~= +250,000 and t~500, so n~27.=A0 A CVC phoneme encodes ~10.7 bits *, so a tra= +nsaction today can be located in the blockchain with 3 of these, e.g. reb-m= +izvig.=A0 This is reasonably short, readable and memorable.<br> + + + + + +<br>The identity protocol Jeff Garzik is working on will link a public key = +fingerprint to a miner sacrifice transaction.=A0 This tx could in turn be u= +niquely described with a short name as above.=A0 Associating this name with= + the public key becomes secure once the tx is sufficiently buried in the bl= +ockchain.=A0 In the identity protocol, lightweight clients check the validi= +ty of a sacrifice tx by checking that its merkle path is valid.=A0 But this= + path encodes, via the ordering of the hashes at each level, the location o= +f the transaction in the block, so the lightweight client can verify the sa= +crifice tx's short name using only the information he already has.<br> + + + + + +<br>Some more random names:<br>vec-halhic<br>wom-vizpyd<br>guv-zussof<br>jo= +g-copwug<br>seg-rizges<br>jyg-somgod<br>pax-synjem<br>zyg-zuxdyj<br>gid-mut= +dyj<br>rel-hyrdaj<br><br>Sources of inspiration:<br><a href=3D"http://urbit= +.org" target=3D"_blank">urbit.org</a><br> + + + + + +<a href=3D"https://en.bitcoin.it/wiki/Identity_protocol_v1" target=3D"_blan= +k">https://en.bitcoin.it/wiki/Identity_protocol_v1</a><br><br>* This is som= +ewhat restricted: I disallowed q for obvious reasons and k because it confl= +icts with c, and c looks much softer and less like Klingon.=A0 H is allowed= + for the first consonant, but not the second, and x is allowed for the last= + one, but not the first one.=A0 Y is a vowel, but not a consonant.=A0 Maybe= + these weren't quite the right choices.=A0 Paint away!<br> + + + + + +</div> +</blockquote></div><br></div> +</div></div><br></div></div>-----------------------------------------------= +-------------------------------<br> +October Webinars: Code for Performance<br> +Free Intel webinars can help you accelerate application performance.<br> +Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most fr= +om<br> +the latest Intel processors and coprocessors. See abstracts and register &g= +t;<br> +<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D60134791&iu= +=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam= +pad/clk?id=3D60134791&iu=3D/4140/ostg.clktrk</a><br>___________________= +____________________________<br> + + + + +Bitcoin-development mailing list<br> +<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla= +nk">Bitcoin-development@lists.sourceforge.net</a><br> +<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development= +" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de= +velopment</a><br> +<br></blockquote></div><br></div> +</blockquote></div><br></div> +</div></div></blockquote></div><br></div> +</div></div></blockquote></div><br></div> + +--20cf30363fa10eb18d04e7d88265-- + + |