1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pieter.wuille@gmail.com>) id 1UmPJi-0005hR-E6
for bitcoin-development@lists.sourceforge.net;
Tue, 11 Jun 2013 14:12:58 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.223.172 as permitted sender)
client-ip=209.85.223.172; envelope-from=pieter.wuille@gmail.com;
helo=mail-ie0-f172.google.com;
Received: from mail-ie0-f172.google.com ([209.85.223.172])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UmPJh-0003LY-HB
for bitcoin-development@lists.sourceforge.net;
Tue, 11 Jun 2013 14:12:58 +0000
Received: by mail-ie0-f172.google.com with SMTP id 17so19809230iea.17
for <bitcoin-development@lists.sourceforge.net>;
Tue, 11 Jun 2013 07:12:52 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.41.34 with SMTP id c2mr997910igl.57.1370959972228; Tue,
11 Jun 2013 07:12:52 -0700 (PDT)
Received: by 10.50.149.233 with HTTP; Tue, 11 Jun 2013 07:12:52 -0700 (PDT)
In-Reply-To: <CAKaEYhJ+v0NfbzVEDEUh69D-n_4=Nd544fsm0a++QwsqcS3RVw@mail.gmail.com>
References: <CAKaEYhJ+v0NfbzVEDEUh69D-n_4=Nd544fsm0a++QwsqcS3RVw@mail.gmail.com>
Date: Tue, 11 Jun 2013 16:12:52 +0200
Message-ID: <CAPg+sBgpFx5vOWWL9izdC1UMvRCV19Lmerm0bw2xwSzf01DW2g@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Melvin Carvalho <melvincarvalho@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.6 (-)
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
(pieter.wuille[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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
X-Headers-End: 1UmPJh-0003LY-HB
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 11 Jun 2013 14:12:58 -0000
On Tue, Jun 11, 2013 at 3:11 PM, Melvin Carvalho
<melvincarvalho@gmail.com> wrote:
> There was some confusion on IRC as to whether bitcoin addresses are opaque
> or not.
>
> https://en.bitcoin.it/wiki/Address
>
> For the sake of argument let's say that opaque means that you can tell
> nothing about the address by examining the characters.
>
> 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:
I'm afraid this is the result of a misunderstanding.
Yesterday on IRC you were asking why the URI specification doesn't
include the semantics and encoding of addresses. Some people,
including me, argued that addresses should be considered opaque. That
doesn't mean they don't have well-specified definition, only that for
the purposes of URI parsing and handling, code shouldn't know or care
what they represent or how they are formatted. Addresses are specified
in one place, and the URI format simply passes addresses through.
The reason for keeping them independent is that the address format
could change (say, a new type is added, like P2SH (BIP13) before), and
there is no reason why this should break or even concern URI handling
code. Clearly, anything that actually interprets addresses in order to
construct transactions will need changing. It's just two separate
concerns, and they should be dealt with separately.
--
Pieter
|
