From mboxrd@z Thu Jan 1 00:00:00 1970 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 1Vnpu6-0000qj-Kv for bitcoin-development@lists.sourceforge.net; Tue, 03 Dec 2013 13:20:42 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.175 as permitted sender) client-ip=209.85.214.175; envelope-from=mh.in.england@gmail.com; helo=mail-ob0-f175.google.com; Received: from mail-ob0-f175.google.com ([209.85.214.175]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Vnpu5-0002Lm-LW for bitcoin-development@lists.sourceforge.net; Tue, 03 Dec 2013 13:20:42 +0000 Received: by mail-ob0-f175.google.com with SMTP id uz6so14220132obc.6 for ; Tue, 03 Dec 2013 05:20:36 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.182.153.226 with SMTP id vj2mr60351449obb.26.1386076836250; Tue, 03 Dec 2013 05:20:36 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.76.3.134 with HTTP; Tue, 3 Dec 2013 05:20:36 -0800 (PST) In-Reply-To: <05CEDEB4-BA29-4ED3-8CFC-D3504727DB4D@gmail.com> References: <5E4597E4-C1C7-4536-8CF0-82EDD7715DAB@plan99.net> <39921E12-B411-4430-9D56-04F53906B109@plan99.net> <05CEDEB4-BA29-4ED3-8CFC-D3504727DB4D@gmail.com> Date: Tue, 3 Dec 2013 14:20:36 +0100 X-Google-Sender-Auth: 6a-GitigOtEChW6a6FvtLHpwJ6w Message-ID: From: Mike Hearn To: Taylor Gerring Content-Type: multipart/alternative; boundary=089e013d0dc074ccd004eca12912 X-Spam-Score: -0.5 (/) 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 (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 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: 1Vnpu5-0002Lm-LW 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:20:42 -0000 --089e013d0dc074ccd004eca12912 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Dec 3, 2013 at 12:57 PM, Taylor Gerring w= rote: > Why should there be two classes of transactions? Where does paying a loca= l > business at a farmer=E2=80=99s stand lie in that realm? Transactions shou= ld 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=E2=80=99m of th= e 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). --089e013d0dc074ccd004eca12912 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, 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=E2= =80=99s stand lie in that realm? Transactions should work the same regardle= ss of who is on the receiving end.

Lots and lots of people are ps= ychologically trained to expect that they pay the sticker price for things.= Yes in recent times some places have started to show additional fees for u= sing credit cards, but only as a way to try and push people onto cheaper fo= rms of payment, not because customers love surcharges. It's for that re= ason that many merchants don't do this, even when they could - I pay fo= r things with Maestro Debit all the time and I don't think I've eve= r seen a surcharge. That system obviously has costs, but they're includ= ed.

This is just a basic cultural thing - when I buy someth= ing from a shop, the social expectation is that the seller should be gratef= ul 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 weeken= d and what he receives is less than 10 bucks, he would probably feel annoye= d - if I owe him 10 bucks then I owe him 10 bucks and it's my job the c= over the fees. That's why PayPal makes sender pay fees in that case.

Maybe we need new terminology for this. Interior fee= s 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 t= errible job of presenting the information to the user. In Hive Wallet, I=E2= =80=99m of the opinion that we should inform the user in an intuitive way t= o let them make an informed decision.

Have you thought through the U= I for that in detail? How exactly are you going to explain the fee structur= e? 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 th= e way to the other end and pay no fees at all? Is the merchant going to ref= use to take my payment? Gavin just said that's not possible with Bitcoi= n-Qt. I'm thinking for bitcoinj I might go in a slightly different dire= ction and not broadcast payments submitted via the payment protocol (and de= finitely not have one wire tx pay multiple payment requests simultaneously,= at least not for consumer wallets).


--089e013d0dc074ccd004eca12912--