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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <lidstrom83@gmail.com>) id 1VRfJo-00057E-Ku
for bitcoin-development@lists.sourceforge.net;
Thu, 03 Oct 2013 09:35:36 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.223.176 as permitted sender)
client-ip=209.85.223.176; envelope-from=lidstrom83@gmail.com;
helo=mail-ie0-f176.google.com;
Received: from mail-ie0-f176.google.com ([209.85.223.176])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VRfJn-0004iX-RO
for bitcoin-development@lists.sourceforge.net;
Thu, 03 Oct 2013 09:35:36 +0000
Received: by mail-ie0-f176.google.com with SMTP id as1so4883320iec.35
for <bitcoin-development@lists.sourceforge.net>;
Thu, 03 Oct 2013 02:35:30 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.42.62.196 with SMTP id z4mr695355ich.49.1380792930373; Thu,
03 Oct 2013 02:35:30 -0700 (PDT)
Received: by 10.64.135.2 with HTTP; Thu, 3 Oct 2013 02:35:30 -0700 (PDT)
Date: Thu, 3 Oct 2013 03:35:30 -0600
Message-ID: <CADjHg8Hh7Vm+CJpZH1-=0FsAxup7z42i2es-j2AW27OMt_SKTw@mail.gmail.com>
From: Daniel Lidstrom <lidstrom83@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=90e6ba614a761f990804e7d2e810
X-Spam-Score: -0.3 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-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)
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: bitcoin.it]
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: 1VRfJn-0004iX-RO
Subject: [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 09:35:36 -0000
--90e6ba614a761f990804e7d2e810
Content-Type: text/plain; charset=ISO-8859-1
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!
--90e6ba614a761f990804e7d2e810
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<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 block height, and t is the number o=
f 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 transaction today can be located i=
n the blockchain with 3 of these, e.g. reb-mizvig.=A0 This is reasonably sh=
ort, readable and memorable.<br>
<br>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.<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">urbit.org</a><br>
<a href=3D"https://en.bitcoin.it/wiki/Identity_protocol_v1">https://en.bitc=
oin.it/wiki/Identity_protocol_v1</a><br><br>* 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.=A0 H is allowed for the first con=
sonant, 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!<br>
</div>
--90e6ba614a761f990804e7d2e810--
|
