summaryrefslogtreecommitdiff
path: root/66/9bc7678659d0158d4a68b3f2ebcf2cc1a11f8d
blob: 670478fe6ff1ad163ce04c04a56ced641e0627f0 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
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--