path: root/a3/e2e058cd42a502c438d501d6519226df252d54

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 <taylor.gerring@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
	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 <multiple recipients>
	(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 <taylor.gerring@gmail.com>
In-Reply-To: <CANEZrP2PrhtFRPK4dSDFeu9iauqt_WJzCMrr+ynbAPRMBbDcOQ@mail.gmail.com>
Date: Tue, 3 Dec 2013 14:48:58 +0100
Message-Id: <2176080D-CE85-422C-A937-A1849F584C51@gmail.com>
References: <CANEZrP3tGdFh6oG5fbX9JbU6sYbbex1cq=0tQB-0A4aDrdbXrQ@mail.gmail.com>
	<l7f97u$jdg$1@ger.gmane.org>
	<5E4597E4-C1C7-4536-8CF0-82EDD7715DAB@plan99.net>
	<l7fpbn$hf6$1@ger.gmane.org>
	<39921E12-B411-4430-9D56-04F53906B109@plan99.net>
	<CAGLkj4C9fyAX1CnB0oZH3BwLRQp6WOo9kLUqDhRUSA6y3LxYvg@mail.gmail.com>
	<CANEZrP1C=Hc-3f-rqQ+wYrPn-eUj52HjN+qRQdJMWvnP+dkK=Q@mail.gmail.com>
	<CAJHLa0P_uzEQ2OG2FTXyD2Zw4RzujNBxKbKD04CSS1sLNpLUUQ@mail.gmail.com>
	<CANEZrP2hf2853w9f4__Ji9v3eRRU0u6pEzPxAmFN+iH067gtnA@mail.gmail.com>
	<CABsx9T3NQDPL6=pz5BD5DsP0qh0x3LJOCj2H3yY5tzL2_DivGA@mail.gmail.com>
	<CANEZrP1PLKemiUEgMJRGdiZXt7o=0_5fhLKYY0x3Ngb_iEm+2w@mail.gmail.com>
	<CABsx9T322nCvynRCL6Mb9C0f5EuJSfMDTSGiU+_JsYoSCb=_kQ@mail.gmail.com>
	<CANEZrP0P9NTJXs22K8-4hnLkxV7Uo+tjvWKJ8msgxiFgJW6xvg@mail.gmail.com>
	<05CEDEB4-BA29-4ED3-8CFC-D3504727DB4D@gmail.com>
	<CANEZrP2PrhtFRPK4dSDFeu9iauqt_WJzCMrr+ynbAPRMBbDcOQ@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
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 <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <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.
>=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

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><br><div><div>On Dec 3, 2013, at 2:20 PM, Mike Hearn =
&lt;<a href=3D"mailto:mike@plan99.net">mike@plan99.net</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote">On Tue, Dec 3, 2013 at 12:57 PM, Taylor Gerring =
<span dir=3D"ltr">&lt;<a href=3D"mailto:taylor.gerring@gmail.com" =
target=3D"_blank">taylor.gerring@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
style=3D"word-wrap:break-word"><div class=3D"im"><div><span =
style=3D"color:rgb(34,34,34)">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.</span></div>
</div></div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Maybe we need new terminology for this. <i>Interior =
fees</i> for included in the price/receiver pays and <i>exterior =
fees</i> for excluded from the price/sender =
pays?</div><div><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style=3D"word-wrap:break-word"><div class=3D"im"><div><span =
style=3D"color:rgb(34,34,34)">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.</span></div>
</div></div></blockquote><div><br></div><div>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).</div>
</div><br></div><div class=3D"gmail_extra"><br></div></div>
</blockquote></div><br><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Taylor</div><div><br></div></body></html>=

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