Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1V7AOe-000769-Al for bitcoin-development@lists.sourceforge.net; Wed, 07 Aug 2013 20:31:52 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.223.172 as permitted sender) client-ip=209.85.223.172; envelope-from=pieter.wuille@gmail.com; helo=mail-ie0-f172.google.com; Received: from mail-ie0-f172.google.com ([209.85.223.172]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1V7AOc-0003tw-Gm for bitcoin-development@lists.sourceforge.net; Wed, 07 Aug 2013 20:31:52 +0000 Received: by mail-ie0-f172.google.com with SMTP id 17so339057iea.17 for ; Wed, 07 Aug 2013 13:31:45 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.56.51 with SMTP id x19mr477340igp.12.1375907505135; Wed, 07 Aug 2013 13:31:45 -0700 (PDT) Received: by 10.50.73.74 with HTTP; Wed, 7 Aug 2013 13:31:45 -0700 (PDT) In-Reply-To: References: Date: Wed, 7 Aug 2013 22:31:45 +0200 Message-ID: From: Pieter Wuille To: Gavin Andresen Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -1.6 (-) 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 (pieter.wuille[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 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: 1V7AOc-0003tw-Gm Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72 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, 07 Aug 2013 20:31:52 -0000 On Wed, Jul 31, 2013 at 8:28 AM, Gavin Andresen wrote: > I've turned the preliminary payment protocol spec into three BIPs: > > https://en.bitcoin.it/wiki/BIP_0070 : Network protocol / messages I don't like the wording for payment_uri "where the payment _may_ be sent to obtain a paymentACK", or the fact that in the diagram it is the client wallet broadcasting the transaction to the network. In my opinion, it should ultimately become the responsibility of the receiver to get the transaction confirmed. Of course, the sender may help, and if the transaction does not confirm, no payment took place. But one of the advantages direct negotiation offers, is that the sender wallet does not need to remain online anymore to get the transaction broadcast. I don't think it should be even required that the sender wallet is connected to the P2P network at all. All they need to do is construct a satisfactory transaction, and send it to the merchant who cares about it. I would suggest the wording, "if a payment_uri is specified, the wallet application should try - and if necessary, retry - to submit the transaction there, resulting in a paymentACK from the merchant. Broadcasting the transaction on the P2P network is optional.". Perhaps we should even discourage broadcasting before the paymentACK is obtained, to make sure the merchant received it, together with the metadata, to decrease the chances of money arriving at a merchant without metadata (to minimize the cases where manual intervention is needed). -- Pieter