summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRoss Nicoll <jrn@jrn.me.uk>2014-04-26 17:45:49 +0100
committerbitcoindev <bitcoindev@gnusha.org>2014-04-26 16:45:59 +0000
commitf350e50af12b63dc685ebad3d634052bdb3ba550 (patch)
treeafccc394c646b02745fdf22c9d119c4c573c5657
parent743cc04e2acbb55b6b8a98fc9257a3c2b84e2283 (diff)
downloadpi-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/2ad65c3a9b2c7d6ee7420d5abecbefba26d7b1126
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.
+>
+>
+
+
+