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-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1W8qLw-0006mc-03 for bitcoin-development@lists.sourceforge.net; Thu, 30 Jan 2014 12:04:16 +0000 X-ACL-Warn: Received: from borboggle.com ([69.164.197.78] helo=mail.borboggle.com) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1W8qLu-0000ct-5X for bitcoin-development@lists.sourceforge.net; Thu, 30 Jan 2014 12:04:15 +0000 Received: from [192.168.1.72] (unknown [180.183.159.154]) by mail.borboggle.com (Postfix) with ESMTPSA id BDDA1FAA8; Thu, 30 Jan 2014 07:15:15 -0500 (EST) Message-ID: <52EA3FAD.5080802@borboggle.com> Date: Thu, 30 Jan 2014 19:03:57 +0700 From: Chuck User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Pieter Wuille , Mike Hearn References: <52E9E787.8080304@borboggle.com> <52EA343E.4010208@borboggle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.4 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1W8qLu-0000ct-5X Cc: Bitcoin-Dev Subject: Re: [Bitcoin-development] BIP70 message delivery reliability 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: Thu, 30 Jan 2014 12:04:16 -0000 On 1/30/2014 7:02 PM, Pieter Wuille wrote: > On Thu, Jan 30, 2014 at 12:59 PM, Mike Hearn wrote: >> With the way it works in bitcoinj, the tx is only committed to the wallet if >> the server accepts the Payment message and ACKs it. So the tx would not be >> retried if there's a failure submitting or some kind of internal server >> error, and the UI would show that the payment failed. That seems >> straightforward and how I'd expect things to work as a user. > That's one right way to do it imho, but not what is suggested or > required by the specification, and not what bitcoin core master > currently implements. > If you sent the Payment message and the server goes silent after receiving it, you retry to delivery. However, the merchant can broadcast the transactions and force them into your wallet anyway. You could, quite likely, pay and never get an ACK.