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; 
MIME-Version: 1.0
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
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Bitcoin addresses -- opaque or not
Precedence: list

--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">&lt;<a href=3D"mai=
lto:luke@dashjr.org" target=3D"_blank">luke@dashjr.org</a>&gt;</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>
&gt; For the sake of argument let&#39;s say that opaque means that you can =
tell<br>
&gt; 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>
&gt; My understanding was that they are NOT opaque, and that if that has<br=
>
&gt; changed, it will invalidate much at least some wiki page, for examples=
 at<br>
&gt; 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 &quot;black b=
ox&quot; that<br>
addresses are.<br>
<br>
&gt; --------<br>
&gt; &lt;snip&gt;<br>
&gt; --------<br>
<br>
These aren&#39;t FALSE, they are &quot;true at the moment, but subject to r=
evision by<br>
newer standards&quot;.<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>
&gt; I also here that there is a LIKELY change from the base58 encoding ...=
 when<br>
&gt; 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&#39;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 &quot;vani=
ty addresses&quot;?<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--