From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Vnnly-0003gv-LX for bitcoin-development@lists.sourceforge.net; Tue, 03 Dec 2013 11:04:10 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.149.115 as permitted sender) client-ip=62.13.149.115; envelope-from=pete@petertodd.org; helo=outmail149115.authsmtp.co.uk; Received: from outmail149115.authsmtp.co.uk ([62.13.149.115]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Vnnlx-0004RL-Hd for bitcoin-development@lists.sourceforge.net; Tue, 03 Dec 2013 11:04:10 +0000 Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt12.authsmtp.com (8.14.2/8.14.2) with ESMTP id rB3B42RQ095813; Tue, 3 Dec 2013 11:04:02 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 rB3B3tJH070842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 3 Dec 2013 11:03:58 GMT Date: Tue, 3 Dec 2013 06:03:54 -0500 From: Peter Todd To: Gavin Andresen Message-ID: <20131203110354.GA6513@tilt> References: <5E4597E4-C1C7-4536-8CF0-82EDD7715DAB@plan99.net> <39921E12-B411-4430-9D56-04F53906B109@plan99.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 9d503904-5c0a-11e3-94fa-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdgEUHFAXAgsB AmUbWlVeUFl7WWM7 ag9QcwRUfEtOXRto UVdMSlVNFUsqcx9z BVpkKhl1dw1CejBx ZkNqWj5SCEF6dk99 RlNRRm1XeGZhPWMC WUQOJh5UcAFPdx8U a1N6AHBDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4lGjk1 WxEEEn0hEEAeDyw1 I1QdEmBUF0IQP0Mu KjMA X-Authentic-SMTP: 61633532353630.1024: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. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record 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: plan99.net] X-Headers-End: 1Vnnlx-0004RL-Hd 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:04:10 -0000 --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 03, 2013 at 11:40:35AM +1000, Gavin Andresen wrote: > On Tue, Dec 3, 2013 at 12:44 AM, Mike Hearn wrote: >=20 > > PPv1 doesn't have any notion of fee unfortunately. I suppose it could be > > added easily, but we also need to launch the existing feature set. > > >=20 > Lets bang out a merchant-pays-fee extension. >=20 > How about: >=20 > SPEC: >=20 > optional uint64 allowfee tag number=3D1000 >=20 > Allow up to allowfee satoshis to be deducted from the amount paid to be > used to pay Bitcoin network transaction fees. A wallet implementation must > not reduce the amount paid for fees more than allowfee, and transaction > fees must be equal to or greater than the amount reduced. Fees are per byte of tx data; call it allowfeeperkb, and given that fees are required - the merchant would really rather not waste up to about twice as much on fees for a child-pays-for-parent - it should be called requirefeeperkb. Back to your point, the merchant wants to limit total fees that have been deducted - 'allowfee' is still a good idea - but only in conjunction with specifying fee-per-kb requirements. UI once both are implemented is to not show anything in the default case, and explain to the user why they have to pay extra in the unusual case where they are spending a whole bunch of dust. --=20 'peter'[:-1]@petertodd.org 000000000000000f9102d27cfd61ea9e8bb324593593ca3ce6ba53153ff251b3 --FCuugMFkClbJLl1L Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJSnbqZAAoJECSBQD2l8JH734UH/3qAGI55zFVwl6H/v696exEG 7iy7muLkSg75JyMIRuNK80O1783VFuRNQjj84hLh7rUf42ju+douTsrJzasEgZXk zaicX4N16N16XjFjJZyXx6LyHFEitsTSgLA5pSxDN2dvVMXYl8KITmcHz2fyLOfN Z4ps3FRHSAOdw2uP1mn4V7gvNqRTKTkAuVnIMY35U6mRfLHaD5FPGx/skbCzsYWQ eyuvKf2lyCbtH10WvFI1swAxEp40nnYnixIf+GwozI4s+lvp6umS3/aqVju5UuFM 1xue6EBZ1YHAfM9HBXyy9qOM0eyT3j7wXCPc0PlSENLmYi8WVmG/aGyFu4SFeXk= =mlRG -----END PGP SIGNATURE----- --FCuugMFkClbJLl1L--