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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <decker.christian@gmail.com>) id 1RaQlQ-0008W7-W2
for bitcoin-development@lists.sourceforge.net;
Tue, 13 Dec 2011 11:43:16 +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=decker.christian@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 1RaQlM-0007V9-OT
for bitcoin-development@lists.sourceforge.net;
Tue, 13 Dec 2011 11:43:16 +0000
Received: by wgbds1 with SMTP id ds1so12536269wgb.10
for <bitcoin-development@lists.sourceforge.net>;
Tue, 13 Dec 2011 03:43:06 -0800 (PST)
Received: by 10.216.49.1 with SMTP id w1mr72322web.29.1323776586555; Tue, 13
Dec 2011 03:43:06 -0800 (PST)
MIME-Version: 1.0
Received: by 10.227.152.10 with HTTP; Tue, 13 Dec 2011 03:42:17 -0800 (PST)
In-Reply-To: <CANEZrP1oPaqAT+LCfrAXO9WBz+oC2uvbP=5vx2+DX2P0qFusgA@mail.gmail.com>
References: <1323731781.42953.YahooMailClassic@web120920.mail.ne1.yahoo.com>
<CAGQP0AGvq603oshSGiP79A+gqDqW_hHG+qZjaZccCmo+gd3W2A@mail.gmail.com>
<201112121841.39864.luke@dashjr.org>
<CAGQP0AGBKKEqhaJZj-Rw400AjrVHE9_EMve=RWdqoaOaDsTgtw@mail.gmail.com>
<CAGQP0AGY32QP=rXyGftb5NbHA7fhcCne7W=pt5+onXp1Jbm98Q@mail.gmail.com>
<1323736946.58149.YahooMailNeo@web121001.mail.ne1.yahoo.com>
<CANEZrP1oPaqAT+LCfrAXO9WBz+oC2uvbP=5vx2+DX2P0qFusgA@mail.gmail.com>
From: Christian Decker <decker.christian@gmail.com>
Date: Tue, 13 Dec 2011 12:42:17 +0100
Message-ID: <CALxbBHUgCOVMRxtnsmC2W-MaYfeDSzaftWMCCgcWsMBdZfzPQg@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=001485f27b943422b804b3f7c18a
X-Spam-Score: -0.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
(decker.christian[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-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: 1RaQlM-0007V9-OT
Cc: "bitcoin-development@lists.sourceforge.net"
<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: Tue, 13 Dec 2011 11:43:17 -0000
--001485f27b943422b804b3f7c18a
Content-Type: text/plain; charset=ISO-8859-1
I think the scope of this BIP is not so well defined right now. We need a
way for merchants to translate a human readable, and more importantly
human-writeable, address into a bitcoin address. I agree with Mike that a
fixed address is not the way to go, because addresses should be used once
for a single transaction to be able to track payments.
While firstbits sounds attractive at first, I think we can all agree that
it just isn't feasible and would not allow per-transaction addresses. DNS
sounds interesting for fixed addresses, but caching and propagation make it
difficult to use for per-transaction addresses that are to be generated
ad-hoc.
HTTP(S) is the best option I think, merchants are probably using HTTP
anyway for their shops. So something like
http://merchant.com/btc/transaction/1234 sounds reasonable. But I think it
should not be over-engineered, it should be a simple HTTP(S) request to a
merchant specified URL that returns an ASCII document containing either a
bitcoin: URI or simply the bitcoin address or even a 301 redirect. It's no
use to start defining URL schemes, it should be left to the merchants to
define how to structure them.
This would allow a merchant to decide if he prefers per-transaction
addresses, per-user transactions, fixed addresses or any combination.
Regards,
cdecker
On Tue, Dec 13, 2011 at 11:55 AM, Mike Hearn <mike@plan99.net> wrote:
> I was in brmlab and wanted to pay 1 BTC for a Club Mate. They had on the
>> wall a picture of their QR code and a bitcoin address. I don't own a mobile
>> phone so the QR code is
>> useless.
>
>
> Fixed addresses like that are a temporary thing during Bitcoins maturation
> period. They lead to merchants exposing data they probably don't realize
> they're exposing, like their income, which is basically unacceptable for
> any payment system.
>
> There's no point trying to optimize a case where:
>
> 1) You are in the minority (no phone?)
> 2) The "perfect experience" leaks private data in such a way that would be
> deemed a gross security breach by any serious payment processor.
>
> OK, some thoughts on the general proposal, from the POV of what it'd take
> for a large deployment, like for every Gmail or every Facebook user. In
> terms of ease of implementation it is ordered HTTPS/HTTP then DNS trailing
> by a large margin. Big sites, even small sites, typically have high-speed
> load balancing and demuxing already implemented for HTTP[S] and it's
> usually easy to add new endpoints. The same is *not* true of DNS, and
> whilst coding up a custom DNS server is possible it's definitely a worse
> fit.
>
> FirstBits seems out of the question for the same privacy reasons as given
> above. No banking system worth its salt would let everyone look up other
> peoples income.
>
> The simplest approach would be to request a full public key with an HTTPS
> request like
>
> foo@domain ->
> https://domain/_bitcoin/getnewkey?user=foo&label=Payment%20from%20Bob
>
> If you then want to turn the resulting public key into an address before
> creating a transaction you can obviously do that.
>
> BTW the BIP is pretty hard to read. Your spec for the HTTPS proposal is a
> big pile of source code. I think it's the same as above, but it's hard to
> tell without more effort.
>
>
> ------------------------------------------------------------------------------
> 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
>
>
--001485f27b943422b804b3f7c18a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
I think the scope of this BIP is not so well defined right now. We need a w=
ay for merchants to translate a human readable, and more importantly human-=
writeable, address into a bitcoin address. I agree with Mike that a fixed a=
ddress is not the way to go, because addresses should be used once for a si=
ngle transaction to be able to track payments. <br>
<br>While firstbits sounds attractive at first, I think we can all agree th=
at it just isn't feasible and would not allow per-transaction addresses=
. DNS sounds interesting for fixed addresses, but caching and propagation m=
ake it difficult to use for per-transaction addresses that are to be genera=
ted ad-hoc.<br>
<br>HTTP(S) is the best option I think, merchants are probably using HTTP a=
nyway for their shops. So something like <a href=3D"http://merchant.com/btc=
/transaction/1234">http://merchant.com/btc/transaction/1234</a> sounds reas=
onable. But I think it should not be over-engineered, it should be a simple=
HTTP(S) request to a merchant specified URL that returns an ASCII document=
containing either a bitcoin: URI or simply the bitcoin address or even a 3=
01 redirect. It's no use to start defining URL schemes, it should be le=
ft to the merchants to define how to structure them.<br>
<br>This would allow a merchant to decide if he prefers per-transaction add=
resses, per-user transactions, fixed addresses or any combination.<br><br>R=
egards,<br>cdecker<br><br><br><div class=3D"gmail_quote">On Tue, Dec 13, 20=
11 at 11:55 AM, Mike Hearn <span dir=3D"ltr"><<a href=3D"mailto:mike@pla=
n99.net">mike@plan99.net</a>></span> wrote:<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"gmail_quote"><div class=3D"im"=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">
I was in brmlab and wanted to pay 1 BTC for a Club Mate. They had on the wa=
ll a picture of their QR code and a bitcoin address. I don't own a mobi=
le phone so the QR code is<br>
useless.</blockquote><div><br></div></div><div>Fixed addresses like that ar=
e a temporary thing during Bitcoins maturation period. They lead to merchan=
ts exposing data they probably don't realize they're exposing, like=
their income, which is basically unacceptable for any payment system.</div=
>
<div><br></div><div>There's no point trying to optimize a case where:</=
div><div><br></div><div>1) You are in the minority (no phone?)</div><div>2)=
The "perfect experience" leaks private data in such a way that w=
ould be deemed a gross security breach by any serious payment processor.</d=
iv>
<div><br></div><div>OK, some thoughts on the general proposal, from the POV=
of what it'd take for a large deployment, like for every Gmail or ever=
y Facebook user. In terms of ease of implementation it is ordered HTTPS/HTT=
P then DNS trailing by a large margin. Big sites, even small sites, typical=
ly have high-speed load balancing and demuxing already implemented for HTTP=
[S] and it's usually easy to add new endpoints. The same is <i>not</i> =
true of DNS, and whilst coding up a custom DNS server is possible it's =
definitely a worse fit.</div>
<div><br></div><div>FirstBits seems out of the question for the same privac=
y reasons as given above. No banking system worth its salt would let everyo=
ne look up other peoples income.</div><div><br></div><div>The simplest appr=
oach would be to request a full public key with an HTTPS request like</div>
<div><br></div><div>=A0 =A0foo@domain -> <a href=3D"https://domain/_bitc=
oin/getnewkey?user=3Dfoo&label=3DPayment%20from%20Bob" target=3D"_blank=
">https://domain/_bitcoin/getnewkey?user=3Dfoo&label=3DPayment%20from%2=
0Bob</a></div>
<div><br></div>
<div>If you then want to turn the resulting public key into an address befo=
re creating a transaction you can obviously do that.</div><div><br></div><d=
iv>BTW the BIP is pretty hard to read. Your spec for the HTTPS proposal is =
a big pile of source code. I think it's the same as above, but it's=
hard to tell without more effort.</div>
</div>
<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>
--001485f27b943422b804b3f7c18a--
|
