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 1W2kc7-0002Ap-My for bitcoin-development@lists.sourceforge.net; Mon, 13 Jan 2014 16:43:47 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.213.178 as permitted sender) client-ip=209.85.213.178; envelope-from=pieter.wuille@gmail.com; helo=mail-ig0-f178.google.com; Received: from mail-ig0-f178.google.com ([209.85.213.178]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1W2kc6-0002Ja-VT for bitcoin-development@lists.sourceforge.net; Mon, 13 Jan 2014 16:43:47 +0000 Received: by mail-ig0-f178.google.com with SMTP id uq10so2402140igb.5 for ; Mon, 13 Jan 2014 08:43:41 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.43.65.145 with SMTP id xm17mr21609572icb.35.1389631421670; Mon, 13 Jan 2014 08:43:41 -0800 (PST) Received: by 10.50.90.42 with HTTP; Mon, 13 Jan 2014 08:43:41 -0800 (PST) Date: Mon, 13 Jan 2014 17:43:41 +0100 Message-ID: From: Pieter Wuille To: Bitcoin Dev 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: 1W2kc6-0002Ja-VT Subject: [Bitcoin-development] Payment protocol and reliable Payment messages 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: Mon, 13 Jan 2014 16:43:48 -0000 Hi all, while thinking about what use cases the stealth addresses covers, in particular in addition to the payment protocol, I found it useful to bring this up again. currently, BIP70 says for "payment_url": Secure (usually https) location where a Payment message (see below) may be sent to obtain a PaymentACK. The fact that this is optional makes the "memo" and "refund" and "merchant_data" fields in the Payment message useless, as merchants cannot rely on it, thus need to provide an alternative, thus nobody would have a use for trying to use the in-Payment versions. If we truly want the use of this Payment being sent be optional, I'd vote to get rid of these and just send the transaction. In particular in the case of more anonymous senders, if the Payment message isn't sent, it may result in funds being transferred without a way to know who to refund it to if something goes wrong. That would be a pity. I think having bi-directional communication in the protocol is one of the nicest things the payment protocol can add. I would prefer to at least formulate it in the BIP as "location where a Payment message must be attempted to be sent to". In case it fails, it should probably be stored in the client and retried later. As an optimization (and I believe this is what Mike plans to implement in BitcoinJ), if a payment_url is present, it should be encouraged to only send the payment there, and not broadcast the transaction at all on the P2P network (minimizing the risk that the transaction confirms without the payment being received; it can't be guaranteed however). -- Pieter