From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: References: Date: Thu, 3 Oct 2013 10:16:27 -0600 Message-ID: From: Daniel Lidstrom To: Mike Hearn 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 Subject: Re: [Bitcoin-development] Identity protocol observation X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 >>>> >>>> >>> >> > --20cf30363fa10eb18d04e7d88265 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
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 ;)

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) Su= rf

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.

BTW I keep phone numbers in an address book ;)=A0
=




On Thu, Oct = 3, 2013 at 5:16 PM, Daniel Lidstrom <lidstrom83@gmail.com> wrote:
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 for the types of people who might care abo= ut=A0decentralized names.=A0 Probably a very small set :)


On Thu, Oct 3, 2013 at 8:00 AM, Mike Hearn <<= a href=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.net>= wrote:
Interesting observation, th= anks.

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.


On Thu, Oct 3, 2013 at 3:35 PM, Daniel Lidstrom <lidstrom83@gmail.co= m> wrote:
= A couple more thoughts on this:

1) Both c and k can be ke= pt if c is pronounced 'ch', giving ~10.9 bits per phoneme.
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.

Sample 4 phoneme names:
~milmoz-vyrnyx
~mypnoz-fojzas<= br>~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, Dan= iel Lidstrom <lidstrom83@gmail.com> wrote:
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.

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.

Some more random names:
vec-halhic
wom-vizpyd
guv-zussof
jo= g-copwug
seg-rizges
jyg-somgod
pax-synjem
zyg-zuxdyj
gid-mut= dyj
rel-hyrdaj

Sources of inspiration:
urbit.org
https://en.bitcoin.it/wiki/Identity_protocol_v1

* 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!


-----------------------------------------------= -------------------------------
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 fr= om
the latest Intel processors and coprocessors. See abstracts and register &g= t;
http://pubads.g.doubleclick.net/gam= pad/clk?id=3D60134791&iu=3D/4140/ostg.clktrk
___________________= ____________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment





--20cf30363fa10eb18d04e7d88265--