From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1W2lZ3-0005rn-0D for bitcoin-development@lists.sourceforge.net; Mon, 13 Jan 2014 17:44:41 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of m.gmane.org designates 80.91.229.3 as permitted sender) client-ip=80.91.229.3; envelope-from=gcbd-bitcoin-development@m.gmane.org; helo=plane.gmane.org; Received: from plane.gmane.org ([80.91.229.3]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1W2lYz-0002Pw-Q5 for bitcoin-development@lists.sourceforge.net; Mon, 13 Jan 2014 17:44:40 +0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1W2lYr-0004w7-Fc for bitcoin-development@lists.sourceforge.net; Mon, 13 Jan 2014 18:44:29 +0100 Received: from f053034198.adsl.alicedsl.de ([78.53.34.198]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 13 Jan 2014 18:44:29 +0100 Received: from andreas by f053034198.adsl.alicedsl.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 13 Jan 2014 18:44:29 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: bitcoin-development@lists.sourceforge.net From: Andreas Schildbach Date: Mon, 13 Jan 2014 18:44:18 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: f053034198.adsl.alicedsl.de User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: 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 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.91.229.3 listed in list.dnswl.org] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 1.1 DKIM_ADSP_ALL No valid author signature, domain signs all mail -0.0 SPF_PASS SPF: sender matches SPF record -0.1 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1W2lYz-0002Pw-Q5 Subject: Re: [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 17:44:41 -0000 On 01/13/2014 05:43 PM, Pieter Wuille wrote: > 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). Can you explain what the problem is here? The payment message can be transmitted after the payment has been received through the P2P network. Am I missing something? Furthermore, if we give up the robustness of the P2P network, we will likely end up with more failed payments. There is so much that can go wrong when trying to connect via HTTP (proxies etc.), Bluetooth endpoints can go away, etc. At least we should provide fallback payment_url's in this case. As for you proposal, just be aware I'd like to use the payment protocol for face to face payments as well. That meant payment request via NFC or QR, payment message and payment confirmations via Bluetooth. I think it can be done by putting a Bluetooth mac address into the payment_url.