Received-SPF: pass (sog-mx-1.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: Tue, 14 Jan 2014 10:40:58 +0100
Message-ID: <lb30mu$jjh$1@ger.gmane.org>
References: <CAPg+sBhdgVQvumL_r9thLD5wm7UOJx=2DE+01-T58HHdimvpXw@mail.gmail.com>	<lb18l6$nu2$1@ger.gmane.org>
	<CAPg+sBji5sFWZ_mDVXKKwkyeGYDbLmvwau457nmntT_NgTT+Sw@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+sBji5sFWZ_mDVXKKwkyeGYDbLmvwau457nmntT_NgTT+Sw@mail.gmail.com>
Subject: Re: [Bitcoin-development] Payment protocol and reliable Payment
	messages
Precedence: list

On 01/13/2014 06:56 PM, Pieter Wuille wrote:

> I want to avoid the case where a transaction confirms, but the
> associated payment is not delivered. If there is a reasonable chance
> that this case occurs in normal operation, it means the payment
> transmission cannot be relied upon.

I was thinking about this some more. Generally I think you have a point.
However, there is one case I'm worried about.

Imagine you get a good offer (payment request) from a merchant. You
would like to accept that offer, however the merchant has changed his
mind. If you don't broadcast the payment to the blockchain, you won't
have a chance to accept and legally bind the offer. The merchant will
silently discard your payment messages.

At some point, you will involve a judge. If you can present the payment
request and the payment from the block chain, you're in a much better
position than if you just present a request but no confirmed payment.

I think in some cases you might want to broadcast your txn to the P2P
network, even if the payment messages get lost. What do you think?