path: root/5d/d3c18fa9ef713259b3f4c083c5f5d7d0337fb7

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&#39;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&#39;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">&lt;<a href=3D"mailto:mike@plan99.net" target=3D"_blank"=
>mike@plan99.net</a>&gt;</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&#39;m not sure wh=
ere NameCoin comes into this. The point of a sacrifice is it&#39;s an anony=
mous identity, there&#39;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">&lt;<a href=3D"mailto=
:lidstrom83@gmail.com" target=3D"_blank">lidstrom83@gmail.com</a>&gt;</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&#39;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">&lt;<=
a href=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>&gt;=
</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&#39;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">&lt;<a=
 href=3D"mailto:lidstrom83@gmail.com" target=3D"_blank">lidstrom83@gmail.co=
m</a>&gt;</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 &#39;ch&#39;, 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&#39;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">&lt;<a href=3D"mailto:lidstrom83@gmail.com" =
target=3D"_blank">lidstrom83@gmail.com</a>&gt;</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&#39;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&#39;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&amp;iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D60134791&amp;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--