From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VnoIQ-0003uq-NI for bitcoin-development@lists.sourceforge.net; Tue, 03 Dec 2013 11:37:42 +0000 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; Received: from outmail148112.authsmtp.co.uk ([62.13.148.112]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1VnoIP-0005uQ-Ju for bitcoin-development@lists.sourceforge.net; Tue, 03 Dec 2013 11:37:42 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt9.authsmtp.com (8.14.2/8.14.2) with ESMTP id rB3BbYjE092812; Tue, 3 Dec 2013 11:37:34 GMT Received: from tilt (ge-19-102-21.service.infuturo.it [151.19.102.21]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id rB3BbSkU056185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 3 Dec 2013 11:37:33 GMT Date: Tue, 3 Dec 2013 06:37:25 -0500 From: Peter Todd To: Mike Hearn Message-ID: <20131203113725.GC12623@tilt> References: <39921E12-B411-4430-9D56-04F53906B109@plan99.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rQ2U398070+RC21q" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 4d6154d6-5c0f-11e3-b802-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdgEUHFAXAgsB AmUbWlVeU1p7Wmc7 ag9QcwRUfEtOXRto UVdMSlVNFUsqcx9z VH1FNxl3cQROfTBx YENiWj5fCEJ7cEIp RFNRRm1QeGZhPWMC AkhYdR5UcAFPdx8U a1UrBXRDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4lGjk1 WxEEEn0hEEAeDyw1 I1QdEmBUF0IQP0Mu KjMA X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 151.19.102.21/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: petertodd.org] -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1VnoIP-0005uQ-Ju Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Floating fees and SPV clients X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 11:37:42 -0000 --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 = 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--