diff options
author | Ross Nicoll <jrn@jrn.me.uk> | 2014-04-26 17:45:49 +0100 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2014-04-26 16:45:59 +0000 |
commit | f350e50af12b63dc685ebad3d634052bdb3ba550 (patch) | |
tree | afccc394c646b02745fdf22c9d119c4c573c5657 | |
parent | 743cc04e2acbb55b6b8a98fc9257a3c2b84e2283 (diff) | |
download | pi-bitcoindev-f350e50af12b63dc685ebad3d634052bdb3ba550.tar.gz pi-bitcoindev-f350e50af12b63dc685ebad3d634052bdb3ba550.zip |
Re: [Bitcoin-development] Error handling in payment protocol (BIP-0070 and BIP-0072)
-rw-r--r-- | 26/2ad65c3a9b2c7d6ee7420d5abecbefba26d7b1 | 126 |
1 files changed, 126 insertions, 0 deletions
diff --git a/26/2ad65c3a9b2c7d6ee7420d5abecbefba26d7b1 b/26/2ad65c3a9b2c7d6ee7420d5abecbefba26d7b1 new file mode 100644 index 000000000..34563280f --- /dev/null +++ b/26/2ad65c3a9b2c7d6ee7420d5abecbefba26d7b1 @@ -0,0 +1,126 @@ +Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] + helo=mx.sourceforge.net) + by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <jrn@jrn.me.uk>) id 1We5jj-0003cr-Q9 + for bitcoin-development@lists.sourceforge.net; + Sat, 26 Apr 2014 16:45:59 +0000 +X-ACL-Warn: +Received: from s3.neomailbox.net ([178.209.62.157]) + by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) + (Exim 4.76) id 1We5ji-0005sY-4n + for bitcoin-development@lists.sourceforge.net; + Sat, 26 Apr 2014 16:45:59 +0000 +Message-ID: <535BE2BD.7010303@jrn.me.uk> +Date: Sat, 26 Apr 2014 17:45:49 +0100 +From: Ross Nicoll <jrn@jrn.me.uk> +User-Agent: Mozilla/5.0 (X11; Linux x86_64; + rv:24.0) Gecko/20100101 Thunderbird/24.4.0 +MIME-Version: 1.0 +To: Gavin Andresen <gavinandresen@gmail.com>, andreas@schildbach.de +References: <535ABD5D.7070509@jrn.me.uk> + <CABsx9T3boaWYuY8S-Xz=bAxe+ne5iP7m8AnuciaAOmDx_3D4Fg@mail.gmail.com> +In-Reply-To: <CABsx9T3boaWYuY8S-Xz=bAxe+ne5iP7m8AnuciaAOmDx_3D4Fg@mail.gmail.com> +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 7bit +X-Spam-Score: 0.0 (/) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. +X-Headers-End: 1We5ji-0005sY-4n +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 16:45:59 -0000 + +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. +> +> + + + |