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
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <andyparkins@gmail.com>) id 1Rb88J-0007uI-Cv
for bitcoin-development@lists.sourceforge.net;
Thu, 15 Dec 2011 10:01:47 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.53 as permitted sender)
client-ip=74.125.82.53; envelope-from=andyparkins@gmail.com;
helo=mail-ww0-f53.google.com;
Received: from mail-ww0-f53.google.com ([74.125.82.53])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128)
(Exim 4.76) id 1Rb88D-0006Fz-MN
for bitcoin-development@lists.sourceforge.net;
Thu, 15 Dec 2011 10:01:47 +0000
Received: by wgbds1 with SMTP id ds1so3307340wgb.10
for <bitcoin-development@lists.sourceforge.net>;
Thu, 15 Dec 2011 02:01:35 -0800 (PST)
Received: by 10.227.206.200 with SMTP id fv8mr1584662wbb.11.1323943295582;
Thu, 15 Dec 2011 02:01:35 -0800 (PST)
Received: from dvr.localnet (mail.360visiontechnology.com. [92.42.121.178])
by mx.google.com with ESMTPS id di5sm7545904wib.3.2011.12.15.02.01.32
(version=TLSv1/SSLv3 cipher=OTHER);
Thu, 15 Dec 2011 02:01:33 -0800 (PST)
From: Andy Parkins <andyparkins@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Date: Thu, 15 Dec 2011 10:01:14 +0000
User-Agent: KMail/1.13.6 (Linux/3.0.0-1-686-pae; KDE/4.6.3; i686; ; )
References: <CA+QPp0rAJz9wPcrf926q=_c45mCL_67JCyacvM79CWcic9AL2w@mail.gmail.com>
<CAGQP0AFD9q+=vZPod_n_LJjCjzVnVy5w3hq4N07JZRM6=Ly-FQ@mail.gmail.com>
<CACwuEiMu1iMnrv2zubqUugSwxu_jWmNxJtPuhdNoqJPgRHhKhg@mail.gmail.com>
In-Reply-To: <CACwuEiMu1iMnrv2zubqUugSwxu_jWmNxJtPuhdNoqJPgRHhKhg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart24076967.RVlZ8CDTU3";
protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <201112151001.23274.andyparkins@gmail.com>
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
(andyparkins[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
0.0 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1Rb88D-0006Fz-MN
Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
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: Thu, 15 Dec 2011 10:01:47 -0000
--nextPart24076967.RVlZ8CDTU3
Content-Type: Text/Plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
On 2011 December 15 Thursday, Walter Stanish wrote:
> > Andy sounded very convincing when talking in favor of URLs. What's
> > wrong with his proposal?
>=20
> A URI identifies a resource and is in effect an alias itself.
> Identifying a resource is different from interacting with it. So,
> while <resource-type>://<resource-type-specific-alias> will work
> sufficiently for the identification, it does not explain the
> interaction.
Quite so; the BIP15 standard shouldn't be setting the format of the URI; it=
=20
should be setting what the format of the client-server conversation is. =20
Effectively, what headers will a requesting client send? What headers shou=
ld=20
a server require? What will a server respond?
> Interaction is a requirement, since there seems to be a widely felt
> need to preserve anonymity through the use of temporary addresses.
I think that's missing the point; any aliasing scheme is definitely reducin=
g=20
your anonymity, neccessarily so -- the alias has to be looked up somewhere,=
=20
that somewhere reduces anonymity. If anonymity is what you want, stick wit=
h=20
just a bitcoin address. The point of an aliasing server is surely to be ab=
le=20
to give a single, unchanging, well known label to a transacting party, but=
=20
still enable that party to generate a new address per transaction.
I want my webshop to be able to say "please pay 3.20 BTC to=20
https://mywebshop.com/payments/orderid=3D27282" to enable the automatic=20
connection from orderid to bitcoin address (which my payment system can the=
n=20
monitor for payment receipt). (This is just one example).
> Generating a temporary address requires some actual processing to
> achieve, since the issuing of the new address cannot be done without
> interacting with the entity hosting the wallet (unless I'm missing
> something?).
Well yes; but then the client has no idea what address to send to unless it=
=20
connects to that URI... interaction/address generation is done when that=20
connection is made.
In short: I don't really think that this aliasing system should be concerni=
ng=20
itself with preserving anonymity of the receiving party. That is almost=20
certainly already gone (I'm hardly likely to send money to someone I don't=
=20
know unless I like gifting random cash). The sending party loses a little=
=20
anonymity because their IP is revealed when they connect to the aliasing=20
system. But there is very little anonymity in a supplier-client relationsh=
ip=20
anyway (you have to say what goods you want, and where you want them, and y=
ou=20
had to interact with a website when you were ordering already).
Andy
=2D-=20
Dr Andy Parkins
andyparkins@gmail.com
--nextPart24076967.RVlZ8CDTU3
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEABECAAYFAk7pxWsACgkQwQJ9gE9xL22zfwCfSLPpzbxOAHlIrQuwBJEmPw8X
2VEAmwUzL8kgNMScvGnk69dmyce5bg7F
=jKoN
-----END PGP SIGNATURE-----
--nextPart24076967.RVlZ8CDTU3--
|
