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-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Vo2rv-00069c-8y for bitcoin-development@lists.sourceforge.net; Wed, 04 Dec 2013 03:11:19 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of taplink.co designates 50.117.27.232 as permitted sender) client-ip=50.117.27.232; envelope-from=jeremy@taplink.co; helo=mail.taplink.co; Received: from mail.taplink.co ([50.117.27.232]) by sog-mx-2.v43.ch3.sourceforge.com with smtp (Exim 4.76) id 1Vo2ru-0005Yu-H4 for bitcoin-development@lists.sourceforge.net; Wed, 04 Dec 2013 03:11:19 +0000 Received: from laptop-air.hsd1.ca.comcast.net ([192.168.168.135]) by mail.taplink.co ; Tue, 3 Dec 2013 17:46:52 -0800 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Mike Hearn" , "Gavin Andresen" References: <5E4597E4-C1C7-4536-8CF0-82EDD7715DAB@plan99.net> <39921E12-B411-4430-9D56-04F53906B109@plan99.net> Date: Tue, 03 Dec 2013 17:45:44 -0800 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Jeremy Spilman" Organization: TapLink Message-ID: In-Reply-To: User-Agent: Opera Mail/1.0 (Win32) oclient: 192.168.168.135#jeremy@taplink.co#465 X-Spam-Score: -1.6 (-) 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 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 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: taplink.co] -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Vo2ru-0005Yu-H4 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 03:11:19 -0000 allowfee: > 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. minfee: > Pay at least minfee satoshis in transaction fees. Wallet software should > add minfee to the amount the user authorizes and pays, and >include at > least minfee in the transaction created to pay miner's transaction fees. > Wallet software may request that the user pays more, if >it must create > a complex transaction or judges that minfee is not sufficient for the > transaction to be accepted by the network.. > Thanks for the draft specs Gavin. Very clear and precise. Personally I think 'allowfee' is more useful than 'minfee'. The 'allowfee' tells me something very useful and definitive about what the merchant will let me do when making payment, and if the merchant chooses 'allowfee' intelligently, they can provide real value to their customers without exposing them to undue risk. A 'minfee' field on the other hand, is just a data point for the wallet software to consider, and likely to be noisy enough that wallets will tend to ignore it. (e.g. like Drak's example of Gox's 0.001 fee) The sender's wallet software will always be free to choose the fee, and paying less than the 'allowfee' or 'minfee' can still get a TX included in the next block. I think of the PaymentRequest is a part of the purchase contract. If a payer transmits a transaction before 'expires' but with less than 'minfee', which gets included in the next block, have they failed to meet the terms of payment? If there is some time criticality, for example to reduce exchange rate risk, then a wallet might need to choose a higher fee to ensure the transaction clears in time. Instead of 'minfee' I'm thinking it would be more appropriate to communicate this using the existing 'expires' field -- in other words, let the merchant express what their requirement is, not tell the wallet how to achieve it. In the case of a transaction with too-low fee, either the payer can double-spend with a higher fee, or wait longer for the transaction to make it into a block. If it hits the blockchain before the 'expires' time, then the merchant should have no standing to refute it, regardless of the amount of fees paid. A refund comes into play if a payer reduced the total amount in excess of an agreed upon 'allowfee', or if the transaction doesn't hit the blockchain until after 'expires'. It should be clear in these cases that payer would end up eating the fees in both directions. But then, what if a wallet pays the 'minfee' and broadcasts 1 block before 'expires' but the payment DOESN'T make the block? Is the merchant liable for too-slow transactions due to their own insufficient 'minfee' value? So I see 'allowfee' as extremely useful, but 'minfee' as somewhat problematic. Thanks, Jeremy