From: Melvin Carvalho <melvincarvalho@gmail•com>
To: Luke-Jr <luke@dashjr•org>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Bitcoin addresses -- opaque or not
Date: Sat, 22 Jun 2013 13:48:08 +0200 [thread overview]
Message-ID: <CAKaEYhK0Lgpw3aNLo6LNQ=SwJ5TjquKYMWyh9K5+C-HFQfK1pw@mail.gmail.com> (raw)
In-Reply-To: <201306111529.13657.luke@dashjr.org>
[-- Attachment #1: Type: text/plain, Size: 2514 bytes --]
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+).
>
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.
>
> > --------
> > <snip>
> > --------
>
> 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
>
[-- Attachment #2: Type: text/html, Size: 3420 bytes --]
prev parent reply other threads:[~2013-06-22 11:48 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-11 13:11 Melvin Carvalho
2013-06-11 13:44 ` Wladimir
2013-06-11 14:12 ` Pieter Wuille
2013-06-11 15:29 ` Luke-Jr
2013-06-15 9:50 ` Melvin Carvalho
2013-06-22 11:48 ` Melvin Carvalho [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAKaEYhK0Lgpw3aNLo6LNQ=SwJ5TjquKYMWyh9K5+C-HFQfK1pw@mail.gmail.com' \
--to=melvincarvalho@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=luke@dashjr$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox