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
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
|
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 <marek@palatinus.cz>) id 1RbLiJ-0006Rc-6m
for bitcoin-development@lists.sourceforge.net;
Fri, 16 Dec 2011 00:31:51 +0000
X-ACL-Warn:
Received: from mail-ey0-f175.google.com ([209.85.215.175])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1RbLiF-00040e-9s
for bitcoin-development@lists.sourceforge.net;
Fri, 16 Dec 2011 00:31:51 +0000
Received: by eaal1 with SMTP id l1so3600257eaa.34
for <bitcoin-development@lists.sourceforge.net>;
Thu, 15 Dec 2011 16:31:41 -0800 (PST)
Received: by 10.204.151.75 with SMTP id b11mr2484725bkw.26.1323994110210; Thu,
15 Dec 2011 16:08:30 -0800 (PST)
MIME-Version: 1.0
Sender: marek@palatinus.cz
Received: by 10.204.168.15 with HTTP; Thu, 15 Dec 2011 16:07:58 -0800 (PST)
In-Reply-To: <201112131622.08158.andyparkins@gmail.com>
References: <1323731781.42953.YahooMailClassic@web120920.mail.ne1.yahoo.com>
<CABsx9T1wksXjLy=EC6dK1WtVFEayL-HgXWtENgSPXhU6Du2Srg@mail.gmail.com>
<1323791208.31194.YahooMailNeo@web121013.mail.ne1.yahoo.com>
<201112131622.08158.andyparkins@gmail.com>
From: slush <slush@centrum.cz>
Date: Fri, 16 Dec 2011 01:07:58 +0100
X-Google-Sender-Auth: ELpUqddG4cW0ype8RoPsCxnyLkg
Message-ID: <CAJna-HiR0qrOp2sG0hb=5bJ2H60y7QwC8BiHDVR9=kiV20W0vA@mail.gmail.com>
To: Andy Parkins <andyparkins@gmail.com>
Content-Type: multipart/alternative; boundary=0015175dd9d09fb33f04b42a6651
X-Spam-Score: 3.5 (+++)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(slush[at]centrum.cz)
0.0 HS_INDEX_PARAM URI: Link contains a common tracker pattern.
1.0 HTML_MESSAGE BODY: HTML included in message
2.5 FREEMAIL_REPLY From and body contain different freemails
X-Headers-End: 1RbLiF-00040e-9s
Cc: bitcoin-development@lists.sourceforge.net
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: Fri, 16 Dec 2011 00:31:51 -0000
--0015175dd9d09fb33f04b42a6651
Content-Type: text/plain; charset=ISO-8859-1
I really like this proposal with standard URLs. All other proposals like
DNS mapping or email aliases converted to URLs with some weird logic looks
strange to me.
Plain URLs (returning address in response body, redirecting to URI
"bitcoin:<address>" or anything else) are very clear solution, easy to
implement in clients and very easy to understand by people. It's also
extremely flexible - almost everybody can somewhere setup static file
containing his "personal" addresses or it's very easy to integrate such
solution with eshops (providing custom address for given order) etc. I'm
definitely for this solution.
Best,
slush
On Tue, Dec 13, 2011 at 5:22 PM, Andy Parkins <andyparkins@gmail.com> wrote:
> 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
> making
> choices on behalf of server operators. It's up to them how they arrange
> their
> domain names and paths.
>
> I also agree that DNS is not the technology to use. DNS is a nightmare.
>
> > genjix@foo.org
> >
> > Contacts https://foo.org/bitcoin-alias/?handle=genjix 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.
> >
> > I'll clarify it later. This is the relevant line:
> >
> > string strRequestUrl = strDomain + "/bitcoin-alias/?handle=" +
> > pszEncodedNick;
> >
> > 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=genjix
>
> Then forget the hardcoding of "https" the hardcoding of "bitcoin-alias" and
> "?handle=" and the original email-looking "genjix@foo.org". Just use the
> URL.
> 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/"
>
> ... or any other URL they want -- any of which suit might suit me and my
> webserver better than whatever mapping would otherwise be hard-coded. The
> world is already very familiar with URLs so this is no more scary than the
> email address. What's more, the email address form looks _too much_ like
> an
> email address, and will only lead to confusion ... "send it to
> genjix@foo.org"
> "so I use outlook express for that, right?" "erm, no, you put it in your
> bitcoin client".
>
> The URL form could easily be made to detect a browser connecting rather
> than a
> bitcoin client (and this is an area that would benefit from a standards
> document -- define the headers and user agent triggers that an alias server
> expects) and give them better instructions.
>
> https can be specified as the default, so "https://" can be optional when
> they're typing. If, in the future, bitcoin gets a distributed peer-to-peer
> alias system, then a new URL type can be added easily
> "bcalias://andyparkins"
> might automatically find my node in the network and query it for an address
> (or whatever).
>
> All of the above is exactly why OpenID chose to use URLs for ID.
>
>
>
> Andy
>
> --
> Dr Andy Parkins
> andyparkins@gmail.com
>
>
> ------------------------------------------------------------------------------
> Systems Optimization Self Assessment
> Improve efficiency and utilization of IT resources. Drive out cost and
> improve service delivery. Take 5 minutes to use this Systems Optimization
> Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--0015175dd9d09fb33f04b42a6651
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
I really like this proposal with standard URLs. All other proposals like DN=
S mapping or email aliases converted to URLs with some weird logic looks st=
range to me.<div><br></div><div>Plain URLs (returning address in response b=
ody, redirecting to URI "bitcoin:<address>" or anything els=
e) are very clear solution, easy to implement in clients and very easy to u=
nderstand by people. It's also extremely flexible - almost everybody ca=
n somewhere setup static file containing his "personal" addresses=
or it's very easy to integrate such solution with eshops (providing cu=
stom address for given order) etc. I'm definitely for this solution.<di=
v>
<br></div><div>Best,</div><div>slush</div><div><br><div class=3D"gmail_quot=
e">On Tue, Dec 13, 2011 at 5:22 PM, Andy Parkins <span dir=3D"ltr"><<a h=
ref=3D"mailto:andyparkins@gmail.com">andyparkins@gmail.com</a>></span> w=
rote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On 2011 December 13 Tuesda=
y, Amir Taaki wrote:<br>
<br>
> Maybe I wasn't clear enough in the document, but this is the inten=
t with<br>
> the HTTPS proposal.<br>
<br>
</div>I don't like the idea of a hard-coded mapping at all. =A0We shoul=
dn't be making<br>
choices on behalf of server operators. =A0It's up to them how they arra=
nge their<br>
domain names and paths.<br>
<br>
I also agree that DNS is not the technology to use. =A0DNS is a nightmare.<=
br>
<div class=3D"im"><br>
> <a href=3D"mailto:genjix@foo.org">genjix@foo.org</a><br>
><br>
> Contacts <a href=3D"https://foo.org/bitcoin-alias/?handle=3Dgenjix" ta=
rget=3D"_blank">https://foo.org/bitcoin-alias/?handle=3Dgenjix</a> and the =
system<br>
> responds with a bitcoin address. Whether the system gives you a new<br=
>
> address from a pool of addresses, or contacts the merchant behind the<=
br>
> scenes is implementation defined.<br>
><br>
> I'll clarify it later. This is the relevant line:<br>
><br>
> string strRequestUrl =3D strDomain + "/bitcoin-alias/?handle=3D&q=
uot; +<br>
> pszEncodedNick;<br>
><br>
> Between HTTPS service and server service, I lean slightly towards HTTP=
S<br>
> (automatic encrypted connection, CAs + all benefits of DNS). But still=
<br>
> interested in arguments in favour of a server service (daemon answerin=
g<br>
> queries).<br>
<br>
</div>Why bother with an encoding scheme at all? =A0If the address<br>
<br>
=A0<a href=3D"mailto:genjix@foo.org">genjix@foo.org</a><br>
<br>
always maps to<br>
<br>
=A0<a href=3D"https://foo.org/bitcoin-alias/?handle=3Dgenjix" target=3D"_b=
lank">https://foo.org/bitcoin-alias/?handle=3Dgenjix</a><br>
<br>
Then forget the hardcoding of "https" the hardcoding of "bit=
coin-alias" and<br>
"?handle=3D" and the original email-looking "<a href=3D"mail=
to:genjix@foo.org">genjix@foo.org</a>". =A0Just use the URL.<br>
Then the author of the service can use whatever they want.<br>
<br>
=A0"Can I pay you 10 BTC?"<br>
=A0"Sure, send it to '<a href=3D"https://bitcoinalias.foo.org/genj=
ix/" target=3D"_blank">https://bitcoinalias.foo.org/genjix/</a>'"<=
br>
<br>
While I might implement my alias server like this:<br>
<br>
=A0"Sure, send it to '<a href=3D"https://google.com/bitcoin/?andyp=
arkins" target=3D"_blank">https://google.com/bitcoin/?andyparkins</a>'&=
quot;<br>
=A0"Sure, send it to '<a href=3D"https://parkins.co.uk/" target=3D=
"_blank">https://parkins.co.uk/</a>"<br>
<br>
... or any other URL they want -- any of which suit might suit me and my<br=
>
webserver better than whatever mapping would otherwise be hard-coded. =A0Th=
e<br>
world is already very familiar with URLs so this is no more scary than the<=
br>
email address. =A0What's more, the email address form looks _too much_ =
like an<br>
email address, and will only lead to confusion ... "send it to <a href=
=3D"mailto:genjix@foo.org">genjix@foo.org</a>"<br>
"so I use outlook express for that, right?" =A0"erm, no, you=
put it in your<br>
bitcoin client".<br>
<br>
The URL form could easily be made to detect a browser connecting rather tha=
n a<br>
bitcoin client (and this is an area that would benefit from a standards<br>
document -- define the headers and user agent triggers that an alias server=
<br>
expects) and give them better instructions.<br>
<br>
https can be specified as the default, so =A0"https://" can be op=
tional when<br>
they're typing. =A0If, in the future, bitcoin gets a distributed peer-t=
o-peer<br>
alias system, then a new URL type can be added easily "bcalias://andyp=
arkins"<br>
might automatically find my node in the network and query it for an address=
<br>
(or whatever).<br>
<br>
All of the above is exactly why OpenID chose to use URLs for ID.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
<br>
Andy<br>
<br>
--<br>
Dr Andy Parkins<br>
<a href=3D"mailto:andyparkins@gmail.com">andyparkins@gmail.com</a><br>
</font></span><br>---------------------------------------------------------=
---------------------<br>
Systems Optimization Self Assessment<br>
Improve efficiency and utilization of IT resources. Drive out cost and<br>
improve service delivery. Take 5 minutes to use this Systems Optimization<b=
r>
Self Assessment. <a href=3D"http://www.accelacomm.com/jaw/sdnl/114/51450054=
/" target=3D"_blank">http://www.accelacomm.com/jaw/sdnl/114/51450054/</a><b=
r>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div></div>
--0015175dd9d09fb33f04b42a6651--
|
