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
|
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 <mh.in.england@gmail.com>) id 1VnUZO-00027t-00
for bitcoin-development@lists.sourceforge.net;
Mon, 02 Dec 2013 14:33:54 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.179 as permitted sender)
client-ip=209.85.214.179; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f179.google.com;
Received: from mail-ob0-f179.google.com ([209.85.214.179])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VnUZL-0005rS-TX
for bitcoin-development@lists.sourceforge.net;
Mon, 02 Dec 2013 14:33:53 +0000
Received: by mail-ob0-f179.google.com with SMTP id wm4so12636233obc.24
for <bitcoin-development@lists.sourceforge.net>;
Mon, 02 Dec 2013 06:33:46 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.182.243.138 with SMTP id wy10mr199059obc.83.1385994826522;
Mon, 02 Dec 2013 06:33:46 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.3.134 with HTTP; Mon, 2 Dec 2013 06:33:46 -0800 (PST)
In-Reply-To: <CAGLkj4C9fyAX1CnB0oZH3BwLRQp6WOo9kLUqDhRUSA6y3LxYvg@mail.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>
Date: Mon, 2 Dec 2013 15:33:46 +0100
X-Google-Sender-Auth: ikzNieEMs6utonbHq2umfTNJoAI
Message-ID: <CANEZrP1C=Hc-3f-rqQ+wYrPn-eUj52HjN+qRQdJMWvnP+dkK=Q@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Patrick Mead <patrick@meadia.com.au>
Content-Type: multipart/alternative; boundary=001a11c2a1204ba8b304ec8e11f7
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
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.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: 1VnUZL-0005rS-TX
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: Mon, 02 Dec 2013 14:33:54 -0000
--001a11c2a1204ba8b304ec8e11f7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Right, as I said earlier:
"The payment protocol at least would need some notion of fee, or possibly
(better?) the ability for a recipient to specify some inputs as well as
some outputs."
Having thought about it a bit more, I think it's better to just have a fee
field that lets the receiver request the sender to attach the given fee.
The outputs would have less value associated with them, so effectively the
seller folds the fee into the price. If the seller is charging a round
price like 1 mBTC, the user sees "1 mBTC" as the price, even if behind the
scenes the created tx only sends 0.99999 BTC
Allowing specification of inputs seems to add too much complexity in other
cases, like when value isn't specified at all.
On Mon, Dec 2, 2013 at 2:54 PM, Patrick Mead <patrick@meadia.com.au> wrote:
> First time posting to this mailing list so feel free to ignore me if
> this is a stupid idea.
>
>
> On Mon, Dec 2, 2013 at 3:49 AM, Mike Hearn <mike@plan99.net> wrote:
> >
> > We need to get away from the notion of senders attaching fees anyway.
> This is the wrong
> > way around because it=E2=80=99s the recipient who cares about double sp=
ending
> risk, not the sender.
> >
>
>
> It seems to me that a common problem currently revolves around
> accepting transactions in
> retail scenarios, such as paying for a sandwich from Subway. A
> solution could be to give the
> vendor responsibility for setting the fee, which means they can choose
> the trade-off that works
> best for them in terms of fee size vs. speed of processing.
>
> Idea:
> Add a "fee" parameter to the payment URI specification.
> When processing the transaction, the customer's UI should show only
> the total price, including
> both the transfer amount and the fee. The vendor only accepts the
> transaction if the customer
> uses the right amount and fee. If the fee is too small (for example,
> the user might be using an
> older wallet and has selected a fee of zero), the vendor can issue a
> refund transaction
> immediately and tell the user to try again.
>
> Pros:
> - could easily be implemented immediately
> - old wallets would still be supported by just manually entering the
> fee as users do now
> - no greater risk of double spending on either side
> - maintains the distributed nature of the system
> - relies on humans to judge the fee (who are much less likely to
> spiral infinitely upwards)
> - flexible enough to support varying sizes of transaction and varying
> degrees of security
>
> Cons
> - requires the vendor to have sufficient understanding of Bitcoin to
> make the trade-off
> - doesn't solve the problem of selecting a fee for transactions
> between individuals/laymen
> - doesn't solve fee selection for automated transactions such as
> mixing/de/refragmentation
>
>
> Thoughts?
>
>
> -------------------------------------------------------------------------=
-----
> 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 you=
r
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=3D84349351&iu=3D/4140/ostg.=
clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--001a11c2a1204ba8b304ec8e11f7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Right, as I said earlier:<div><br></div><div><span style=
=3D"font-family:arial,sans-serif;font-size:13px">"The payment protocol=
at least would need some notion of fee, or possibly (better?) the ability =
for a recipient to specify some inputs as well as some outputs."</span=
><br style=3D"font-family:arial,sans-serif;font-size:13px">
</div><div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br>=
</span></div><div><span style=3D"font-family:arial,sans-serif;font-size:13p=
x">Having thought about it a bit more, I think it's better to just have=
a fee field that lets the receiver request the sender to attach the given =
fee. The outputs would have less value associated with them, so effectively=
the seller folds the fee into the price. If the seller is charging a round=
price like 1 mBTC, the user sees "1 mBTC" as the price, even if =
behind the scenes the created tx only sends 0.99999 BTC</span></div>
<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div><div><span style=3D"font-family:arial,sans-serif;font-size:13px">All=
owing specification of inputs seems to add too much complexity in other cas=
es, like when value isn't specified at all.</span></div>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Mon,=
Dec 2, 2013 at 2:54 PM, Patrick Mead <span dir=3D"ltr"><<a href=3D"mail=
to:patrick@meadia.com.au" target=3D"_blank">patrick@meadia.com.au</a>></=
span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">First time posting to this mailing list so f=
eel free to ignore me if<br>
this is a stupid idea.<br>
<div class=3D"im"><br>
<br>
On Mon, Dec 2, 2013 at 3:49 AM, Mike Hearn <<a href=3D"mailto:mike@plan9=
9.net">mike@plan99.net</a>> wrote:<br>
><br>
> We need to get away from the notion of senders attaching fees anyway. =
This is the wrong<br>
> way around because it=E2=80=99s the recipient who cares about double s=
pending risk, not the sender.<br>
><br>
<br>
<br>
</div>It seems to me that a common problem currently revolves around<br>
accepting transactions in<br>
retail scenarios, such as paying for a sandwich from Subway. A<br>
solution could be to give the<br>
vendor responsibility for setting the fee, which means they can choose<br>
the trade-off that works<br>
best for them in terms of fee size vs. speed of processing.<br>
<br>
Idea:<br>
Add a "fee" parameter to the payment URI specification.<br>
When processing the transaction, the customer's UI should show only<br>
the total price, including<br>
both the transfer amount and the fee. The vendor only accepts the<br>
transaction if the customer<br>
uses the right amount and fee. If the fee is too small (for example,<br>
the user might be using an<br>
older wallet and has selected a fee of zero), the vendor can issue a<br>
refund transaction<br>
immediately and tell the user to try again.<br>
<br>
Pros:<br>
- could easily be implemented immediately<br>
- old wallets would still be supported by just manually entering the<br>
fee as users do now<br>
- no greater risk of double spending on either side<br>
- maintains the distributed nature of the system<br>
- relies on humans to judge the fee (who are much less likely to<br>
spiral infinitely upwards)<br>
- flexible enough to support varying sizes of transaction and varying<br>
degrees of security<br>
<br>
Cons<br>
- requires the vendor to have sufficient understanding of Bitcoin to<br>
make the trade-off<br>
- doesn't solve the problem of selecting a fee for transactions<br>
between individuals/laymen<br>
- doesn't solve fee selection for automated transactions such as<br>
mixing/de/refragmentation<br>
<br>
<br>
Thoughts?<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
---------------------------------------------------------------------------=
---<br>
Rapidly troubleshoot problems before they affect your business. Most IT<br>
organizations don't have a clear picture of how application performance=
<br>
affects their revenue. With AppDynamics, you get 100% visibility into your<=
br>
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynami=
cs Pro!<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D84349351&iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D84349351&iu=3D/4140/ostg.clktrk</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br></div>
--001a11c2a1204ba8b304ec8e11f7--
|
