From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 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 , andreas@schildbach.de References: <535ABD5D.7070509@jrn.me.uk> In-Reply-To: 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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. > >