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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <voisine@gmail.com>) id 1Z37dD-0006wW-QQ
for bitcoin-development@lists.sourceforge.net;
Thu, 11 Jun 2015 18:55:15 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.169 as permitted sender)
client-ip=209.85.216.169; envelope-from=voisine@gmail.com;
helo=mail-qc0-f169.google.com;
Received: from mail-qc0-f169.google.com ([209.85.216.169])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z37dC-0004yJ-Mj
for bitcoin-development@lists.sourceforge.net;
Thu, 11 Jun 2015 18:55:15 +0000
Received: by qcjl8 with SMTP id l8so4637452qcj.3
for <bitcoin-development@lists.sourceforge.net>;
Thu, 11 Jun 2015 11:55:09 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.107.228 with SMTP id h91mr13537038qgf.1.1434048909166;
Thu, 11 Jun 2015 11:55:09 -0700 (PDT)
Received: by 10.140.91.37 with HTTP; Thu, 11 Jun 2015 11:55:09 -0700 (PDT)
In-Reply-To: <CAFdHNGg-gJ99L4oartyMMX3PhykhekNbuLrs7Z8JN0zTpwgaZw@mail.gmail.com>
References: <CAFdHNGgtgWGu8gnnJfM0EcVn2m_Wff5HPwAe-9FBvjR++q0Q-Q@mail.gmail.com>
<CACq0ZD5=EunMZJJMKfFUGkR=Ye_8nmV0qLkJJ997gbWk1MTC9w@mail.gmail.com>
<CAFdHNGh=eGCwoMF36Siup-h6aSQtE0mvxCfk+OQRJb-37pds9w@mail.gmail.com>
<20150610200323.GA13724@savin.petertodd.org>
<CAFdHNGg-gJ99L4oartyMMX3PhykhekNbuLrs7Z8JN0zTpwgaZw@mail.gmail.com>
Date: Thu, 11 Jun 2015 11:55:09 -0700
Message-ID: <CACq0ZD4LDTWXsk8Lk5Yf3D7FOwnrgY_oVjRHgH0PhRYmb3ZOdg@mail.gmail.com>
From: Aaron Voisine <voisine@gmail.com>
To: Nathan Wilcox <nathan@leastauthority.com>
Content-Type: multipart/alternative; boundary=001a113a360ed251a705184287b5
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
(voisine[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
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: 1Z37dC-0004yJ-Mj
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal: SPV Fee Discovery mechanism
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: Thu, 11 Jun 2015 18:55:15 -0000
--001a113a360ed251a705184287b5
Content-Type: text/plain; charset=UTF-8
> A Header-PoW-verifying client could still be given all transactions in a
recent block, from which it can see the in-band fees directly.
You don't know the fees paid by any given transaction unless you also have
all it's inputs. Transaction inputs do not include an amount. You could
however get the average fee-per-kb paid by all transactions in a block by
looking at the coinbase transaction, subtracting the block reward, and
dividing by the size of block minus the header.
Aaron Voisine
co-founder and CEO
breadwallet.com
On Thu, Jun 11, 2015 at 11:30 AM, Nathan Wilcox <nathan@leastauthority.com>
wrote:
> On Wed, Jun 10, 2015 at 2:03 PM, Peter Todd <pete@petertodd.org> wrote:
>
>> On Wed, Jun 10, 2015 at 02:00:27PM -0600, Nathan Wilcox wrote:
>> > On Wed, Jun 10, 2015 at 1:19 PM, Aaron Voisine <voisine@gmail.com>
>> wrote:
>> >
>> > > It could be done by agreeing on a data format and encoding it in an
>> > > op_return output in the coinbase transaction. If it catches on it
>> could
>> > > later be enforced with a soft fork.
>> > >
>> > >
>> > Sounds plausible, except SPV protocols would need to include this
>> coinbase
>> > txn if it's going to help SPV clients. (Until a softfork is activated,
>> SPV
>> > clients should not rely on this encoding, since until that time the
>> results
>> > can be fabricated by individual miners.)
>>
>> Fee stats can always be fabricated by individual miners because fees can
>> be paid out-of-band.
>>
>>
> This is a point I hadn't considered carefully before. I don't understand
> the marketplace here or why miners would want to move fees outside of
> explicit inband fees. Implicit in this proposal is that the statistics only
> cover in-band data, because that's the scope of consensus rules, and thus
> the proposal is only as useful as the information of in-band fees is useful.
>
> I've also noticed a detracting technical argument given a particular
> tradeoff:
>
> A Header-PoW-verifying client could still be given all transactions in a
> recent block, from which it can see the in-band fees directly. The
> trade-off is the size of those transactions versus the need to alter any
> consensus rules or do soft forks.
>
> Notice how this trade-off's costs change with maximum block size.
>
>
>
>
>> --
>> 'peter'[:-1]@petertodd.org
>> 00000000000000001245bd2f5c99379ee76836227ded9c08324894faabc0d27f
>>
>
>
>
> --
> Nathan Wilcox
> Least Authoritarian
>
> email: nathan@leastauthority.com
> twitter: @least_nathan
> PGP: 11169993 / AAAC 5675 E3F7 514C 67ED E9C9 3BFE 5263 1116 9993
>
--001a113a360ed251a705184287b5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>=C2=A0<span style=3D"font-size:13px">A Header-PoW-veri=
fying client could still be given all transactions in a recent block, from =
which it can see the in-band fees directly.=C2=A0</span><div><span style=3D=
"font-size:13px"><br></span></div><div>You don't know the fees paid by =
any given transaction unless you also have all it's inputs. Transaction=
inputs do not include an amount. You could however get the average fee-per=
-kb paid by all transactions in a block by looking at the coinbase transact=
ion, subtracting the block reward, and dividing by the size of block minus =
the header.</div></div><div class=3D"gmail_extra"><br clear=3D"all"><div><d=
iv class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div><b=
r>Aaron Voisine</div><div>co-founder and CEO<br><a href=3D"http://breadwall=
et.com" target=3D"_blank">breadwallet.com</a></div></div></div></div></div>=
</div>
<br><div class=3D"gmail_quote">On Thu, Jun 11, 2015 at 11:30 AM, Nathan Wil=
cox <span dir=3D"ltr"><<a href=3D"mailto:nathan@leastauthority.com" targ=
et=3D"_blank">nathan@leastauthority.com</a>></span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">On Wed, Jun 10, 2015=
at 2:03 PM, Peter Todd <span dir=3D"ltr"><<a href=3D"mailto:pete@petert=
odd.org" target=3D"_blank">pete@petertodd.org</a>></span> wrote:<br></sp=
an><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D""><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
#ccc solid;padding-left:1ex"><span>On Wed, Jun 10, 2015 at 02:00:27PM -060=
0, Nathan Wilcox wrote:<br>
> On Wed, Jun 10, 2015 at 1:19 PM, Aaron Voisine <<a href=3D"mailto:v=
oisine@gmail.com" target=3D"_blank">voisine@gmail.com</a>> wrote:<br>
><br>
> > It could be done by agreeing on a data format and encoding it in =
an<br>
> > op_return output in the coinbase transaction. If it catches on it=
could<br>
> > later be enforced with a soft fork.<br>
> ><br>
> ><br>
> Sounds plausible, except SPV protocols would need to include this coin=
base<br>
> txn if it's going to help SPV clients. (Until a softfork is activa=
ted, SPV<br>
> clients should not rely on this encoding, since until that time the re=
sults<br>
> can be fabricated by individual miners.)<br>
<br>
</span>Fee stats can always be fabricated by individual miners because fees=
can<br>
be paid out-of-band.<br>
<span><font color=3D"#888888"><br></font></span></blockquote><div><br></div=
></span><div>This is a point I hadn't considered carefully before. I do=
n't understand the marketplace here or why miners would want to move fe=
es outside of explicit inband fees. Implicit in this proposal is that the s=
tatistics only cover in-band data, because that's the scope of consensu=
s rules, and thus the proposal is only as useful as the information of in-b=
and fees is useful.<br><br>I've also noticed a detracting technical arg=
ument given a particular tradeoff:<br><br>A Header-PoW-verifying client cou=
ld still be given all transactions in a recent block, from which it can see=
the in-band fees directly.=C2=A0 The trade-off is the size of those transa=
ctions versus the need to alter any consensus rules or do soft forks.<br><b=
r></div><div>Notice how this trade-off's costs change with maximum bloc=
k size.<br><br><br></div><span class=3D""><div>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><span><font color=3D"#888888">
--<br>
'peter'[:-1]@<a href=3D"http://petertodd.org" target=3D"_blank">pet=
ertodd.org</a><br>
00000000000000001245bd2f5c99379ee76836227ded9c08324894faabc0d27f<br>
</font></span></blockquote></span></div><br><br clear=3D"all"><span class=
=3D""><br>-- <br><div>Nathan Wilcox<br>Least Authoritarian<br><br>email: <a=
href=3D"mailto:nathan@leastauthority.com" target=3D"_blank">nathan@leastau=
thority.com</a><br>twitter: @least_nathan<br>PGP: 11169993 / AAAC 5675 E3F7=
514C 67ED =C2=A0E9C9 3BFE 5263 1116 9993<br></div>
</span></div></div>
</blockquote></div><br></div>
--001a113a360ed251a705184287b5--
|
