From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1TdrRw-0007fv-R5 for bitcoin-development@lists.sourceforge.net; Wed, 28 Nov 2012 23:53:52 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gnomon.org.uk designates 93.93.131.22 as permitted sender) client-ip=93.93.131.22; envelope-from=roy@gnomon.org.uk; helo=darla.gnomon.org.uk; Received: from darla.gnomon.org.uk ([93.93.131.22]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1TdrRq-00063j-In for bitcoin-development@lists.sourceforge.net; Wed, 28 Nov 2012 23:53:52 +0000 Received: from darla.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by darla.gnomon.org.uk (8.14.3/8.14.3) with ESMTP id qASNaJ7H007000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Nov 2012 23:36:24 GMT (envelope-from roy@darla.gnomon.org.uk) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at darla.gnomon.org.uk Received: (from roy@localhost) by darla.gnomon.org.uk (8.14.3/8.14.1/Submit) id qASNaJXO006999; Wed, 28 Nov 2012 18:36:19 -0500 (EST) (envelope-from roy) Date: Wed, 28 Nov 2012 18:36:19 -0500 From: Roy Badami To: Gavin Andresen Message-ID: <20121128233619.GA6368@giles.gnomon.org.uk> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: -1.9 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record -0.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1TdrRq-00063j-In Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts 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: Wed, 28 Nov 2012 23:53:53 -0000 > If a Receipt is not received for any reason (timeout, error) and > Payment.transactions has not been broadcast by the merchant on the > Bitcoin p2p network, then the Bitcoin client should assume that the > payment failed, inform the customer that the payment failed, and > return coins involved in the transaction to the customer's wallet. I'm not sure I understand the rationale for this. In the above scenario the buyer has no way to determine whether the merchant still has a copy of the transaction that they could broadcast in future. Maybe there is simply a systems problem at the merchant which has temporarily delayed the transaction broadcast. Or maybe a dishonest merchant deliberately engineered this situation in an attempt to mislead the buyer as to the status of their payment. Either way, having the buyer think the coins have been returned to their wallet - only to disappear from their wallet again at some later time - would seriously damage user confidence in Bitcoin IMHO. It seems to me that the first thing the buyer should do given the protocol as it stands is simply resend the Payment message - if there was a temporary problem then resending the payment message (with the same signed transation) might resolve the sitution. If after several retries the status of the transaction is still undefined then it's really not clear what to do, but it seems desireable to have the client take steps so that it can return to a state of certainly about its wallet balance as quickly as possible. Two things I can imagine that the buyer might want their client to do at this point are: * broadcast the transaction itself, so they are sure the payment transaction will make it into the blockchain without any further action on their part, or * invalidate the transaction by immediately broadcasting a pay-to-self transaction that spends one or more of the same outputs that the payment transaction spends (and treat the funds as part of the unconfirmed balance until this pay-to-self transaction confirms). This ensures the merchant can't subsequently use a transaction which the buyer thinks has failed It seems to me it would be simpler and cleaner if the buyer just always broadcasted the transaction on the p2p network, regardless of whether the Invoice includes a receiptURI. If a receiptURI is included, the buyer's client would also include the transaction in the Purchase message. The merchant then tries to broadcast the transaction as well (unless their bitcoind has already seen it, which may well be the common case). This approach seems to me to have fewer nasty edge cases.s roy