From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UmQVo-0006lZ-B7 for bitcoin-development@lists.sourceforge.net; Tue, 11 Jun 2013 15:29:32 +0000 X-ACL-Warn: Received: from zinan.dashjr.org ([173.242.112.54]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1UmQVl-0008Ml-JK for bitcoin-development@lists.sourceforge.net; Tue, 11 Jun 2013 15:29:32 +0000 Received: from ishibashi.localnet (unknown [IPv6:2001:470:5:265:222:4dff:fe50:4c49]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id 061EE27A2965; Tue, 11 Jun 2013 15:29:20 +0000 (UTC) From: "Luke-Jr" To: bitcoin-development@lists.sourceforge.net Date: Tue, 11 Jun 2013 15:29:11 +0000 User-Agent: KMail/1.13.7 (Linux/3.7.8-gentoo; KDE/4.10.2; x86_64; ; ) References: In-Reply-To: X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201306111529.13657.luke@dashjr.org> X-Spam-Score: -0.2 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1UmQVl-0008Ml-JK 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: Tue, 11 Jun 2013 15:29:32 -0000 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+). > 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. Luke