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
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <andyparkins@gmail.com>) id 1RaV7a-0008Fq-T9
for bitcoin-development@lists.sourceforge.net;
Tue, 13 Dec 2011 16:22:26 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.161.47 as permitted sender)
client-ip=209.85.161.47; envelope-from=andyparkins@gmail.com;
helo=mail-fx0-f47.google.com;
Received: from mail-fx0-f47.google.com ([209.85.161.47])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1RaV7V-0005nC-54
for bitcoin-development@lists.sourceforge.net;
Tue, 13 Dec 2011 16:22:26 +0000
Received: by faaa20 with SMTP id a20so474264faa.34
for <bitcoin-development@lists.sourceforge.net>;
Tue, 13 Dec 2011 08:22:15 -0800 (PST)
Received: by 10.180.107.97 with SMTP id hb1mr27699592wib.18.1323793333838;
Tue, 13 Dec 2011 08:22:13 -0800 (PST)
Received: from dvr.localnet (mail.360visiontechnology.com. [92.42.121.178])
by mx.google.com with ESMTPS id dw6sm30451404wib.12.2011.12.13.08.22.10
(version=TLSv1/SSLv3 cipher=OTHER);
Tue, 13 Dec 2011 08:22:11 -0800 (PST)
From: Andy Parkins <andyparkins@gmail.com>
To: bitcoin-development@lists.sourceforge.net, Amir Taaki <zgenjix@yahoo.com>
Date: Tue, 13 Dec 2011 16:22:00 +0000
User-Agent: KMail/1.13.6 (Linux/3.0.0-1-686-pae; KDE/4.6.3; i686; ; )
References: <1323731781.42953.YahooMailClassic@web120920.mail.ne1.yahoo.com>
<CABsx9T1wksXjLy=EC6dK1WtVFEayL-HgXWtENgSPXhU6Du2Srg@mail.gmail.com>
<1323791208.31194.YahooMailNeo@web121013.mail.ne1.yahoo.com>
In-Reply-To: <1323791208.31194.YahooMailNeo@web121013.mail.ne1.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2373416.GlT41jfGsN";
protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <201112131622.08158.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.0 HS_INDEX_PARAM URI: Link contains a common tracker pattern.
-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: 1RaV7V-0005nC-54
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: Tue, 13 Dec 2011 16:22:27 -0000
--nextPart2373416.GlT41jfGsN
Content-Type: Text/Plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
On 2011 December 13 Tuesday, Amir Taaki wrote:
> Maybe I wasn't clear enough in the document, but this is the intent with
> the HTTPS proposal.
I don't like the idea of a hard-coded mapping at all. We shouldn't be maki=
ng=20
choices on behalf of server operators. It's up to them how they arrange th=
eir=20
domain names and paths.
I also agree that DNS is not the technology to use. DNS is a nightmare.
> genjix@foo.org
>=20
> Contacts https://foo.org/bitcoin-alias/?handle=3Dgenjix and the system
> responds with a bitcoin address. Whether the system gives you a new
> address from a pool of addresses, or contacts the merchant behind the
> scenes is implementation defined.
>=20
> I'll clarify it later. This is the relevant line:
>=20
> string strRequestUrl =3D strDomain + "/bitcoin-alias/?handle=3D" +
> pszEncodedNick;
>=20
> Between HTTPS service and server service, I lean slightly towards HTTPS
> (automatic encrypted connection, CAs + all benefits of DNS). But still
> interested in arguments in favour of a server service (daemon answering
> queries).
Why bother with an encoding scheme at all? If the address
genjix@foo.org
always maps to
https://foo.org/bitcoin-alias/?handle=3Dgenjix
Then forget the hardcoding of "https" the hardcoding of "bitcoin-alias" and=
=20
"?handle=3D" and the original email-looking "genjix@foo.org". Just use the=
URL. =20
Then the author of the service can use whatever they want.
"Can I pay you 10 BTC?"
"Sure, send it to 'https://bitcoinalias.foo.org/genjix/'"
While I might implement my alias server like this:
"Sure, send it to 'https://google.com/bitcoin/?andyparkins'"
"Sure, send it to 'https://parkins.co.uk/"
=2E.. or any other URL they want -- any of which suit might suit me and my=
=20
webserver better than whatever mapping would otherwise be hard-coded. The=
=20
world is already very familiar with URLs so this is no more scary than the=
=20
email address. What's more, the email address form looks _too much_ like a=
n=20
email address, and will only lead to confusion ... "send it to genjix@foo.o=
rg" =20
"so I use outlook express for that, right?" "erm, no, you put it in your=20
bitcoin client".
The URL form could easily be made to detect a browser connecting rather tha=
n a=20
bitcoin client (and this is an area that would benefit from a standards=20
document -- define the headers and user agent triggers that an alias server=
=20
expects) and give them better instructions.
https can be specified as the default, so "https://" can be optional when=
=20
they're typing. If, in the future, bitcoin gets a distributed peer-to-peer=
=20
alias system, then a new URL type can be added easily "bcalias://andyparkin=
s"=20
might automatically find my node in the network and query it for an address=
=20
(or whatever).
All of the above is exactly why OpenID chose to use URLs for ID.
Andy
=2D-=20
Dr Andy Parkins
andyparkins@gmail.com
--nextPart2373416.GlT41jfGsN
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)
iEYEABECAAYFAk7ne6kACgkQwQJ9gE9xL22tDACfaix7dRiXPos9D0AlMjWFudpc
p0UAnRa7zpQHWCuwQnX8vH4uwQnNHq9l
=Lz35
-----END PGP SIGNATURE-----
--nextPart2373416.GlT41jfGsN--
|
