Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UqMIj-0001El-4U for bitcoin-development@lists.sourceforge.net; Sat, 22 Jun 2013 11:48:17 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.47 as permitted sender) client-ip=209.85.215.47; envelope-from=melvincarvalho@gmail.com; helo=mail-la0-f47.google.com; Received: from mail-la0-f47.google.com ([209.85.215.47]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UqMIh-0000mp-6d for bitcoin-development@lists.sourceforge.net; Sat, 22 Jun 2013 11:48:17 +0000 Received: by mail-la0-f47.google.com with SMTP id fe20so8302919lab.6 for ; Sat, 22 Jun 2013 04:48:08 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.50.236 with SMTP id f12mr9308422lbo.15.1371901688361; Sat, 22 Jun 2013 04:48:08 -0700 (PDT) Received: by 10.112.19.226 with HTTP; Sat, 22 Jun 2013 04:48:08 -0700 (PDT) In-Reply-To: <201306111529.13657.luke@dashjr.org> References: <201306111529.13657.luke@dashjr.org> Date: Sat, 22 Jun 2013 13:48:08 +0200 Message-ID: From: Melvin Carvalho To: Luke-Jr Content-Type: multipart/alternative; boundary=001a1133b42acd38f204dfbcc08d X-Spam-Score: 0.0 (/) 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 0.6 URIBL_SBL Contains an URL listed in the SBL blocklist [URIs: dashjr.org] X-Headers-End: 1UqMIh-0000mp-6d Cc: Bitcoin Dev 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 11:48:17 -0000 --001a1133b42acd38f204dfbcc08d Content-Type: text/plain; charset=ISO-8859-1 On 11 June 2013 17:29, Luke-Jr 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+). > Luke, if you think that the sole purpose of a URI scheme is to be used as a URI handler, I think you've not fully understood the concept. URIs are the global variable of the internet, and as such the need to play nicely with all other URI schemes on the net. They need to be able to be linked to, to be defined and documented. This is important for bitcoin to get right because bitcoin: needs to treated in a special way on the internet, I just saw today that it was treated by some software as a relative URL, which is going to break a ton of stuff. > > > 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. > > > -------- > > > > -------- > > These aren't FALSE, they are "true at the moment, but subject to revision > by > newer standards". > > > 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. > I am opposed to address changes in general, until he wider implications are fully understood. > > Luke > --001a1133b42acd38f204dfbcc08d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 11 June 2013 17:29, Luke-Jr <luke@dashjr.org> wrote= :
On Tuesday, June 11, 2013 1:11:33 PM Melvin Carvalho wrot= e:
> 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<= br> interpret the address as anything other than an arbitrary word (\w+).

Luke, if you think that the sole purpose of = a URI scheme is to be used as a URI handler, I think you've not fully u= nderstood the concept.=A0 URIs are the global variable of the internet, and= as such the need to play nicely with all other URI schemes on the net.=A0 = They need to be able to be linked to, to be defined and documented.=A0 This= is important for bitcoin to get right because bitcoin: needs to treated in= a special way on the internet, I just saw today that it was treated by som= e software as a relative URL, which is going to break a ton of stuff.
=A0

> 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 th= e 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 b= ox" that
addresses are.

> --------
> <snip>
> --------

These aren't FALSE, they are "true at the moment, but subject to r= evision by
newer standards".

> 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 ba= se58
encoding for addresses ... at some unspecified time in the future, to some<= br> unspecified new encoding that addressed known limitations of base58. What those changes will be, or when, are not all established at this time. The o= nly
currently-planned change to addresses (very loosely defined) is inclusion o= f
the Payment Protocol URIs. But the point is that software developers should= n't
assume that addresses will remain base58 forever.

=
I am opposed to address changes in general, until he wider impli= cations are fully understood.=A0
=A0

Luke

--001a1133b42acd38f204dfbcc08d--