From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VRjS4-0005cA-VW for bitcoin-development@lists.sourceforge.net; Thu, 03 Oct 2013 14:00:25 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.43 as permitted sender) client-ip=209.85.214.43; envelope-from=mh.in.england@gmail.com; helo=mail-bk0-f43.google.com; Received: from mail-bk0-f43.google.com ([209.85.214.43]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VRjS3-0008Lz-2U for bitcoin-development@lists.sourceforge.net; Thu, 03 Oct 2013 14:00:24 +0000 Received: by mail-bk0-f43.google.com with SMTP id mz13so938801bkb.2 for ; Thu, 03 Oct 2013 07:00:16 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.205.78.5 with SMTP id zk5mr7862203bkb.25.1380808816402; Thu, 03 Oct 2013 07:00:16 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.204.237.74 with HTTP; Thu, 3 Oct 2013 07:00:16 -0700 (PDT) In-Reply-To: References: Date: Thu, 3 Oct 2013 16:00:16 +0200 X-Google-Sender-Auth: R4sx_WjKj6JoQ93_mRIfqGDTaJ0 Message-ID: From: Mike Hearn To: Daniel Lidstrom Content-Type: multipart/alternative; boundary=f46d041038a701570904e7d69b15 X-Spam-Score: -0.5 (/) 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 (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 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: 1VRjS3-0008Lz-2U 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 14:00:25 -0000 --f46d041038a701570904e7d69b15 Content-Type: text/plain; charset=UTF-8 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 > > --f46d041038a701570904e7d69b15 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Interesting observation, thanks.

I'= d think any competent implementation of such an identity scheme would not i= nvolve end users directly handling randomized nonsense words, however. I al= ways 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><= /span> 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 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.=C2=A0 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<= 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 Th= u, 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=3Dlog2(h)+log2(t) bits, where h is the bloc= k height, and t is the number of transactions in the block.=C2=A0 Currently= h~250,000 and t~500, so n~27.=C2=A0 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.=C2=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.=C2=A0 This tx could in turn b= e uniquely described with a short name as above.=C2=A0 Associating this nam= e with the public key becomes secure once the tx is sufficiently buried in = the blockchain.=C2=A0 In the identity protocol, lightweight clients check t= he validity of a sacrifice tx by checking that its merkle path is valid.=C2= =A0 But this path encodes, via the ordering of the hashes at each level, th= e location of the transaction in the block, so the lightweight client can v= erify the sacrifice tx's short name using only the information he alrea= dy 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.=C2=A0 H is allo= wed for the first consonant, but not the second, and x is allowed for the l= ast one, but not the first one.=C2=A0 Y is a vowel, but not a consonant.=C2= =A0 Maybe these weren't quite the right choices.=C2=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-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--f46d041038a701570904e7d69b15--