From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VRkeA-0006aI-64 for bitcoin-development@lists.sourceforge.net; Thu, 03 Oct 2013 15:16:58 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.223.170 as permitted sender) client-ip=209.85.223.170; envelope-from=lidstrom83@gmail.com; helo=mail-ie0-f170.google.com; Received: from mail-ie0-f170.google.com ([209.85.223.170]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VRke9-0003bK-0y for bitcoin-development@lists.sourceforge.net; Thu, 03 Oct 2013 15:16:58 +0000 Received: by mail-ie0-f170.google.com with SMTP id x13so5990881ief.29 for ; Thu, 03 Oct 2013 08:16:51 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.61.137 with SMTP id p9mr2522836igr.45.1380813411527; Thu, 03 Oct 2013 08:16:51 -0700 (PDT) Received: by 10.64.135.2 with HTTP; Thu, 3 Oct 2013 08:16:51 -0700 (PDT) In-Reply-To: References: Date: Thu, 3 Oct 2013 09:16:51 -0600 Message-ID: From: Daniel Lidstrom To: Mike Hearn Content-Type: multipart/alternative; boundary=047d7bdca5dce56bff04e7d7aca6 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: 1VRke9-0003bK-0y 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 15:16:58 -0000 --047d7bdca5dce56bff04e7d7aca6 Content-Type: text/plain; charset=ISO-8859-1 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 >> >> > --047d7bdca5dce56bff04e7d7aca6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Fair enough, though people still manage okay with pho= ne numbers.=A0 And a decentralized naming system seems to come at great cos= t - with namecoin you need the whole blockchain to resolve names without tr= ust.=A0 Strip out a bell and whistle - meaningfulness and transferability o= f names - and you get a simple, rudimentary (spam killing!) system that sca= les on any device.=A0 I'll only argue that it seems to be Good Enough <= i>for the types of people who might care about=A0decentralized names.= =A0 Probably a very small set :)


O= n Thu, Oct 3, 2013 at 8:00 AM, Mike Hearn <mike@plan99.net> wr= ote:
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 <lids= trom83@gmail.com> wrote:
A couple more thoughts on this:

1) Both c a= nd k can be kept if c is pronounced 'ch', giving ~10.9 bits per pho= neme.
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



--047d7bdca5dce56bff04e7d7aca6--