From: Andreas Schildbach <andreas@schildbach•de>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Error handling in payment protocol (BIP-0070 and BIP-0072)
Date: Sat, 26 Apr 2014 00:33:36 +0200 [thread overview]
Message-ID: <ljens1$1qh$1@ger.gmane.org> (raw)
In-Reply-To: <535ABD5D.7070509@jrn.me.uk>
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
>
next prev parent reply other threads:[~2014-04-25 22:33 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-25 19:54 J Ross Nicoll
2014-04-25 22:33 ` Andreas Schildbach [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='ljens1$1qh$1@ger.gmane.org' \
--to=andreas@schildbach$(echo .)de \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox