Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.49 as permitted sender)
	client-ip=74.125.82.49; envelope-from=gavinandresen@gmail.com;
	helo=mail-wg0-f49.google.com; 
MIME-Version: 1.0
In-Reply-To: <CANEZrP0P9NTJXs22K8-4hnLkxV7Uo+tjvWKJ8msgxiFgJW6xvg@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>
Date: Tue, 3 Dec 2013 21:41:10 +1000
Message-ID: <CABsx9T2cs5Agzpbn7S1ppzDnFgLuMJoqFVFZjJzPU+RuSVrQPQ@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=089e0102e3e0e23bcb04ec9fc5c4
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Floating fees and SPV clients
Precedence: list

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

>
> Wouldn't the idea be that the user always sees 10mBTC no matter what, but
> the receiver may receive less if the user decides to pay with a huge
> transaction?
>

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.


RE: hiding or showing fees:  I pointed out to Peter that there doesn't have
to be One True Answer.  Let wallets experiment with either hiding or
exposing fees, and may the best user experience win.

-- 
--
Gavin Andresen

--089e0102e3e0e23bcb04ec9fc5c4
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 class=3D"im"><span style=3D"color:rgb(34,34,34)">Wouldn&#39;t the idea=
 be that the user always sees 10mBTC no matter what, but the receiver may r=
eceive less if the user decides to pay with a huge transaction?</span><br><=
/div>
<div></div></div></div></div></blockquote></div><div class=3D"gmail_extra">=
<br></div><div class=3D"gmail_extra">If users want to pay with a huge trans=
action 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 attack=
s.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><=
div class=3D"gmail_extra">RE: hiding or showing fees: =A0I pointed out to P=
eter that there doesn&#39;t have to be One True Answer. =A0Let wallets expe=
riment with either hiding or exposing fees, and may the best user experienc=
e win.</div>
<div><br></div>-- <br>--<br>Gavin Andresen<br>
</div></div>

--089e0102e3e0e23bcb04ec9fc5c4--