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 ------------------------------------------------------------------------------ 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
