Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Vo5MD-0003t4-1n for bitcoin-development@lists.sourceforge.net; Wed, 04 Dec 2013 05:50:45 +0000 X-ACL-Warn: Received: from serv.jerviss.org ([12.47.47.47] helo=inana.jerviss.org) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1Vo5MB-0007ZC-Q2 for bitcoin-development@lists.sourceforge.net; Wed, 04 Dec 2013 05:50:45 +0000 Received: from [10.8.2.254] ([192.151.168.109]) (username: kjj authenticated by PLAIN symmetric_key_bits=0) by inana.jerviss.org (8.13.6/8.12.11) with ESMTP id rB45oWm3005610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Dec 2013 23:50:36 -0600 Message-ID: <529EC2A3.7080602@jerviss.org> Date: Tue, 03 Dec 2013 23:50:27 -0600 From: kjj User-Agent: Mozilla/5.0 (Windows NT 5.2; WOW64; rv:25.0) Gecko/20100101 SeaMonkey/2.22.1 MIME-Version: 1.0 To: Gavin Andresen References: <5E4597E4-C1C7-4536-8CF0-82EDD7715DAB@plan99.net> <39921E12-B411-4430-9D56-04F53906B109@plan99.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010805050402090201000609" Received-SPF: pass (inana.jerviss.org: 192.151.168.109 is authenticated by a trusted mechanism) X-Spam-Score: -0.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: doubleclick.net] -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1Vo5MB-0007ZC-Q2 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: Wed, 04 Dec 2013 05:50:45 -0000 This is a multi-part message in MIME format. --------------010805050402090201000609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit After reading all 99 messages in this thread, I think allowfee is just about perfect. It effectively lets merchants to give an allowance against the purchase price for network fees, if they choose. It is still up to the sender (and/or the sender's software) to get the fees right. Sometimes the sender will need to pay more fees than allowed, and sometimes the sender will need to pay less. We can't solve the fee problem, in general. I'm not sure that we can even define it properly. But this is something that we can do, that will be useful at least occasionally, and that will cause no harm the rest of the time. P.S. Clever senders can use this to defrag their wallets. Who wants to write the patch for that? Gavin Andresen wrote: > On Tue, Dec 3, 2013 at 12:44 AM, Mike Hearn > wrote: > > 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. > > > Lets bang out a merchant-pays-fee extension. > > How about: > > SPEC: > > optional uint64 allowfee tag number=1000 > > 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. > > :ENDSPEC > > Rationale: we don't want wallet software giving users discounts-- > sending transactions that are amount-allowfee without paying any fee. > We also want to allow users to pay MORE in fees, if they need to > (fragmented wallet, maybe, or big CoinJoin transaction) or decide to. > > > PS: I think there was also consensus that the BIP72 request=... > should be shortened to just r=... (save 6 chars in QR codes). Unless > somebody objects, I'll change the BIP and the reference implementation > code to make it so... > > -- > -- > Gavin Andresen > > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk > > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development --------------010805050402090201000609 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
After reading all 99 messages in this thread, I think allowfee is just about perfect.

It effectively lets merchants to give an allowance against the purchase price for network fees, if they choose.  It is still up to the sender (and/or the sender's software) to get the fees right.  Sometimes the sender will need to pay more fees than allowed, and sometimes the sender will need to pay less.

We can't solve the fee problem, in general.  I'm not sure that we can even define it properly.  But this is something that we can do, that will be useful at least occasionally, and that will cause no harm the rest of the time.

P.S.  Clever senders can use this to defrag their wallets.  Who wants to write the patch for that?

Gavin Andresen wrote:
On Tue, Dec 3, 2013 at 12:44 AM, Mike Hearn <mike@plan99.net> wrote:
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.

Lets bang out a merchant-pays-fee extension.

How about:

SPEC:

    optional uint64 allowfee    tag number=1000

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.

:ENDSPEC

Rationale: we don't want wallet software giving users discounts-- sending transactions that are amount-allowfee without paying any fee.  We also want to allow users to pay MORE in fees, if they need to (fragmented wallet, maybe, or big CoinJoin transaction) or decide to.


PS: I think there was also consensus that the BIP72  request=...   should be shortened to just r=... (save 6 chars in QR codes).  Unless somebody objects, I'll change the BIP and the reference implementation code to make it so...

--
--
Gavin Andresen



------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk


_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--------------010805050402090201000609--