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 ------------------------------------------------------------------------------ Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
