Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.215.47 as permitted sender)
	client-ip=209.85.215.47; envelope-from=gavinandresen@gmail.com;
	helo=mail-la0-f47.google.com; 
MIME-Version: 1.0
In-Reply-To: <20121128233619.GA6368@giles.gnomon.org.uk>
References: <CABsx9T0PsGLEAWRCjEDDFWQrb+DnJWQZ7mFLaZewAEX6vD1eHw@mail.gmail.com>
	<20121128233619.GA6368@giles.gnomon.org.uk>
Date: Thu, 29 Nov 2012 11:11:51 -0500
Message-ID: <CABsx9T09FYf2RTaMpmujt3qwTFc2JgnREH_7Hyk2mnCgb3CvAw@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Roy Badami <roy@gnomon.org.uk>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Payment Protocol Proposal:
	Invoices/Payments/Receipts
Precedence: list

RE: Roy Badami's comments on edge cases around submitting a Payment
message to a merchant and then not receiving a timely response:

I agree, it is messy.

I'm hesitant to try to specify One True Way of handling it in the
spec; I've got a feeling that this might be a place where different
implementations might try different things, with the best
implementation winning.

For example, if some future nifty-keen Bitcoin client is re-using an
old Invoice to send a monthly subscription payment and they can't
contact the paymentURI, then the right thing is probably for it to
retry once a day for three or four days and if they all fail then give
up and tell the user that the service is no longer in business (or
changed their paymentURI without leaving behind a redirect).

If it has a single-use Invoice created a minute or two ago, the right
logic might be:
  + If the paymentURI is completely non-responsive, just error and
tell the user "payment failed"
  + If connected to the paymentURI and payment sent, but disconnected
before receiving a response, then try to send-to-self the coins to
cancel payment.

Again, I'm not at all sure that is the best way to handle it;
implementors have the right incentives to give their users the best
user experience, so I feel comfortable leaving the spec fuzzy for now.

-- 
--
Gavin Andresen