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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from
<SRS0=ccXgun+D=VL=jerviss.org=bitcoin-devel@jerviss.org>)
id 1Vo5MD-0003t4-1n for bitcoin-development@lists.sourceforge.net;
Wed, 04 Dec 2013 05:50:45 +0000
X-ACL-Warn:
Received: from serv.jerviss.org ([12.47.47.47] helo=inana.jerviss.org)
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1Vo5MB-0007ZC-Q2
for bitcoin-development@lists.sourceforge.net;
Wed, 04 Dec 2013 05:50:45 +0000
Received: from [10.8.2.254] ([192.151.168.109])
(username: kjj authenticated by PLAIN symmetric_key_bits=0)
by inana.jerviss.org (8.13.6/8.12.11) with ESMTP id rB45oWm3005610
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Tue, 3 Dec 2013 23:50:36 -0600
Message-ID: <529EC2A3.7080602@jerviss.org>
Date: Tue, 03 Dec 2013 23:50:27 -0600
From: kjj <bitcoin-devel@jerviss.org>
User-Agent: Mozilla/5.0 (Windows NT 5.2; WOW64;
rv:25.0) Gecko/20100101 SeaMonkey/2.22.1
MIME-Version: 1.0
To: Gavin Andresen <gavinandresen@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>
In-Reply-To: <CABsx9T3NQDPL6=pz5BD5DsP0qh0x3LJOCj2H3yY5tzL2_DivGA@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------010805050402090201000609"
Received-SPF: pass (inana.jerviss.org: 192.151.168.109 is authenticated by a
trusted mechanism)
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 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain 1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1Vo5MB-0007ZC-Q2
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: Wed, 04 Dec 2013 05:50:45 -0000
This is a multi-part message in MIME format.
--------------010805050402090201000609
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
After reading all 99 messages in this thread, I think allowfee is just
about perfect.
It effectively lets merchants to give an allowance against the purchase
price for network fees, if they choose. It is still up to the sender
(and/or the sender's software) to get the fees right. Sometimes the
sender will need to pay more fees than allowed, and sometimes the sender
will need to pay less.
We can't solve the fee problem, in general. I'm not sure that we can
even define it properly. But this is something that we can do, that
will be useful at least occasionally, and that will cause no harm the
rest of the time.
P.S. Clever senders can use this to defrag their wallets. Who wants to
write the patch for that?
Gavin Andresen wrote:
> On Tue, Dec 3, 2013 at 12:44 AM, Mike Hearn <mike@plan99.net
> <mailto:mike@plan99.net>> wrote:
>
> PPv1 doesn't have any notion of fee unfortunately. I suppose it
> could be added easily, but we also need to launch the existing
> feature set.
>
>
> Lets bang out a merchant-pays-fee extension.
>
> How about:
>
> SPEC:
>
> optional uint64 allowfee tag number=1000
>
> Allow up to allowfee satoshis to be deducted from the amount paid to
> be used to pay Bitcoin network transaction fees. A wallet
> implementation must not reduce the amount paid for fees more than
> allowfee, and transaction fees must be equal to or greater than the
> amount reduced.
>
> :ENDSPEC
>
> Rationale: we don't want wallet software giving users discounts--
> sending transactions that are amount-allowfee without paying any fee.
> We also want to allow users to pay MORE in fees, if they need to
> (fragmented wallet, maybe, or big CoinJoin transaction) or decide to.
>
>
> PS: I think there was also consensus that the BIP72 request=...
> should be shortened to just r=... (save 6 chars in QR codes). Unless
> somebody objects, I'll change the BIP and the reference implementation
> code to make it so...
>
> --
> --
> Gavin Andresen
>
>
>
> ------------------------------------------------------------------------------
> 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
--------------010805050402090201000609
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">After reading all 99 messages in this
thread, I think allowfee is just about perfect.<br>
<br>
It effectively lets merchants to give an allowance against the
purchase price for network fees, if they choose. It is still up
to the sender (and/or the sender's software) to get the fees
right. Sometimes the sender will need to pay more fees than
allowed, and sometimes the sender will need to pay less.<br>
<br>
We can't solve the fee problem, in general. I'm not sure that we
can even define it properly. But this is something that we can
do, that will be useful at least occasionally, and that will cause
no harm the rest of the time.<br>
<br>
P.S. Clever senders can use this to defrag their wallets. Who
wants to write the patch for that?<br>
<br>
Gavin Andresen wrote:<br>
</div>
<blockquote
cite="mid:CABsx9T3NQDPL6=pz5BD5DsP0qh0x3LJOCj2H3yY5tzL2_DivGA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Tue, Dec 3, 2013 at 12:44 AM, Mike
Hearn <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:mike@plan99.net" target="_blank">mike@plan99.net</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">PPv1 doesn't have any notion of fee
unfortunately. I suppose it could be added easily, but
we also need to launch the existing feature set.</div>
</blockquote>
<div><br>
</div>
<div>Lets bang out a merchant-pays-fee extension.</div>
<div><br>
</div>
<div>How about:</div>
<div><br>
</div>
<div>SPEC:</div>
<div><br>
</div>
<div> optional uint64 allowfee tag number=1000</div>
<div><br>
</div>
<div>Allow up to allowfee satoshis to be deducted from the
amount paid to be used to pay Bitcoin network transaction
fees. A wallet implementation must not reduce the amount
paid for fees more than allowfee, and transaction fees
must be equal to or greater than the amount reduced.</div>
<div><br>
</div>
<div>:ENDSPEC</div>
<div><br>
</div>
<div>Rationale: we don't want wallet software giving users
discounts-- sending transactions that are amount-allowfee
without paying any fee. We also want to allow users to
pay MORE in fees, if they need to (fragmented wallet,
maybe, or big CoinJoin transaction) or decide to.</div>
<div><br>
</div>
<div><br>
</div>
<div>PS: I think there was also consensus that the BIP72
request=... should be shortened to just r=... (save 6
chars in QR codes). Unless somebody objects, I'll change
the BIP and the reference implementation code to make it
so...</div>
<div><br>
</div>
</div>
-- <br>
--<br>
Gavin Andresen<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>
--------------010805050402090201000609--
|
