Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.48 as permitted sender)
	client-ip=74.125.82.48; envelope-from=gavinandresen@gmail.com;
	helo=mail-wg0-f48.google.com; 
MIME-Version: 1.0
In-Reply-To: <CANEZrP1Ef7P_bvE_qY+CsXG02=jGx8f4DrDKweSo7AAXLjeWXQ@mail.gmail.com>
References: <CANEZrP3tGdFh6oG5fbX9JbU6sYbbex1cq=0tQB-0A4aDrdbXrQ@mail.gmail.com>
	<l7f97u$jdg$1@ger.gmane.org>
	<5E4597E4-C1C7-4536-8CF0-82EDD7715DAB@plan99.net>
	<l7fpbn$hf6$1@ger.gmane.org>
	<39921E12-B411-4430-9D56-04F53906B109@plan99.net>
	<CAGLkj4C9fyAX1CnB0oZH3BwLRQp6WOo9kLUqDhRUSA6y3LxYvg@mail.gmail.com>
	<CANEZrP1C=Hc-3f-rqQ+wYrPn-eUj52HjN+qRQdJMWvnP+dkK=Q@mail.gmail.com>
	<CAJHLa0P_uzEQ2OG2FTXyD2Zw4RzujNBxKbKD04CSS1sLNpLUUQ@mail.gmail.com>
	<CANEZrP2hf2853w9f4__Ji9v3eRRU0u6pEzPxAmFN+iH067gtnA@mail.gmail.com>
	<CABsx9T3NQDPL6=pz5BD5DsP0qh0x3LJOCj2H3yY5tzL2_DivGA@mail.gmail.com>
	<CANEZrP1PLKemiUEgMJRGdiZXt7o=0_5fhLKYY0x3Ngb_iEm+2w@mail.gmail.com>
	<CABsx9T322nCvynRCL6Mb9C0f5EuJSfMDTSGiU+_JsYoSCb=_kQ@mail.gmail.com>
	<CANEZrP0P9NTJXs22K8-4hnLkxV7Uo+tjvWKJ8msgxiFgJW6xvg@mail.gmail.com>
	<CABsx9T2cs5Agzpbn7S1ppzDnFgLuMJoqFVFZjJzPU+RuSVrQPQ@mail.gmail.com>
	<CANEZrP1Ef7P_bvE_qY+CsXG02=jGx8f4DrDKweSo7AAXLjeWXQ@mail.gmail.com>
Date: Tue, 3 Dec 2013 21:54:41 +1000
Message-ID: <CABsx9T2CLBV7Xnx8ePEonYnr7HTZDRi14=ZhQeNznftL9Mj7Uw@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Mike Hearn <mike@plan99.net>, 
	Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=089e0102e3e039535504ec9ff658
Subject: Re: [Bitcoin-development] Floating fees and SPV clients
Precedence: list

--089e0102e3e039535504ec9ff658
Content-Type: text/plain; charset=ISO-8859-1

>
> A merchant can always refuse the payment and refund it if that's a
> practical problem.
>

No, they can't, at least not in bitcoin-qt:  when the user pokes the SEND
button, the transaction is broadcast on the network, and then the merchant
is also told with the Payment/PaymentACK round-trip.

Allowing merchants to cancel (e.g. having a PaymentNACK) makes
implementation harder, and brings up nasty issues if we want to allow
CoinJoin or CoinJoin-like transactions as payments to merchants.
 Bitcoin-Qt ALREADY allows you to pay several PaymentRequests with one
transaction; handling the case where one merchant gives you a PaymentACK
and another gives you (or wants to give you) a PaymentNACK is a nightmare.

--
Gavin Andresen

--089e0102e3e039535504ec9ff658
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div=
 class=3D"gmail_quote">
<div>A merchant can always refuse the payment and refund it if that&#39;s a=
 practical problem.</div></div></div></div></blockquote><div><br></div><div=
>No, they can&#39;t, at least not in bitcoin-qt: =A0when the user pokes the=
 SEND button, the transaction is broadcast on the network, and then the mer=
chant is also told with the Payment/PaymentACK round-trip.</div>
<div><br></div><div>Allowing merchants to cancel (e.g. having a PaymentNACK=
) makes implementation harder, and brings up nasty issues if we want to all=
ow CoinJoin or CoinJoin-like transactions as payments to merchants. =A0Bitc=
oin-Qt ALREADY allows you to pay several PaymentRequests with one transacti=
on; handling the case where one merchant gives you a PaymentACK and another=
 gives you (or wants to give you) a PaymentNACK is a nightmare.</div>
<div><br></div><div>--<br></div></div>Gavin Andresen<br>
</div></div>

--089e0102e3e039535504ec9ff658--