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; 
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
To: "Mike Hearn" <mike@plan99.net>, "Gavin Andresen" <gavinandresen@gmail.com>
References: <CANEZrP3tGdFh6oG5fbX9JbU6sYbbex1cq=0tQB-0A4aDrdbXrQ@mail.gmail.com>
	<l7f97u$jdg$1@ger.gmane.org>
	<5E4597E4-C1C7-4536-8CF0-82EDD7715DAB@plan99.net>
	<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>
Date: Tue, 03 Dec 2013 17:45:44 -0800
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: "Jeremy Spilman" <jeremy@taplink.co>
Organization: TapLink
Message-ID: <op.w7jnreqwyldrnw@laptop-air.hsd1.ca.comcast.net>
In-Reply-To: <CABsx9T322nCvynRCL6Mb9C0f5EuJSfMDTSGiU+_JsYoSCb=_kQ@mail.gmail.com>
User-Agent: Opera Mail/1.0 (Win32)
oclient: 192.168.168.135#jeremy@taplink.co#465
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Floating fees and SPV clients
Precedence: list

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