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, 15 Jun 2013 11:50:30 +0200 [thread overview]
Message-ID: <CAKaEYhKjvtPf_Xs=Q8tAJt_7PuxCAnym2-kJadNoSdWCHjXNDA@mail.gmail.com> (raw)
In-Reply-To: <201306111529.13657.luke@dashjr.org>
[-- Attachment #1: Type: text/plain, Size: 2002 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+).
>
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
>
[-- Attachment #2: Type: text/html, Size: 3074 bytes --]
next prev parent reply other threads:[~2013-06-15 9:50 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 [this message]
2013-06-22 11:48 ` Melvin Carvalho
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='CAKaEYhKjvtPf_Xs=Q8tAJt_7PuxCAnym2-kJadNoSdWCHjXNDA@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