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 1W8qsu-00087N-IG for bitcoin-development@lists.sourceforge.net; Thu, 30 Jan 2014 12:38:20 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.51 as permitted sender) client-ip=209.85.214.51; envelope-from=mh.in.england@gmail.com; helo=mail-bk0-f51.google.com; Received: from mail-bk0-f51.google.com ([209.85.214.51]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1W8qsr-0002az-TC for bitcoin-development@lists.sourceforge.net; Thu, 30 Jan 2014 12:38:20 +0000 Received: by mail-bk0-f51.google.com with SMTP id w10so1426224bkz.10 for ; Thu, 30 Jan 2014 04:38:11 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.204.103.7 with SMTP id i7mr5503411bko.14.1391085491079; Thu, 30 Jan 2014 04:38:11 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.205.33.205 with HTTP; Thu, 30 Jan 2014 04:38:10 -0800 (PST) In-Reply-To: <52EA3FAD.5080802@borboggle.com> References: <52E9E787.8080304@borboggle.com> <52EA343E.4010208@borboggle.com> <52EA3FAD.5080802@borboggle.com> Date: Thu, 30 Jan 2014 13:38:10 +0100 X-Google-Sender-Auth: 1T1YDGZ-VSI-dYRoPd91WHtfD0I Message-ID: From: Mike Hearn To: Chuck Content-Type: multipart/alternative; boundary=001a113351548c7c2204f12f545b X-Spam-Score: -0.5 (/) 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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1W8qsr-0002az-TC 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:38:20 -0000 --001a113351548c7c2204f12f545b Content-Type: text/plain; charset=UTF-8 > > 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. > No retries. If there's a timeout the wallet will consider the payment not made, and if the merchant broadcasts anyway, the wallet will see the transactions and sync with them correctly. The ACK is not particularly important in the current design, so that's no big deal. If we see this situation crop up routinely we can take measures to improve things. I doubt we will. --001a113351548c7c2204f12f545b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If you sent the Payment message and the server g= oes silent after receiving it, you retry to delivery. =C2=A0However, the me= rchant can broadcast the transactions and force them into your wallet anywa= y. You could, quite likely, pay and never get an ACK.

No retries. If there's a timeout the w= allet will consider the payment not made, and if the merchant broadcasts an= yway, the wallet will see the transactions and sync with them correctly. Th= e ACK is not particularly important in the current design, so that's no= big deal.

If we see this situation crop up routinely we can take = measures to improve things. I doubt we will.
--001a113351548c7c2204f12f545b--