From: Mike Hearn <mike@plan99•net>
To: Taylor Gerring <taylor.gerring@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Floating fees and SPV clients
Date: Tue, 3 Dec 2013 14:20:36 +0100 [thread overview]
Message-ID: <CANEZrP2PrhtFRPK4dSDFeu9iauqt_WJzCMrr+ynbAPRMBbDcOQ@mail.gmail.com> (raw)
In-Reply-To: <05CEDEB4-BA29-4ED3-8CFC-D3504727DB4D@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2493 bytes --]
On Tue, Dec 3, 2013 at 12:57 PM, Taylor Gerring <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).
[-- Attachment #2: Type: text/html, Size: 3295 bytes --]
next prev parent reply other threads:[~2013-12-03 13:20 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 [this message]
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
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=CANEZrP2PrhtFRPK4dSDFeu9iauqt_WJzCMrr+ynbAPRMBbDcOQ@mail.gmail.com \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=taylor.gerring@gmail$(echo .)com \
/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