summaryrefslogtreecommitdiff
path: root/6d/fe23c5c4a95050f1eaae68da817740685103a0
blob: d9f22f1770719e6a5122b1cb0767172da945d4de (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <taylor.gerring@gmail.com>) id 1VnodJ-0001SP-KC
	for bitcoin-development@lists.sourceforge.net;
	Tue, 03 Dec 2013 11:59:17 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.215.176 as permitted sender)
	client-ip=209.85.215.176; envelope-from=taylor.gerring@gmail.com;
	helo=mail-ea0-f176.google.com; 
Received: from mail-ea0-f176.google.com ([209.85.215.176])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1VnodH-0007H9-CU
	for bitcoin-development@lists.sourceforge.net;
	Tue, 03 Dec 2013 11:59:17 +0000
Received: by mail-ea0-f176.google.com with SMTP id h14so9727179eaj.7
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 03 Dec 2013 03:59:09 -0800 (PST)
X-Received: by 10.14.174.71 with SMTP id w47mr26923eel.113.1386071949080;
	Tue, 03 Dec 2013 03:59:09 -0800 (PST)
Received: from [192.168.1.157] ([82.84.138.236])
	by mx.google.com with ESMTPSA id a45sm81611710eem.6.2013.12.03.03.59.07
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 03 Dec 2013 03:59:08 -0800 (PST)
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_90B85D20-1FD8-4B03-A7A1-33B4072408B7"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Taylor Gerring <taylor.gerring@gmail.com>
In-Reply-To: <CANEZrP0P9NTJXs22K8-4hnLkxV7Uo+tjvWKJ8msgxiFgJW6xvg@mail.gmail.com>
Date: Tue, 3 Dec 2013 12:57:23 +0100
Message-Id: <05CEDEB4-BA29-4ED3-8CFC-D3504727DB4D@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>
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: 1VnodH-0007H9-CU
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 11:59:17 -0000


--Apple-Mail=_90B85D20-1FD8-4B03-A7A1-33B4072408B7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Dec 3, 2013, at 12:29 PM, Mike Hearn <mike@plan99.net> wrote:

> It may be acceptable that receivers don't always receive exactly what =
they requested, at least for person-to-business transactions.  For =
person-to-person transactions of course any fee at all is confusing =
because you intuitively expect that if you send 1 mBTC, then 1 mBTC will =
arrive the other end. I wonder if we'll end up in a world where buying =
things from shops involves paying fees, and (more occasional?) =
person-to-person transactions tend to be free and people just understand =
that the money isn't going to be spendable for a while.


> person-to-business transactions.  For person-to-person transactions
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.

> any fee at all is confusing because you intuitively expect that if you =
send 1 mBTC, then 1 mBTC will arrive the other end
The paradigm of sending money has an explicit cost is not new... I think =
people are used to Western Union/PayPal and associated fees, no?  It=92s =
okay to have a fee if it=92s reasonable, so let=92s inform the user what =
the estimated cost is to send a transaction in a reasonable amount of =
time.

>  wonder if we'll end up in a world where buying things from shops =
involves paying fees
I stayed in a hotel for the first night here here in Milan, and there =
was an (anticipated) surcharge for the use of credit over cash. Again, =
nothing new here.


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.=

--Apple-Mail=_90B85D20-1FD8-4B03-A7A1-33B4072408B7
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;"><div><br></div><div><div>On Dec 3, 2013, at 12:29 =
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"><span =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px; float: none; display: inline =
!important;">It may be acceptable that receivers don't always receive =
exactly what they requested, at least for person-to-business =
transactions. &nbsp;For person-to-person transactions of course any fee =
at all is confusing because you intuitively expect that if you send 1 =
mBTC, then 1 mBTC will arrive the other end. I wonder if we'll end up in =
a world where buying things from shops involves paying fees, and (more =
occasional?) person-to-person transactions tend to be free and people =
just understand that the money isn't going to be spendable for a =
while.</span></blockquote></div><br><div><br></div><div>&gt; =
person-to-business transactions. &nbsp;For person-to-person =
transactions</div><div>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.</div><div><br></div><div>&gt;&nbsp;any fee at all is =
confusing because you intuitively expect that if you send 1 mBTC, then 1 =
mBTC will arrive the other end</div><div>The paradigm of sending money =
has an explicit cost is not new... I think people are used to Western =
Union/PayPal and associated fees, no? &nbsp;It=92s okay to have a fee if =
it=92s reasonable, so let=92s inform the user what the estimated cost is =
to send a transaction in a reasonable amount of =
time.</div><div><br></div><div>&gt; &nbsp;wonder if we'll end up in a =
world where buying things from shops involves paying fees</div><div>I =
stayed in a hotel for the first night here here in Milan, and there was =
an (anticipated) surcharge for the use of credit over cash. Again, =
nothing new here.</div><div><br></div><div><br></div><div>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.</div></body></html>=

--Apple-Mail=_90B85D20-1FD8-4B03-A7A1-33B4072408B7--