Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VnqLZ-0002jo-BN for bitcoin-development@lists.sourceforge.net; Tue, 03 Dec 2013 13:49:05 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.174 as permitted sender) client-ip=209.85.215.174; envelope-from=taylor.gerring@gmail.com; helo=mail-ea0-f174.google.com; Received: from mail-ea0-f174.google.com ([209.85.215.174]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VnqLY-0003rb-8j for bitcoin-development@lists.sourceforge.net; Tue, 03 Dec 2013 13:49:05 +0000 Received: by mail-ea0-f174.google.com with SMTP id b10so9901660eae.33 for ; Tue, 03 Dec 2013 05:48:57 -0800 (PST) X-Received: by 10.15.35.67 with SMTP id f43mr2856475eev.100.1386078537889; Tue, 03 Dec 2013 05:48:57 -0800 (PST) Received: from [172.20.10.3] ([5.168.37.176]) by mx.google.com with ESMTPSA id h3sm57666879eem.15.2013.12.03.05.48.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Dec 2013 05:48:57 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_2E843629-DA83-4B6E-9329-2FEA074DE069" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Taylor Gerring In-Reply-To: Date: Tue, 3 Dec 2013 14:48:58 +0100 Message-Id: <2176080D-CE85-422C-A937-A1849F584C51@gmail.com> References: <5E4597E4-C1C7-4536-8CF0-82EDD7715DAB@plan99.net> <39921E12-B411-4430-9D56-04F53906B109@plan99.net> <05CEDEB4-BA29-4ED3-8CFC-D3504727DB4D@gmail.com> To: Mike Hearn X-Mailer: Apple Mail (2.1822) X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (taylor.gerring[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: plan99.net] 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1VnqLY-0003rb-8j Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Floating fees and SPV clients X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 13:49:05 -0000 --Apple-Mail=_2E843629-DA83-4B6E-9329-2FEA074DE069 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Dec 3, 2013, at 2:20 PM, Mike Hearn wrote: > On Tue, Dec 3, 2013 at 12:57 PM, Taylor Gerring = wrote: > Why should there be two classes of transactions? Where does paying a = local business at a farmer=92s stand lie in that realm? Transactions = should work the same regardless of who is on the receiving end. >=20 > 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. >=20 > 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. >=20 > 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? >=20 > Fees are only confusing because existing clients do a terrible job of = presenting the information to the user. In Hive Wallet, I=92m of the = opinion that we should inform the user in an intuitive way to let them = make an informed decision. >=20 > 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). >=20 >=20 Most of what you mentioned is entirely culture-dependant. In the = majority of North America, sales tax is calculated at the point of sale = on top of the advertised price. When my local government increases sales = taxes, we feel it BECAUSE we see it. Expose information in a digestible = way. Just because you don=92t instinctively know how to implement a UI = for varying sender fees doesn=92t mean that other wallets don=92t. Leave the fee structure alone. Instead, let=92s concentrate on how to = calculate an accurate assessment of what a reasonable fee is for = reliable service and let the software shake out the rest. Taylor --Apple-Mail=_2E843629-DA83-4B6E-9329-2FEA074DE069 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Dec 3, 2013, at 2:20 PM, Mike Hearn = <mike@plan99.net> = wrote:

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=92s 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=92m 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).



Most of what you mentioned is entirely = culture-dependant. In the majority of North America, sales tax is = calculated at the point of sale on top of the advertised price. When my = local government increases sales taxes, we feel it BECAUSE we see it. = Expose information in a digestible way. Just because you don=92t = instinctively know how to implement a UI for varying sender fees doesn=92t= mean that other wallets don=92t.

Leave the fee = structure alone. Instead, let=92s concentrate on how to calculate an = accurate assessment of what a reasonable fee is for reliable service and = let the software shake out the = rest.

Taylor

= --Apple-Mail=_2E843629-DA83-4B6E-9329-2FEA074DE069--