Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.148.112 as permitted sender)
	client-ip=62.13.148.112; envelope-from=pete@petertodd.org;
	helo=outmail148112.authsmtp.co.uk; 
Date: Tue, 3 Dec 2013 06:37:25 -0500
From: Peter Todd <pete@petertodd.org>
To: Mike Hearn <mike@plan99.net>
Message-ID: <20131203113725.GC12623@tilt>
References: <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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="rQ2U398070+RC21q"
Content-Disposition: inline
In-Reply-To: <CANEZrP0P9NTJXs22K8-4hnLkxV7Uo+tjvWKJ8msgxiFgJW6xvg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Floating fees and SPV clients
Precedence: list


--rQ2U398070+RC21q
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 03, 2013 at 12:29:03PM +0100, Mike Hearn wrote:
> On Tue, Dec 3, 2013 at 12:07 PM, Gavin Andresen <gavinandresen@gmail.com>=
wrote:
>=20
> > Making it fee-per-kilobyte is a bad idea, in my opinion; users don't ca=
re
> > how many kilobytes their transactions are, and they will just be confus=
ed
> > 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.
> >
>=20
> 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?
>=20
> 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 becau=
se
> you intuitively expect that if you send 1 mBTC, then 1 mBTC will arrive t=
he
> 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.

Person-to-person payments are an *excellent* argument for keeping fees
visible to end-users; people will pay other people commonly in Bitcoin
and they will be very confused if those transactions act weirdly
differently than payments to merchants.


NAK on unconfirmed overrides - if something goes wrong even by accident
it just makes fixing the problem much harder and less intuitive.

--=20
'peter'[:-1]@petertodd.org
000000000000000f9102d27cfd61ea9e8bb324593593ca3ce6ba53153ff251b3

--rQ2U398070+RC21q
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBCAAGBQJSncJ1AAoJECSBQD2l8JH7tj8IAJlG4aMK/+HjvkfaXe6fSjOO
I45tCamYPJzpx6cCjVasPyIRILyli8upWCZebSPNp2Drbd0cFnWmAbuLvTL4XXSm
kaelzHBkAjtA8vvcTaX9zl4/Eh5ingXXRWHOt2LctYmN9amxS+S63hg8hQjTsq6m
0ASOKBKLkDYLuopROwxt5ZtnAz2EyWYilYRGEIx7plKFmH1zIl785VPz7PvUyeRE
s1fwKBF/F4QCugzNePtGJL00YKCq3V+sy6m1vRBRg88Y8ZbVzYj9I3Nihi6V0TVk
4hIIJKUaQ90cLC4xeOfz6Hc8EQfq88v2jEa1pF1ZIi4iBQjjJ7mtuHopiMFCFlI=
=6uVK
-----END PGP SIGNATURE-----

--rQ2U398070+RC21q--