public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Jeremy Spilman" <jeremy@taplink•co>
To: "Mike Hearn" <mike@plan99•net>,
	"Gavin Andresen" <gavinandresen@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Floating fees and SPV clients
Date: Tue, 03 Dec 2013 17:45:44 -0800	[thread overview]
Message-ID: <op.w7jnreqwyldrnw@laptop-air.hsd1.ca.comcast.net> (raw)
In-Reply-To: <CABsx9T322nCvynRCL6Mb9C0f5EuJSfMDTSGiU+_JsYoSCb=_kQ@mail.gmail.com>

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




  parent reply	other threads:[~2013-12-04  3:11 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-01 11:51 Mike Hearn
2013-12-01 12:15 ` Andreas Schildbach
2013-12-01 13:41   ` Mike Hearn
2013-12-01 16:50     ` Andreas Schildbach
2013-12-01 17:19       ` Mike Hearn
2013-12-01 17:40         ` Andreas Schildbach
2013-12-01 17:52           ` Mike Hearn
2013-12-01 18:12         ` Peter Todd
2013-12-01 18:18           ` Mike Hearn
2013-12-01 18:37             ` Peter Todd
2013-12-02 13:54         ` Patrick Mead
2013-12-02 14:33           ` Mike Hearn
2013-12-02 14:37             ` Jeff Garzik
2013-12-02 14:44               ` Mike Hearn
2013-12-02 14:47                 ` Jeff Garzik
2013-12-03  1:40                 ` Gavin Andresen
2013-12-03 10:06                   ` Mike Hearn
2013-12-03 10:36                     ` Drak
2013-12-03 10:45                       ` Mike Hearn
2013-12-03 11:04                         ` Drak
2013-12-03 11:07                     ` Gavin Andresen
2013-12-03 11:29                       ` Mike Hearn
2013-12-03 11:37                         ` Peter Todd
2013-12-03 11:41                         ` Gavin Andresen
2013-12-03 11:46                           ` Mike Hearn
2013-12-03 11:54                             ` Gavin Andresen
2013-12-03 12:05                             ` Drak
2013-12-03 11:57                         ` Taylor Gerring
2013-12-03 12:07                           ` Peter Todd
2013-12-03 13:20                             ` Jamie McNaught
2013-12-03 13:20                           ` Mike Hearn
2013-12-03 13:48                             ` Taylor Gerring
2013-12-03 13:54                               ` Mike Hearn
2013-12-03 14:42                             ` Quinn Harris
2013-12-04  1:45                       ` Jeremy Spilman [this message]
2013-12-04 10:40                         ` Mike Hearn
2013-12-04 10:57                           ` Peter Todd
2013-12-04 11:09                             ` Mike Hearn
2013-12-04 13:06                               ` Peter Todd
2013-12-04 13:48                                 ` Mike Hearn
2013-12-04 21:51                                   ` Peter Todd
2013-12-03 11:03                   ` Peter Todd
2013-12-03 11:09                     ` Drak
2013-12-03 11:33                       ` Peter Todd
2013-12-04  5:50                   ` kjj
2013-12-03 11:31 ` Peter Todd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=op.w7jnreqwyldrnw@laptop-air.hsd1.ca.comcast.net \
    --to=jeremy@taplink$(echo .)co \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    --cc=gavinandresen@gmail$(echo .)com \
    --cc=mike@plan99$(echo .)net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox