summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMike Hearn <mike@plan99.net>2013-10-03 16:00:16 +0200
committerbitcoindev <bitcoindev@gnusha.org>2013-10-03 14:00:25 +0000
commitd9e51117245f073cacd02962a42eabde19b01f50 (patch)
tree7b35413bd1107ded7b2a9db793546cba991809df
parentef437b3dfdb87ad9e85b88c07d990ab5d75576da (diff)
downloadpi-bitcoindev-d9e51117245f073cacd02962a42eabde19b01f50.tar.gz
pi-bitcoindev-d9e51117245f073cacd02962a42eabde19b01f50.zip
Re: [Bitcoin-development] Identity protocol observation
-rw-r--r--66/9bc7678659d0158d4a68b3f2ebcf2cc1a11f8d260
1 files changed, 260 insertions, 0 deletions
diff --git a/66/9bc7678659d0158d4a68b3f2ebcf2cc1a11f8d b/66/9bc7678659d0158d4a68b3f2ebcf2cc1a11f8d
new file mode 100644
index 000000000..670478fe6
--- /dev/null
+++ b/66/9bc7678659d0158d4a68b3f2ebcf2cc1a11f8d
@@ -0,0 +1,260 @@
+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 <mh.in.england@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
+ 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: <CADjHg8GDqAFsmO-yNSPpgcvm4uRfwz4z7u-gm8Ur7ScuB=6joA@mail.gmail.com>
+References: <CADjHg8Hh7Vm+CJpZH1-=0FsAxup7z42i2es-j2AW27OMt_SKTw@mail.gmail.com>
+ <CADjHg8GDqAFsmO-yNSPpgcvm4uRfwz4z7u-gm8Ur7ScuB=6joA@mail.gmail.com>
+Date: Thu, 3 Oct 2013 16:00:16 +0200
+X-Google-Sender-Auth: R4sx_WjKj6JoQ93_mRIfqGDTaJ0
+Message-ID: <CANEZrP3NekFg-czGGnEiyomCigMcY=beg-+X61_LLg9kqAPy-w@mail.gmail.com>
+From: Mike Hearn <mike@plan99.net>
+To: Daniel Lidstrom <lidstrom83@gmail.com>
+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 <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 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 <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
+>
+>
+
+--f46d041038a701570904e7d69b15
+Content-Type: text/html; charset=UTF-8
+Content-Transfer-Encoding: quoted-printable
+
+<div dir=3D"ltr">Interesting observation, thanks.<div><br></div><div>I&#39;=
+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.</div>
+</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu,=
+ Oct 3, 2013 at 3:35 PM, Daniel Lidstrom <span dir=3D"ltr">&lt;<a href=3D"m=
+ailto: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>A couple more thoughts=
+ on this:<br><br></div><div>1) Both c and k can be kept 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.=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.<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 class=3D"HOEnZb"><div class=
+=3D"h5"><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Th=
+u, Oct 3, 2013 at 3:35 AM, 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">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.<br>
+
+
+<br>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&#39;s short name using only the information he alrea=
+dy 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.=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&#39;t quite the right choices.=C2=A0 Paint away!<br>
+
+
+</div>
+</blockquote></div><br></div>
+</div></div><br>-----------------------------------------------------------=
+-------------------<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">Bitcoin-develo=
+pment@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>
+
+--f46d041038a701570904e7d69b15--
+
+