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-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1W32O4-0002if-7q for bitcoin-development@lists.sourceforge.net; Tue, 14 Jan 2014 11:42:28 +0000 X-ACL-Warn: Received: from mout.perfora.net ([74.208.4.194]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1W32O2-0007O9-Fe for bitcoin-development@lists.sourceforge.net; Tue, 14 Jan 2014 11:42:28 +0000 Received: from netbook (c107-70.i07-27.onvol.net [92.251.107.70]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0Md2qI-1Vm3SC2rdC-00ICga; Tue, 14 Jan 2014 06:41:44 -0500 Received: by netbook (Postfix, from userid 1000) id 499082E035F; Tue, 14 Jan 2014 12:41:37 +0100 (CET) Received: by flare (hashcash-sendmail, from uid 1000); Tue, 14 Jan 2014 12:41:34 +0100 Date: Tue, 14 Jan 2014 12:41:34 +0100 From: Adam Back To: Mike Hearn Message-ID: <20140114114134.GA9838@netbook.cypherspace.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Hashcash: 1:20:140114:mike@plan99.net::YWbmYLUSmOecpnnO:006rj+ X-Hashcash: 1:20:140114:andreas@schildbach.de::gMa3UfsoNixiQs75:0000000000000000 0000000000000000000000003GiE X-Hashcash: 1:20:140114:bitcoin-development@lists.sourceforge.net::Bg/Ebjpp1y4ya 77Z:000000000000000000003xYH X-Hashcash: 1:20:140114:adam@cypherspace.org::fdbFahm5Dh6voQdU:00000000000000000 0000000000000000000000000kUy X-Provags-ID: V02:K0:FjkNZT/7aM1LTlK6NOF9MyI+6Ywn+FackL8XSze9osm TTy1Cawi4FpXSOp10dlrArLzfu3Ah3SIQ9rj0M85+ALE9OrJtg tROvjOeumHWv0wwwRFyV6Z1W0i8MWDwM2yECGS3ngCLaXIYDVc +bSSLZYSZ2u9MWx+Puu4aPfR0KRetZcpJ2n79jj2SKK95pZlcc eucl3ail/rWyKamq11KtBy8eYTQJEfSAqlh5LFsmR3CaoTRaLi U6w0KQ+VoqWcK7+UrBoUT7yITiV9aWVX9m4bULLEpRoWCLk64y lgDymb2wEkNKuNOEZdvV38g4/dRBU95Fb7tTIS6ftDAyoJtRdF 8/Y/F3sojTaznGjHBR33LMzIAEr1M3sIAGNOZDd5n X-Spam-Score: -0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [74.208.4.194 listed in list.dnswl.org] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record X-Headers-End: 1W32O2-0007O9-Fe Cc: Bitcoin Dev , Andreas Schildbach 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: Tue, 14 Jan 2014 11:42:28 -0000 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