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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <melvincarvalho@gmail.com>) id 1Unn85-0007m1-KK
for bitcoin-development@lists.sourceforge.net;
Sat, 15 Jun 2013 09:50:41 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.217.181 as permitted sender)
client-ip=209.85.217.181; envelope-from=melvincarvalho@gmail.com;
helo=mail-lb0-f181.google.com;
Received: from mail-lb0-f181.google.com ([209.85.217.181])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Unn81-0004H8-Nf
for bitcoin-development@lists.sourceforge.net;
Sat, 15 Jun 2013 09:50:41 +0000
Received: by mail-lb0-f181.google.com with SMTP id w10so1267135lbi.12
for <bitcoin-development@lists.sourceforge.net>;
Sat, 15 Jun 2013 02:50:31 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.19.162 with SMTP id g2mr2751591lbe.9.1371289830942; Sat,
15 Jun 2013 02:50:30 -0700 (PDT)
Received: by 10.112.2.8 with HTTP; Sat, 15 Jun 2013 02:50:30 -0700 (PDT)
In-Reply-To: <201306111529.13657.luke@dashjr.org>
References: <CAKaEYhJ+v0NfbzVEDEUh69D-n_4=Nd544fsm0a++QwsqcS3RVw@mail.gmail.com>
<201306111529.13657.luke@dashjr.org>
Date: Sat, 15 Jun 2013 11:50:30 +0200
Message-ID: <CAKaEYhKjvtPf_Xs=Q8tAJt_7PuxCAnym2-kJadNoSdWCHjXNDA@mail.gmail.com>
From: Melvin Carvalho <melvincarvalho@gmail.com>
To: Luke-Jr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=14dae93d909241f14a04df2e4b70
X-Spam-Score: -0.6 (/)
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
(melvincarvalho[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
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: 1Unn81-0004H8-Nf
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Bitcoin addresses -- opaque or not
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: Sat, 15 Jun 2013 09:50:41 -0000
--14dae93d909241f14a04df2e4b70
Content-Type: text/plain; charset=ISO-8859-1
On 11 June 2013 17:29, Luke-Jr <luke@dashjr.org> wrote:
> On Tuesday, June 11, 2013 1:11:33 PM Melvin Carvalho wrote:
> > For the sake of argument let's say that opaque means that you can tell
> > nothing about the address by examining the characters.
>
> This is true or false based on CONTEXT.
>
> Obviously, an implementation of transaction handling (eg, wallets) needs
> to be
> able to translate addresses to and from what they represent.
>
> On the other hand, things like URI handlers do not (and should not) try to
> interpret the address as anything other than an arbitrary word (\w+).
>
I think this statement may need to be justified.
>
> > My understanding was that they are NOT opaque, and that if that has
> > changed, it will invalidate much at least some wiki page, for examples at
> > least some of the following would now be false:
>
> The wiki goes into much detail on how addresses work, which is not the
> concern
> of most software in the Bitcoin ecosystem, but may be of interest to humans
> and developers working on the one component that operates the "black box"
> that
> addresses are.
>
> > --------
> > <snip>
> > --------
>
> These aren't FALSE, they are "true at the moment, but subject to revision
> by
> newer standards".
>
Got it.
>
> > I also here that there is a LIKELY change from the base58 encoding ...
> when
> > was this established?
>
> I stated (on IRC) that it was likely Bitcoin would change from the base58
> encoding for addresses ... at some unspecified time in the future, to some
> unspecified new encoding that addressed known limitations of base58. What
> those changes will be, or when, are not all established at this time. The
> only
> currently-planned change to addresses (very loosely defined) is inclusion
> of
> the Payment Protocol URIs. But the point is that software developers
> shouldn't
> assume that addresses will remain base58 forever.
>
Does this mean that people should not be investing in "vanity addresses"?
>
> Luke
>
--14dae93d909241f14a04df2e4b70
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 11 June 2013 17:29, Luke-Jr <span dir=3D"ltr"><<a href=3D"mai=
lto:luke@dashjr.org" target=3D"_blank">luke@dashjr.org</a>></span> wrote=
:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">
<div class=3D"im">On Tuesday, June 11, 2013 1:11:33 PM Melvin Carvalho wrot=
e:<br>
> For the sake of argument let's say that opaque means that you can =
tell<br>
> nothing about the address by examining the characters.<br>
<br>
</div>This is true or false based on CONTEXT.<br>
<br>
Obviously, an implementation of transaction handling (eg, wallets) needs to=
be<br>
able to translate addresses to and from what they represent.<br>
<br>
On the other hand, things like URI handlers do not (and should not) try to<=
br>
interpret the address as anything other than an arbitrary word (\w+).<br></=
blockquote><div><br></div><div>I think this statement may need to be justif=
ied.<br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im"><br>
> My understanding was that they are NOT opaque, and that if that has<br=
>
> changed, it will invalidate much at least some wiki page, for examples=
at<br>
> least some of the following would now be false:<br>
<br>
</div>The wiki goes into much detail on how addresses work, which is not th=
e concern<br>
of most software in the Bitcoin ecosystem, but may be of interest to humans=
<br>
and developers working on the one component that operates the "black b=
ox" that<br>
addresses are.<br>
<br>
> --------<br>
> <snip><br>
> --------<br>
<br>
These aren't FALSE, they are "true at the moment, but subject to r=
evision by<br>
newer standards".<br></blockquote><div><br></div><div>Got it.<br></div=
><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im"><br>
> I also here that there is a LIKELY change from the base58 encoding ...=
when<br>
> was this established?<br>
<br>
</div>I stated (on IRC) that it was likely Bitcoin would change from the ba=
se58<br>
encoding for addresses ... at some unspecified time in the future, to some<=
br>
unspecified new encoding that addressed known limitations of base58. What<b=
r>
those changes will be, or when, are not all established at this time. The o=
nly<br>
currently-planned change to addresses (very loosely defined) is inclusion o=
f<br>
the Payment Protocol URIs. But the point is that software developers should=
n't<br>
assume that addresses will remain base58 forever.<br></blockquote><div><br>=
</div><div>Does this mean that people should not be investing in "vani=
ty addresses"?<br></div><div>=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Luke<br>
</font></span></blockquote></div><br></div></div>
--14dae93d909241f14a04df2e4b70--
|
