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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gavinandresen@gmail.com>) id 1We2ZS-0006US-Pf
for bitcoin-development@lists.sourceforge.net;
Sat, 26 Apr 2014 13:23:10 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.47 as permitted sender)
client-ip=209.85.213.47; envelope-from=gavinandresen@gmail.com;
helo=mail-yh0-f47.google.com;
Received: from mail-yh0-f47.google.com ([209.85.213.47])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1We2ZQ-0001TL-W6
for bitcoin-development@lists.sourceforge.net;
Sat, 26 Apr 2014 13:23:10 +0000
Received: by mail-yh0-f47.google.com with SMTP id 29so4546907yhl.20
for <bitcoin-development@lists.sourceforge.net>;
Sat, 26 Apr 2014 06:23:03 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.142.204 with SMTP id i52mr20809091yhj.6.1398518583484;
Sat, 26 Apr 2014 06:23:03 -0700 (PDT)
Received: by 10.170.188.149 with HTTP; Sat, 26 Apr 2014 06:23:03 -0700 (PDT)
In-Reply-To: <535ABD5D.7070509@jrn.me.uk>
References: <535ABD5D.7070509@jrn.me.uk>
Date: Sat, 26 Apr 2014 09:23:03 -0400
Message-ID: <CABsx9T3boaWYuY8S-Xz=bAxe+ne5iP7m8AnuciaAOmDx_3D4Fg@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: J Ross Nicoll <jrn@jrn.me.uk>
Content-Type: multipart/alternative; boundary=20cf301b66ad6165fc04f7f1fbdb
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
(gavinandresen[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: 1We2ZQ-0001TL-W6
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Error handling in payment protocol
(BIP-0070 and BIP-0072)
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: Sat, 26 Apr 2014 13:23:10 -0000
--20cf301b66ad6165fc04f7f1fbdb
Content-Type: text/plain; charset=UTF-8
>
> The main area of concern is handling unexpected problems while sending
> the Payment message, or receiving the corresponding PaymentACK message.
> For example, in case of a transport layer failure or non-200 HTTP status
> code while sending the Payment message, what should the wallet software
> do next? Is it safe to re-send the Payment message? I'd propose that for
> any transport failure or 500 status code, the client retries after a
> delay (suggested at 30-60 seconds). For 400 status codes, the request
> should not be repeated, and as such the user should be alerted and a
> copy of the Payment message saved to be resent later.
>
Why does error handling have to be standardized?
I generally think that wallet software should be free to do whatever gives
the user the best experience, so I'm in favor of restricting BIPs to things
that must be standardized so that different implementations inter-operate.
> For 300 (redirect and similar) status codes, is it considered safe to
> follow redirects? I think we have to, but good to make it clear in the
> specification.
>
Referencing whatever RFCs defines how to fetch URLs would be the best way
to do this. Submit a pull request.
>
> On the merchant's side; I think it would be useful for there to be
> guidance for handling of errors processing Payment messages. I'd suggest
> that Payment messages should have a fixed maximum size to avoid merchant
> systems theoretically having to accept files of any size; 10MB would
> seem far larger than in any way practical, and therefore a good maximum
> size?
PaymentRequests are limited to 50,000 bytes. I can't think of a reason why
Payment messages would need to be any bigger than that. Submit a pull
request to the existing BIP.
> A defined maximum time to wait (to avoid DDoS via connection
> holding) might be useful too, although I'd need to do measurements to
> find what values are tolerable.
>
Implementation detail that doesn't belong in the spec, in my humble opinion.
> I would like to have the protocol state that merchant systems should
> handle repeatedly receiving the same Payment message, and return an
> equivalent (if not identical) PaymentACK to each. This is important in
> case of a network failure while the client is sending the Payment
> message, as outlined above.
>
I think this should be left to implementations to work out.
> Lastly, I'm wondering about potential timing issues with transactions;
> if a merchant system wants to see confirmation of a transaction before
> sending a PaymentACK...
.... not a good idea. The user should get feedback right away. Poking a
"pay now" button and then waiting more than a second or three to get "your
payment has been received and is being processed" is terrible UI.
--
--
Gavin Andresen
--20cf301b66ad6165fc04f7f1fbdb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">The main area of concern is handling unexpected =
problems while sending<br>
the Payment message, or receiving the corresponding PaymentACK message.<br>
For example, in case of a transport layer failure or non-200 HTTP status<br=
>
code while sending the Payment message, what should the wallet software<br>
do next? Is it safe to re-send the Payment message? I'd propose that fo=
r<br>
any transport failure or 500 status code, the client retries after a<br>
delay (suggested at 30-60 seconds). For 400 status codes, the request<br>
should not be repeated, and as such the user should be alerted and a<br>
copy of the Payment message saved to be resent later.<br></blockquote><div>=
<br></div><div>Why does error handling have to be standardized?</div><div><=
br></div><div>I generally think that wallet software should be free to do w=
hatever gives the user the best experience, so I'm in favor of restrict=
ing BIPs to things that must be standardized so that different implementati=
ons inter-operate.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">For 300 (redirect and simil=
ar) status codes, is it considered safe to<br>
follow redirects? I think we have to, but good to make it clear in the<br>
specification.<br></blockquote><div><br></div><div>Referencing whatever RFC=
s defines how to fetch URLs would be the best way to do this. Submit a pull=
request.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On the merchant's side; I think it would be useful for there to be<br>
guidance for handling of errors processing Payment messages. I'd sugges=
t<br>
that Payment messages should have a fixed maximum size to avoid merchant<br=
>
systems theoretically having to accept files of any size; 10MB would<br>
seem far larger than in any way practical, and therefore a good maximum<br>
size?</blockquote><div><br></div><div>PaymentRequests are limited to 50,000=
bytes. I can't think of a reason why Payment messages would need to be=
any bigger than that. Submit a pull request to the existing BIP.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"> A defined maximum time to =
wait (to avoid DDoS via connection<br>
holding) might be useful too, although I'd need to do measurements to<b=
r>
find what values are tolerable.<br></blockquote><div><br></div><div>Impleme=
ntation detail that doesn't belong in the spec, in my humble opinion.</=
div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I would like to have the protocol state that merchant systems should<br>
handle repeatedly receiving the same Payment message, and return an<br>
equivalent (if not identical) PaymentACK to each. This is important in<br>
case of a network failure while the client is sending the Payment<br>
message, as outlined above.<br></blockquote><div><br></div><div>I think thi=
s should be left to implementations to work out.</div><div>=C2=A0<br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Lastly, I'm wondering about potential timing issues with transactions;<=
br>
if a merchant system wants to see confirmation of a transaction before<br>
sending a PaymentACK...</blockquote><div><br></div><div>.... not a good ide=
a. The user should get feedback right away. Poking a "pay now" bu=
tton and then waiting more than a second or three to get "your payment=
has been received and is being processed" is terrible UI.</div>
</div><br clear=3D"all"><div><br></div>-- <br>--<br>Gavin Andresen<br>
</div></div>
--20cf301b66ad6165fc04f7f1fbdb--
|
