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; 
To: bitcoin-development@lists.sourceforge.net
From: Andreas Schildbach <andreas@schildbach.de>
Date: Mon, 13 Jan 2014 18:44:18 +0100
Message-ID: <lb18l6$nu2$1@ger.gmane.org>
References: <CAPg+sBhdgVQvumL_r9thLD5wm7UOJx=2DE+01-T58HHdimvpXw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
In-Reply-To: <CAPg+sBhdgVQvumL_r9thLD5wm7UOJx=2DE+01-T58HHdimvpXw@mail.gmail.com>
Subject: Re: [Bitcoin-development] Payment protocol and reliable Payment
	messages
Precedence: list

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.