* [Bitcoin-development] Error handling in payment protocol (BIP-0070 and BIP-0072)
@ 2014-04-25 19:54 J Ross Nicoll
2014-04-25 22:33 ` Andreas Schildbach
2014-04-26 13:23 ` Gavin Andresen
0 siblings, 2 replies; 7+ messages in thread
From: J Ross Nicoll @ 2014-04-25 19:54 UTC (permalink / raw)
To: gavinandresen; +Cc: bitcoin-development
Dear Gavin, all,
Going over the payment protocol specifications, I've noticed that
there's appears to be a lack of specificity on handling of error states.
In most cases there are reasonably obvious solutions, however it would
seem positive to formalise processes to ensure consistency. I'm
wondering therefore if either you'd be willing to edit the existing BIP,
or advise on whether this is useful to write up as a new BIP?
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.
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.
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? 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.
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.
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, any thoughts on whether it should hold the
connection, or send a PaymentACK with a memo indicating payment has been
seen on the relay network but is not yet confirmed, or something else?
Happy to write this up as a new BIP if that's more appropriate than
editing the original, and please do tell me if I've missed anything
obvious/prior discussion on this topic.
Ross
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Bitcoin-development] Error handling in payment protocol (BIP-0070 and BIP-0072)
2014-04-25 19:54 [Bitcoin-development] Error handling in payment protocol (BIP-0070 and BIP-0072) J Ross Nicoll
@ 2014-04-25 22:33 ` Andreas Schildbach
2014-04-26 13:23 ` Gavin Andresen
1 sibling, 0 replies; 7+ messages in thread
From: Andreas Schildbach @ 2014-04-25 22:33 UTC (permalink / raw)
To: bitcoin-development
These two BIPs are not accepted yet, so feel free to submit PRs for them.
Note BIP70 is almost agnostic to transport layer. For example, I have
implemented it for NFC, QR-codes, Bluetooth, e-mail and In-app payments
in Bitcoin Wallet -- doesn't make much sense to put HTTP status codes
into the spec.
Max message sizes make sense. I also thought about adding a guarantee
that the payment_url is valid for as long as the payment request is valid.
On 04/25/2014 09:54 PM, J Ross Nicoll wrote:
> Dear Gavin, all,
>
> Going over the payment protocol specifications, I've noticed that
> there's appears to be a lack of specificity on handling of error states.
> In most cases there are reasonably obvious solutions, however it would
> seem positive to formalise processes to ensure consistency. I'm
> wondering therefore if either you'd be willing to edit the existing BIP,
> or advise on whether this is useful to write up as a new BIP?
>
> 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.
>
> 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.
>
>
> 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? 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.
>
> 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.
>
> 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, any thoughts on whether it should hold the
> connection, or send a PaymentACK with a memo indicating payment has been
> seen on the relay network but is not yet confirmed, or something else?
>
> Happy to write this up as a new BIP if that's more appropriate than
> editing the original, and please do tell me if I've missed anything
> obvious/prior discussion on this topic.
>
>
> Ross
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Bitcoin-development] Error handling in payment protocol (BIP-0070 and BIP-0072)
2014-04-25 19:54 [Bitcoin-development] Error handling in payment protocol (BIP-0070 and BIP-0072) J Ross Nicoll
2014-04-25 22:33 ` Andreas Schildbach
@ 2014-04-26 13:23 ` Gavin Andresen
2014-04-26 16:45 ` Ross Nicoll
2014-04-26 17:36 ` Mike Hearn
1 sibling, 2 replies; 7+ messages in thread
From: Gavin Andresen @ 2014-04-26 13:23 UTC (permalink / raw)
To: J Ross Nicoll; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2791 bytes --]
>
> 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
[-- Attachment #2: Type: text/html, Size: 3961 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Bitcoin-development] Error handling in payment protocol (BIP-0070 and BIP-0072)
2014-04-26 13:23 ` Gavin Andresen
@ 2014-04-26 16:45 ` Ross Nicoll
2014-04-26 17:36 ` Mike Hearn
1 sibling, 0 replies; 7+ messages in thread
From: Ross Nicoll @ 2014-04-26 16:45 UTC (permalink / raw)
To: Gavin Andresen, andreas; +Cc: Bitcoin Dev
Dear Gavin, Andreas,
I'd see standardisation (or at least suggested standards) for error
handling as positive for consistency of user experience. I do see what
you mean about over-specification, however.
Thanks for the feedback, I've taken the main points and created two pull
requests:
BIP-0070: https://github.com/bitcoin/bips/pull/54/
BIP-0072: https://github.com/bitcoin/bips/pull/55/
Please tell me if these need any further work.
Ross
On 26/04/14 14:23, Gavin Andresen wrote:
>> 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.
>
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Bitcoin-development] Error handling in payment protocol (BIP-0070 and BIP-0072)
2014-04-26 13:23 ` Gavin Andresen
2014-04-26 16:45 ` Ross Nicoll
@ 2014-04-26 17:36 ` Mike Hearn
2014-04-26 17:43 ` Ross Nicoll
1 sibling, 1 reply; 7+ messages in thread
From: Mike Hearn @ 2014-04-26 17:36 UTC (permalink / raw)
To: Gavin Andresen; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 349 bytes --]
>
> 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.
>
In future it might be nice to have images and things in the payment
requests, to make UIs look prettier. But with the current version 50kb
should be plenty indeed.
[-- Attachment #2: Type: text/html, Size: 686 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Bitcoin-development] Error handling in payment protocol (BIP-0070 and BIP-0072)
2014-04-26 17:36 ` Mike Hearn
@ 2014-04-26 17:43 ` Ross Nicoll
2014-04-27 7:53 ` Kevin Greene
0 siblings, 1 reply; 7+ messages in thread
From: Ross Nicoll @ 2014-04-26 17:43 UTC (permalink / raw)
To: Mike Hearn, Gavin Andresen; +Cc: Bitcoin Dev
I'd be very cautious of security implications of embedding files into
the payment request. Even file formats one would presume safe, such as
images, have had security issues (i.e.
https://technet.microsoft.com/library/security/ms11-006 )
Longer term I was wondering about embedding the PaymentRequest into web
pages directly via the <object> tag, which could eliminate need for
BIP0072 and potentially improve user interface integration that way.
Obviously this would require browser plugins, however.
Ross
On 26/04/14 18:36, Mike Hearn wrote:
>> 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.
>>
> In future it might be nice to have images and things in the payment
> requests, to make UIs look prettier. But with the current version 50kb
> should be plenty indeed.
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Bitcoin-development] Error handling in payment protocol (BIP-0070 and BIP-0072)
2014-04-26 17:43 ` Ross Nicoll
@ 2014-04-27 7:53 ` Kevin Greene
0 siblings, 0 replies; 7+ messages in thread
From: Kevin Greene @ 2014-04-27 7:53 UTC (permalink / raw)
To: Ross Nicoll; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1684 bytes --]
Keep in mind that links don't always come embedded in html. Think of native
mobile apps.
On Sat, Apr 26, 2014 at 10:43 AM, Ross Nicoll <jrn@jrn•me.uk> wrote:
> I'd be very cautious of security implications of embedding files into
> the payment request. Even file formats one would presume safe, such as
> images, have had security issues (i.e.
> https://technet.microsoft.com/library/security/ms11-006 )
>
> Longer term I was wondering about embedding the PaymentRequest into web
> pages directly via the <object> tag, which could eliminate need for
> BIP0072 and potentially improve user interface integration that way.
> Obviously this would require browser plugins, however.
>
> Ross
>
> On 26/04/14 18:36, Mike Hearn wrote:
> >> 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.
> >>
> > In future it might be nice to have images and things in the payment
> > requests, to make UIs look prettier. But with the current version 50kb
> > should be plenty indeed.
> >
>
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
[-- Attachment #2: Type: text/html, Size: 2711 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2014-04-27 7:53 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-04-25 19:54 [Bitcoin-development] Error handling in payment protocol (BIP-0070 and BIP-0072) J Ross Nicoll
2014-04-25 22:33 ` Andreas Schildbach
2014-04-26 13:23 ` Gavin Andresen
2014-04-26 16:45 ` Ross Nicoll
2014-04-26 17:36 ` Mike Hearn
2014-04-26 17:43 ` Ross Nicoll
2014-04-27 7:53 ` Kevin Greene
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox