Re: [Bitcoin-development] Floating fees and SPV clients

[Quinn Harris <btcdev@quinnharris.me>]

[-- Attachment #1: Type: text/plain, Size: 4426 bytes --]

The merchant wants to include a fee to ensure the transaction is 
confirmed which is dependent on the fee per kilobyte, but they don't 
want to pay unexpectedly high fees. So what about including a 
min_fee_per_kilobyte and a max_fee in PaymentDetails describing what 
fees the merchant will pay.  The sender would be expected to respect the 
min_fee_per_kilobyte but if the result exceeds max_fee the sender would 
be agreeing to pay the extra fee (exterior fees).  The sender might also 
agree to pay fees in excess of min_fee_per_kilobyte.

The sender would deduct the interior or merchant fees from the first output.

The UI could show the payment "price" which would match the sum of 
original outputs.  It would show the merchant fees (interior) and sender 
fees (exterior) if there are any.  The UI should always show fees so 
users learn to expect them for all transactions.

This should allow the merchant to pay fees in most cases while not 
having to pay excessive fees if the sender wants to use some large 
transaction.  If max_fee is 0 the sender would be expected to pay all fees.

On 12/03/2013 10:20 AM, Mike Hearn wrote:
> On Tue, Dec 3, 2013 at 12:57 PM, Taylor Gerring 
> <taylor.gerring@gmail.com <mailto:taylor.gerring@gmail.com>> wrote:
>
>     Why should there be two classes of transactions? Where does paying
>     a local business at a farmer's stand lie in that realm?
>     Transactions should work the same regardless of who is on the
>     receiving end.
>
>
> Lots and lots of people are psychologically trained to expect that 
> they pay the sticker price for things. Yes in recent times some places 
> have started to show additional fees for using credit cards, but only 
> as a way to try and push people onto cheaper forms of payment, not 
> because customers love surcharges. It's for that reason that many 
> merchants don't do this, even when they could - I pay for things with 
> Maestro Debit all the time and I don't think I've ever seen a 
> surcharge. That system obviously has costs, but they're included.
>
> This is just a basic cultural thing - when I buy something from a 
> shop, the social expectation is that the seller should be grateful for 
> receiving my money. "The customer is always right". When I send money 
> to a friend, the social expectation is different. If my friend said, 
> hey Mike, could you send me that 10 bucks you owe me from last weekend 
> and what he receives is less than 10 bucks, he would probably feel 
> annoyed - if I owe him 10 bucks then I owe him 10 bucks and it's my 
> job the cover the fees. That's why PayPal makes sender pay fees in 
> that case.
>
> Maybe we need new terminology for this. /Interior fees/ for included 
> in the price/receiver pays and /exterior fees/ for excluded from the 
> price/sender pays?
>
>     Fees are only confusing because existing clients do a terrible job
>     of presenting the information to the user. In Hive Wallet, I'm of
>     the opinion that we should inform the user in an intuitive way to
>     let them make an informed decision.
>
>
> Have you thought through the UI for that in detail? How exactly are 
> you going to explain the fee structure? Let the user pick the number 
> of blocks they need to wait for? What's a block? Why should I care? 
> Why shouldn't I just set the slider all the way to the other end and 
> pay no fees at all? Is the merchant going to refuse to take my 
> payment? Gavin just said that's not possible with Bitcoin-Qt. I'm 
> thinking for bitcoinj I might go in a slightly different direction and 
> not broadcast payments submitted via the payment protocol (and 
> definitely not have one wire tx pay multiple payment requests 
> simultaneously, at least not for consumer wallets).
>
>
>
>
> ------------------------------------------------------------------------------
> 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


[-- Attachment #2: Type: text/html, Size: 7356 bytes --]