Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of zikula.org
	designates 74.125.82.41 as permitted sender)
	client-ip=74.125.82.41; envelope-from=drak@zikula.org;
	helo=mail-wg0-f41.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>
From: Drak <drak@zikula.org>
Date: Tue, 3 Dec 2013 12:05:21 +0000
Message-ID: <CANAnSg0s-fo=+SmzZpv+5Yv32jXP3ptnjbV8DxexC8tvW5wtDg@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=f46d04428e3a89001604eca01d10
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Floating fees and SPV clients
Precedence: list

--f46d04428e3a89001604eca01d10
Content-Type: text/plain; charset=UTF-8

On 3 December 2013 11:46, Mike Hearn <mike@plan99.net> wrote:

> On Tue, Dec 3, 2013 at 12:41 PM, Gavin Andresen <gavinandresen@gmail.com>wrote:
>>
>> If users want to pay with a huge transaction then it seems to me the user
>> should cover that cost. Allowing users to pay merchants with 100K
>> transactions full of dust and expecting them to eat the cost seems like a
>> great way to enable bleed-the-merchant-dry attacks.
>>
>
> A merchant can always refuse the payment and refund it if that's a
> practical problem. I doubt it would be though. If a user is trying to buy
> something from the merchant, they will want it to work, and it'll be up to
> the developers of the wallet they're using to ensure it never does anything
> obnoxious or unacceptable that would result in people hating to receive
> money from that app.
>

Refunds in this circumstance would be problematic because someone is going
to lose because they have to pay the fee. If the sender's money is refunded
minus the fee, they will be unhappy. And the merchant will be unhappy about
having had an unacceptable transaction they have to send back, and eat a
fee for the privilege.

This kind of situation needs to be avoided at all costs.

--f46d04428e3a89001604eca01d10
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 3=
 December 2013 11:46, Mike Hearn <span dir=3D"ltr">&lt;<a href=3D"mailto:mi=
ke@plan99.net" target=3D"_blank">mike@plan99.net</a>&gt;</span> wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa=
dding-left:1ex">

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
 class=3D"im">On Tue, Dec 3, 2013 at 12:41 PM, Gavin Andresen <span dir=3D"=
ltr">&lt;<a href=3D"mailto:gavinandresen@gmail.com" target=3D"_blank">gavin=
andresen@gmail.com</a>&gt;</span> wrote:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rg=
b(204,204,204);border-left-style:solid;padding-left:1ex">


<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_extra">If u=
sers want to pay with a huge transaction then it seems to me the user shoul=
d cover that cost. Allowing users to pay merchants with 100K transactions f=
ull of dust and expecting them to eat the cost seems like a great way to en=
able bleed-the-merchant-dry attacks.</div>


</div></div></blockquote><div><br></div></div><div>A merchant can always re=
fuse the payment and refund it if that&#39;s a practical problem. I doubt i=
t would be though. If a user is trying to buy something from the merchant, =
they will want it to work, and it&#39;ll be up to the developers of the wal=
let they&#39;re using to ensure it never does anything obnoxious or unaccep=
table that would result in people hating to receive money from that app.</d=
iv>

</div></div></div></blockquote><div><br></div><div>Refunds in this circumst=
ance would be problematic because someone is going to lose because they hav=
e to pay the fee. If the sender&#39;s money is refunded minus the fee, they=
 will be unhappy. And the merchant will be unhappy about having had an unac=
ceptable transaction they have to send back, and eat a fee for the privileg=
e.=C2=A0</div>

<div><br></div><div>This kind of situation needs to be avoided at all costs=
.=C2=A0</div></div></div></div>

--f46d04428e3a89001604eca01d10--