Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.219.50 as permitted sender)
	client-ip=209.85.219.50; envelope-from=mh.in.england@gmail.com;
	helo=mail-oa0-f50.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <CABsx9T322nCvynRCL6Mb9C0f5EuJSfMDTSGiU+_JsYoSCb=_kQ@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>
Date: Tue, 3 Dec 2013 12:29:03 +0100
Message-ID: <CANEZrP0P9NTJXs22K8-4hnLkxV7Uo+tjvWKJ8msgxiFgJW6xvg@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=089e0111bca487cc8504ec9f9a9d
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Floating fees and SPV clients
Precedence: list

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

On Tue, Dec 3, 2013 at 12:07 PM, Gavin Andresen <gavinandresen@gmail.com>wrote:

> Making it fee-per-kilobyte is a bad idea, in my opinion; users don't care
> how many kilobytes their transactions are, and they will just be confused
> if they're paying for a 10mBTC burger and are asked to pay 10.00011 or
> 9.9994 because the merchant has no idea how many kilobytes the paying
> transaction will be.
>

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?

It may be acceptable that receivers don't always receive exactly what they
requested, at least for person-to-business transactions.  For
person-to-person transactions of course any fee at all is confusing because
you intuitively expect that if you send 1 mBTC, then 1 mBTC will arrive the
other end. I wonder if we'll end up in a world where buying things from
shops involves paying fees, and (more occasional?) person-to-person
transactions tend to be free and people just understand that the money
isn't going to be spendable for a while. Or alternatively that wallets let
you override the safeguards on spending unconfirmed coins when the user is
sure that they trust the sender.

--089e0111bca487cc8504ec9f9a9d
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 T=
ue, Dec 3, 2013 at 12:07 PM, Gavin Andresen <span dir=3D"ltr">&lt;<a href=
=3D"mailto:gavinandresen@gmail.com" target=3D"_blank">gavinandresen@gmail.c=
om</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Making it fee-per-kilo=
byte is a bad idea, in my opinion; users don&#39;t care how many kilobytes =
their transactions are, and they will just be confused if they&#39;re payin=
g for a 10mBTC burger and are asked to pay 10.00011 or 9.9994 because the m=
erchant has no idea how many kilobytes the paying transaction will be.</div=
>
</div></blockquote><div><br></div><div>Wouldn&#39;t the idea be that the us=
er always sees 10mBTC no matter what, but the receiver may receive less if =
the user decides to pay with a huge transaction?</div><div><br></div><div>
It may be acceptable that receivers don&#39;t always receive exactly what t=
hey requested, at least for person-to-business transactions. =C2=A0For pers=
on-to-person transactions of course any fee at all is confusing because you=
 intuitively expect that if you send 1 mBTC, then 1 mBTC will arrive the ot=
her end. I wonder if we&#39;ll end up in a world where buying things from s=
hops involves paying fees, and (more occasional?) person-to-person transact=
ions tend to be free and people just understand that the money isn&#39;t go=
ing to be spendable for a while. Or alternatively that wallets let you over=
ride the safeguards on spending unconfirmed coins when the user is sure tha=
t they trust the sender.</div>
</div></div></div>

--089e0111bca487cc8504ec9f9a9d--