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-2.v43.ch3.sourceforge.com ([172.29.43.192]
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 1VnmsR-0000dJ-5Z
for bitcoin-development@lists.sourceforge.net;
Tue, 03 Dec 2013 10:06:47 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.43 as permitted sender)
client-ip=209.85.219.43; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f43.google.com;
Received: from mail-oa0-f43.google.com ([209.85.219.43])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VnmsP-0001No-FE
for bitcoin-development@lists.sourceforge.net;
Tue, 03 Dec 2013 10:06:47 +0000
Received: by mail-oa0-f43.google.com with SMTP id i7so14628617oag.2
for <bitcoin-development@lists.sourceforge.net>;
Tue, 03 Dec 2013 02:06:40 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.182.246.39 with SMTP id xt7mr59017187obc.16.1386065199987;
Tue, 03 Dec 2013 02:06:39 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.3.134 with HTTP; Tue, 3 Dec 2013 02:06:39 -0800 (PST)
In-Reply-To: <CABsx9T3NQDPL6=pz5BD5DsP0qh0x3LJOCj2H3yY5tzL2_DivGA@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>
<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>
Date: Tue, 3 Dec 2013 11:06:39 +0100
X-Google-Sender-Auth: NHyEpKdEhr27JZahwe6nZsDLuis
Message-ID: <CANEZrP1PLKemiUEgMJRGdiZXt7o=0_5fhLKYY0x3Ngb_iEm+2w@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c2e224e183ce04ec9e7356
X-Spam-Score: -0.5 (/)
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
(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: 1VnmsP-0001No-FE
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 10:06:47 -0000
--001a11c2e224e183ce04ec9e7356
Content-Type: text/plain; charset=UTF-8
On Tue, Dec 3, 2013 at 2:40 AM, Gavin Andresen <gavinandresen@gmail.com>wrote:
> optional uint64 allowfee tag number=1000
>
Let's just use a normal/low tag number. The extensions mechanism is great
for people who want to extend the protocol outside the core development
process. It'd be weird if nobody ever used the low numbers again though.
Tag numbers are varint encoded so using smaller ones does have a minor
efficiency benefit, it's not just aesthetics :)
> 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.
>
Hmmm. Why "allow"? Should it not be called min_fee instead? Wallets would
have to attach at least that much in fees, right?
Also, why describe it as reducing the amount paid? Which output would be
reduced in value? Why not just have it be added to the total value
displayed to the user and the outputs are left alone/not reduced.
> 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.
>
I like the idea but it seems this gets us back to the original problem -
senders don't care about confirmations, ever, not even if they make an
annoying set of transactions. The protocol allows users to submit
transactions directly to receivers, I guess, if the receiver does not like
the transactions they get they could potentially reject the payment. But
I'd hope that's really rare.
> 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...
>
Sweet, thanks!
--001a11c2e224e183ce04ec9e7356
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Dec 3, 2013 at 2:40 AM, Gavin Andresen <span dir=3D"ltr"><<a href=3D=
"mailto:gavinandresen@gmail.com" target=3D"_blank">gavinandresen@gmail.com<=
/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"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div class=3D"im"><span style=3D"color:rgb(34,34=
,34)">=C2=A0 =C2=A0 optional uint64 allowfee =C2=A0 =C2=A0tag number=3D1000=
</span><br>
</div></div></div></div></blockquote><div><br></div><div>Let's just use=
a normal/low tag number. The extensions mechanism is great for people who =
want to extend the protocol outside the core development process. It'd =
be weird if nobody ever used the low numbers again though.</div>
<div><br></div><div>Tag numbers are varint encoded so using smaller ones do=
es have a minor efficiency benefit, it's not just aesthetics :)</div><d=
iv>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>Allow up to allowfee satoshis to be deducted from the amount paid to be us=
ed to pay Bitcoin network transaction fees. A wallet implementation must no=
t reduce the amount paid for fees more than allowfee, and transaction fees =
must be equal to or greater than the amount reduced.<br>
</div></div></div></div></blockquote><div><br></div><div>Hmmm. Why "al=
low"? Should it not be called min_fee instead? Wallets would have to a=
ttach at least that much in fees, right?</div><div><br></div><div>Also, why=
describe it as reducing the amount paid? Which output would be reduced in =
value? Why not just have it be added to the total value displayed to the us=
er and the outputs are left alone/not reduced.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><div></div>
<div>We also want to allow users to pay MORE in fees, if they need to (frag=
mented wallet, maybe, or big CoinJoin transaction) or decide to.<br></div><=
/div></div></div></blockquote><div><br></div><div>I like the idea but it se=
ems this gets us back to the original problem - senders don't care abou=
t confirmations, ever, not even if they make an annoying set of transaction=
s. The protocol allows users to submit transactions directly to receivers, =
I guess, if the receiver does not like the transactions they get they could=
potentially reject the payment. But I'd hope that's really rare.</=
div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><div></div>
<div>PS: I think there was also consensus that the BIP72 =C2=A0request=3D..=
. =C2=A0 should be shortened to just r=3D... (save 6 chars in QR codes). =
=C2=A0Unless somebody objects, I'll change the BIP and the reference im=
plementation code to make it so...<br>
</div></div></div></div></blockquote><div><br></div><div>Sweet, thanks!</di=
v></div></div></div>
--001a11c2e224e183ce04ec9e7356--
|
