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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1V4SG1-0007qT-5y
for bitcoin-development@lists.sourceforge.net;
Wed, 31 Jul 2013 08:59:45 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.45 as permitted sender)
client-ip=209.85.219.45; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f45.google.com;
Received: from mail-oa0-f45.google.com ([209.85.219.45])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1V4SFz-0000q3-CH
for bitcoin-development@lists.sourceforge.net;
Wed, 31 Jul 2013 08:59:45 +0000
Received: by mail-oa0-f45.google.com with SMTP id m1so953501oag.32
for <bitcoin-development@lists.sourceforge.net>;
Wed, 31 Jul 2013 01:59:37 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.43.226 with SMTP id z2mr67034590oel.76.1375261177807;
Wed, 31 Jul 2013 01:59:37 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.23.36 with HTTP; Wed, 31 Jul 2013 01:59:37 -0700 (PDT)
In-Reply-To: <CABsx9T0Ly67ZNJhoRQk0L9Q0-ucq3e=24b5Tg6GRKspRKKtP-g@mail.gmail.com>
References: <CABsx9T0Ly67ZNJhoRQk0L9Q0-ucq3e=24b5Tg6GRKspRKKtP-g@mail.gmail.com>
Date: Wed, 31 Jul 2013 10:59:37 +0200
X-Google-Sender-Auth: 4FWgoEqyCP2HG9jzepAOlJA3_0A
Message-ID: <CANEZrP3pp6N+B4HgRF_xpp-sm7gkkK-NoV6nKKnOzes_2ubT4g@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=001a11333dcefa0cb004e2caf1dd
X-Spam-Score: -0.5 (/)
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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1V4SFz-0000q3-CH
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
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: Wed, 31 Jul 2013 08:59:45 -0000
--001a11333dcefa0cb004e2caf1dd
Content-Type: text/plain; charset=UTF-8
Woo, huzzah :-)
Now the BIP draft is available and we know it all hangs together, I'm
hoping to (re)start implementation work in bitcoinj in the next month or
two. I'm currently trying to figure out which is more important,
deterministic wallets or payment protocol, but I think right now the
payment protocol would be easier to do and would benefit more from a second
implementation. HD wallets have already been shown interoperable.
Comments on BIP 70:
"PaymentRequest messages larger than 50,000 bytes should be rejected by
the merchant's server, to mitigate denial-of-service attacks."
Do you mean "users wallet" here?
You could note in the motivation section two more motivations:
1) That the protocol can be a foundation on which other features are built
2) That it is required to assist hardware wallets when there is a virus on
the system
Perhaps note in the BIP that the merchant should not assume the
merchant_data field is trustworthy - malicious buyers could rewrite it as
they see fit. Point out that a good way to use this is to serialize server
state, signed by a merchant-only key, in the same way one might use an HTTP
cookie.
"PaymentDetails.payment_url must be secure against man-in-the-middle
attacks that might alter Payment.refund_to (if using HTTP, it must be
TLS-protected).
This says "must", but what should a client do here if the payment URL is
not HTTPS? I suggest weakening this to "should", as sometimes TLS is
redundant (e.g. if you're sending to a Tor hidden service).
The PaymentACK message contains a copy of Payment, but the BIP doesn't say
what to do with it. I assume this means a client is free to ignore it and
rely on TCP state to figure out the payment/ack connection instead? It may
be worth noting that explicitly.
In the certificates section, you could observe that "validation" means
"verification that it correctly chains to a trusted root authority, where
trusted roots may be obtained from the operating system. If there is no
operating system, the Mozilla root store is recommended".
All the rest LGTM.
[edit<https://en.bitcoin.it/w/index.php?title=BIP_0070&action=edit§ion=7>
]
On Wed, Jul 31, 2013 at 8:28 AM, Gavin Andresen <gavinandresen@gmail.com>wrote:
> I've turned the preliminary payment protocol spec into three BIPs:
>
> https://en.bitcoin.it/wiki/BIP_0070 : Network protocol / messages
> https://en.bitcoin.it/wiki/BIP_0071 : MIME types for the messages
> https://en.bitcoin.it/wiki/BIP_0072 : bitcoin: URI extension
>
> I expect the wallet-side implementation to be pulled into Bitcoin-Qt Real
> Soon:
> https://github.com/bitcoin/bitcoin/pull/2539
>
> There is also a reference implementation of server-side code for
> generating payment requests in php and C++ :
> https://github.com/gavinandresen/paymentrequest
>
> --
> --
> Gavin Andresen
>
>
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--001a11333dcefa0cb004e2caf1dd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Woo, huzzah :-)<div><br></div><div>Now the BIP draft is av=
ailable and we know it all hangs together, I'm hoping to (re)start impl=
ementation work in bitcoinj in the next month or two. I'm currently try=
ing to figure out which is more important, deterministic wallets or payment=
protocol, but I think right now the payment protocol would be easier to do=
and would benefit more from a second implementation. HD wallets have alrea=
dy been shown interoperable.</div>
<div><br></div><div>Comments on BIP 70:</div><div><br></div><div>=C2=A0 =C2=
=A0"<span style=3D"line-height:1.5em">PaymentRequest messages larger t=
han 50,000 bytes should be rejected by the merchant's server, to mitiga=
te denial-of-service attacks."</span></div>
<div><span style=3D"line-height:1.5em"><br></span></div><div><span style=3D=
"line-height:1.5em">Do you mean "users wallet" here?</span></div>=
<div><span style=3D"line-height:1.5em"><br></span></div><div><span style=3D=
"line-height:1.5em">You could note in the motivation section two more motiv=
ations:</span></div>
<div><span style=3D"line-height:1.5em"><br></span></div><div><span style=3D=
"line-height:1.5em">1) That the protocol can be a foundation on which other=
features are built</span></div><div><span style=3D"line-height:1.5em">2) T=
hat it is required to assist hardware wallets when there is a virus on the =
system</span></div>
<div><span style=3D"line-height:1.5em"><br></span></div><div><span style=3D=
"line-height:1.5em">Perhaps note in the BIP that the merchant should not as=
sume the merchant_data field is trustworthy - malicious buyers could rewrit=
e it as they see fit. Point out that a good way to use this is to serialize=
server state, signed by a merchant-only key, in the same way one might use=
an HTTP cookie.</span></div>
<div><span style=3D"line-height:1.5em"><br></span></div><div><span style=3D=
"line-height:1.5em">=C2=A0 =C2=A0"</span><span style=3D"color:rgb(0,0,=
0);font-family:sans-serif;font-size:12.800000190734863px;line-height:19.200=
000762939453px">PaymentDetails.payment_url must be secure against man-in-th=
e-middle attacks that might alter Payment.refund_to (if using HTTP, it must=
be TLS-protected).</span></div>
<div><br></div><div><font color=3D"#000000" face=3D"sans-serif"><span style=
=3D"line-height:19.1875px">This says "must", but what should a cl=
ient do here if the payment URL is not HTTPS? I suggest weakening this to &=
quot;should", as sometimes TLS is redundant (e.g. if you're sendin=
g to a Tor hidden service).</span></font></div>
<div><font color=3D"#000000" face=3D"sans-serif"><span style=3D"line-height=
:19.1875px"><br></span></font></div><div><font color=3D"#000000" face=3D"sa=
ns-serif"><span style=3D"line-height:19.1875px">The PaymentACK message cont=
ains a copy of Payment, but the BIP doesn't say what to do with it. I a=
ssume this means a client is free to ignore it and rely on TCP state to fig=
ure out the payment/ack connection instead? It may be worth noting that exp=
licitly.</span></font></div>
<div><font color=3D"#000000" face=3D"sans-serif"><span style=3D"line-height=
:19.1875px"><br></span></font></div><div><font color=3D"#000000" face=3D"sa=
ns-serif"><span style=3D"line-height:19.1875px">In the certificates section=
, you could observe that "validation" means "verification th=
at it correctly chains to a trusted root authority, where trusted roots may=
be obtained from the operating system. If there is no operating system, th=
e Mozilla root store is recommended".</span></font></div>
<div><font color=3D"#000000" face=3D"sans-serif"><span style=3D"line-height=
:19.1875px"><br></span></font></div><div><font color=3D"#000000" face=3D"sa=
ns-serif"><span style=3D"line-height:19.1875px">All the rest LGTM.</span></=
font></div>
<h3 style=3D"color:black;background-image:none;margin:0px 0px 0.3em;overflo=
w:hidden;padding-top:0.5em;padding-bottom:0.17em;border-bottom-style:none;f=
ont-size:16.799999237060547px"><span class=3D"" style=3D"float:right;font-s=
ize:12.800000190734863px;font-weight:normal;margin-left:5px;font-family:san=
s-serif;line-height:19.200000762939453px">[<a href=3D"https://en.bitcoin.it=
/w/index.php?title=3DBIP_0070&action=3Dedit&section=3D7" title=3D"E=
dit section: Payment" style=3D"text-decoration:none;color:rgb(11,0,128);bac=
kground-image:none">edit</a>]</span><span class=3D"" id=3D"Payment" style=
=3D"font-family:sans-serif;font-size:16.799999237060547px;line-height:19.20=
0000762939453px"></span></h3>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed,=
Jul 31, 2013 at 8:28 AM, Gavin Andresen <span dir=3D"ltr"><<a href=3D"m=
ailto:gavinandresen@gmail.com" target=3D"_blank">gavinandresen@gmail.com</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">I've turned the preliminary payment prot=
ocol spec into three BIPs:<div><br></div><div><a href=3D"https://en.bitcoin=
.it/wiki/BIP_0070" target=3D"_blank">https://en.bitcoin.it/wiki/BIP_0070</a=
> : Network protocol / messages</div>
<div><a href=3D"https://en.bitcoin.it/wiki/BIP_0071" target=3D"_blank">http=
s://en.bitcoin.it/wiki/BIP_0071</a> : MIME types for the messages</div>
<div><a href=3D"https://en.bitcoin.it/wiki/BIP_0072" target=3D"_blank">http=
s://en.bitcoin.it/wiki/BIP_0072</a> : bitcoin: URI extension</div><div><br>=
</div><div>I expect the wallet-side implementation to be pulled into Bitcoi=
n-Qt Real Soon:</div>
<div>=C2=A0=C2=A0<a href=3D"https://github.com/bitcoin/bitcoin/pull/2539" t=
arget=3D"_blank">https://github.com/bitcoin/bitcoin/pull/2539</a></div><div=
><br></div><div>There is also a reference implementation of server-side cod=
e for generating payment requests in php and C++ :</div>
<div>=C2=A0=C2=A0<a href=3D"https://github.com/gavinandresen/paymentrequest=
" target=3D"_blank">https://github.com/gavinandresen/paymentrequest</a><spa=
n class=3D"HOEnZb"><font color=3D"#888888"><br clear=3D"all"><div><br></div=
><div>--=C2=A0</div>
--<br>Gavin Andresen<br>
</font></span></div><div><br></div>
<br>-----------------------------------------------------------------------=
-------<br>
Get your SQL database under version control now!<br>
Version control is standard for application code, but databases havent<br>
caught up. So what steps can you take to put your SQL databases under<br>
version control? Why should you start doing it? Read more to find out.<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D49501711&iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D49501711&iu=3D/4140/ostg.clktrk</a><br>___________________=
____________________________<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>
--001a11333dcefa0cb004e2caf1dd--
|
