Date: Tue, 14 Jan 2014 12:41:34 +0100
From: Adam Back <adam@cypherspace.org>
To: Mike Hearn <mike@plan99.net>
Message-ID: <20140114114134.GA9838@netbook.cypherspace.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>
	<lb30mu$jjh$1@ger.gmane.org>
	<CANEZrP3BeFMLtcThr=Gp5mudbtQeT_dHno1DGQzOg28YKBNkzA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <CANEZrP3BeFMLtcThr=Gp5mudbtQeT_dHno1DGQzOg28YKBNkzA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	Andreas Schildbach <andreas@schildbach.de>
Subject: Re: [Bitcoin-development] Payment protocol and reliable Payment
 messages
Precedence: list

He's probably thinking of fair advertising rules.  There are regulations
motivated by consumer protection/advertising standards (prevents merchant
listing attractive prices in media, and then when consumer goes to pay the
merchant says "oh actually that doesnt include X and Y, and the minimum
price is 10% more" after the user has already partly committed to the
purchase.  Ryanair, an airline near and dear to Europeans ;) is infamous for
aggressive use of such tactics.  Or worse systematic abuse of "sorry that
was a pricing mistake".

In trading situations its even more important, you're facing a dynamic
price, and revocable bids after acceptance but before payment allow system
gaming.  There were court cases about such things and trading systems gamed. 
So I think this is the use case to consider.  Payment request is an offer,
payment message is an acceptance, transaction broadcast is settlment.  After
acceptance the asker must not be allowed to retract ther ask.

Going back to Pieter's comment it seems there are two approaches: i) send
payment message to merchant, merchant broadcasts tx to network to claim
funds; ii) user broadcasts tx, and sends payment message to merchant.

In case i) the user is relying on the merchant in terms of retraction, for
many use-cases that doesnt matter, or consumer law says they can do that in
some places.  Though transferable proof the merchant is systematically
retracting advertised offers could be indirectly useful as it maybe evidence
of unfair trading, which can result in censure for the merchant!

In case ii) I think Andreas has a point.  Maybe the way to do that is to
also bind the transaction to the payment message.  Eg include the hash of
the payment message in the tx (circular ref may have to use multisig
approach?), or as Timo Hanke's paper where the offer/acceptance contact hash
is bound to the address (ie the address paid is Q'=H(Q+H(contract)G).

Adam

On Tue, Jan 14, 2014 at 11:45:59AM +0100, Mike Hearn wrote:
>     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.
>
>   Usually if the merchant has not delivered, then at that point it's not
>   a problem and he is allowed to change his mind. It's only if they
>   change their mind *after* you pay that it's a problem, right?

>------------------------------------------------------------------------------
>CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>Learn Why More Businesses Are Choosing CenturyLink Cloud For
>Critical Workloads, Development Environments & Everything In Between.
>Get a Quote or Start a Free Trial Today.
>http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk

>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development