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
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <btcdev@quinnharris.me>) id 1VnrBY-0006Ti-9l
for bitcoin-development@lists.sourceforge.net;
Tue, 03 Dec 2013 14:42:48 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of quinnharris.me
designates 67.223.164.214 as permitted sender)
client-ip=67.223.164.214; envelope-from=btcdev@quinnharris.me;
helo=fza.durangomail.com;
Received: from fza.durangomail.com ([67.223.164.214])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1VnrBV-0007Gm-P4 for bitcoin-development@lists.sourceforge.net;
Tue, 03 Dec 2013 14:42:48 +0000
Received: from localhost (localhost [127.0.0.1])
by fza.durangomail.com (Postfix) with ESMTP id A702B1E2240
for <bitcoin-development@lists.sourceforge.net>;
Tue, 3 Dec 2013 07:42:39 -0700 (MST)
Received: from fza.durangomail.com ([127.0.0.1])
by localhost (fza.durangomail.com [127.0.0.1]) (amavisd-new, port 10032)
with ESMTP id z21cfgmAtPfT
for <bitcoin-development@lists.sourceforge.net>;
Tue, 3 Dec 2013 07:42:38 -0700 (MST)
Received: from localhost (localhost [127.0.0.1])
by fza.durangomail.com (Postfix) with ESMTP id D7B921E2242
for <bitcoin-development@lists.sourceforge.net>;
Tue, 3 Dec 2013 07:42:37 -0700 (MST)
DKIM-Filter: OpenDKIM Filter v2.8.4 fza.durangomail.com D7B921E2242
X-Virus-Scanned: amavisd-new at fza.durangomail.com
Received: from fza.durangomail.com ([127.0.0.1])
by localhost (fza.durangomail.com [127.0.0.1]) (amavisd-new, port 10026)
with ESMTP id 2I-sb-cf_ZNs
for <bitcoin-development@lists.sourceforge.net>;
Tue, 3 Dec 2013 07:42:37 -0700 (MST)
Received: from [192.168.1.200] (186-107-99-134.baf.movistar.cl
[186.107.99.134])
by fza.durangomail.com (Postfix) with ESMTPSA id 3B2F91E2240
for <bitcoin-development@lists.sourceforge.net>;
Tue, 3 Dec 2013 07:42:37 -0700 (MST)
Message-ID: <529DEDDB.1090108@quinnharris.me>
Date: Tue, 03 Dec 2013 11:42:35 -0300
From: Quinn Harris <btcdev@quinnharris.me>
User-Agent: Mozilla/5.0 (X11; Linux i686;
rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
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>
In-Reply-To: <CANEZrP2PrhtFRPK4dSDFeu9iauqt_WJzCMrr+ynbAPRMBbDcOQ@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------060805030306030803070402"
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 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: doubleclick.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: 1VnrBV-0007Gm-P4
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 14:42:48 -0000
This is a multi-part message in MIME format.
--------------060805030306030803070402
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
The merchant wants to include a fee to ensure the transaction is
confirmed which is dependent on the fee per kilobyte, but they don't
want to pay unexpectedly high fees. So what about including a
min_fee_per_kilobyte and a max_fee in PaymentDetails describing what
fees the merchant will pay. The sender would be expected to respect the
min_fee_per_kilobyte but if the result exceeds max_fee the sender would
be agreeing to pay the extra fee (exterior fees). The sender might also
agree to pay fees in excess of min_fee_per_kilobyte.
The sender would deduct the interior or merchant fees from the first output.
The UI could show the payment "price" which would match the sum of
original outputs. It would show the merchant fees (interior) and sender
fees (exterior) if there are any. The UI should always show fees so
users learn to expect them for all transactions.
This should allow the merchant to pay fees in most cases while not
having to pay excessive fees if the sender wants to use some large
transaction. If max_fee is 0 the sender would be expected to pay all fees.
On 12/03/2013 10:20 AM, Mike Hearn wrote:
> On Tue, Dec 3, 2013 at 12:57 PM, Taylor Gerring
> <taylor.gerring@gmail.com <mailto: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).
>
>
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--------------060805030306030803070402
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">The merchant wants to include a fee to
ensure the transaction is confirmed which is dependent on the fee
per kilobyte, but they don't want to pay unexpectedly high fees.
So what about including a min_fee_per_kilobyte and a max_fee in
PaymentDetails describing what fees the merchant will pay. The
sender would be expected to respect the min_fee_per_kilobyte but
if the result exceeds max_fee the sender would be agreeing to pay
the extra fee (exterior fees). The sender might also agree to pay
fees in excess of min_fee_per_kilobyte.<br>
<br>
The sender would deduct the interior or merchant fees from the
first output.<br>
<br>
The UI could show the payment "price" which would match the sum of
original outputs. It would show the merchant fees (interior) and
sender fees (exterior) if there are any. The UI should always
show fees so users learn to expect them for all transactions. <br>
<br>
This should allow the merchant to pay fees in most cases while not
having to pay excessive fees if the sender wants to use some large
transaction. If max_fee is 0 the sender would be expected to pay
all fees.<br>
<br>
On 12/03/2013 10:20 AM, Mike Hearn wrote:<br>
</div>
<blockquote
cite="mid:CANEZrP2PrhtFRPK4dSDFeu9iauqt_WJzCMrr+ynbAPRMBbDcOQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Tue, Dec 3, 2013 at 12:57 PM,
Taylor Gerring <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:taylor.gerring@gmail.com" target="_blank">taylor.gerring@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div class="im">
<div><span style="color:rgb(34,34,34)">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.</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="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div class="im">
<div><span style="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’m 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="gmail_extra"><br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
<a class="moz-txt-link-freetext" href="http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk">http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk</a></pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Bitcoin-development mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a>
</pre>
</blockquote>
<br>
</body>
</html>
--------------060805030306030803070402--
|
