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
|
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 <nathan@leastauthority.com>) id 1Z3nWR-0003wk-N7
for bitcoin-development@lists.sourceforge.net;
Sat, 13 Jun 2015 15:39:03 +0000
X-ACL-Warn:
Received: from mail-oi0-f43.google.com ([209.85.218.43])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z3nWQ-0002qe-2T
for bitcoin-development@lists.sourceforge.net;
Sat, 13 Jun 2015 15:39:03 +0000
Received: by oigz2 with SMTP id z2so36813741oig.1
for <bitcoin-development@lists.sourceforge.net>;
Sat, 13 Jun 2015 08:38:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=x72DjTrgc39yWSKDhCRvBjSGEZ2dloUo4qM957jph0o=;
b=G2h0G9pupoVoklVSy4wIzJGERE06GFC1Fmqa4rJRfvXNx0UJLk1cgXlGab+xXFRzWk
78/30DX3lOQYEVaWsXg1o/G9LSCiaS0haMZVIwMVe+osoEN4+jbybQESXdUpr3gHvaGA
cSS/DRtAKh7d65IobLs4gIdjm91rr0EQ9wSR4QeJF8whQV8Pv1ljEnb3DmQs4V1qnwGC
zfdXkvMnI90obJt4WFHRQJhg6f+Yf/CKsdSjtch34bKEHtHKOLQali72vIDXJWv2B2W0
PZ3h5o/x3RKhk+j821yrZ8uDn3u3c3jD9AaIgnMa7SwJkTsq3Hvm/PHQ2/Ko5qxsHpAW
oqwA==
X-Gm-Message-State: ALoCoQm6ZZmndmFqSjjVWFYV56bF8Ij1mSXTyRIG4g+9B0kvUxpFNrIG2zix94YXbTTVxYEK5tAY
MIME-Version: 1.0
X-Received: by 10.60.102.37 with SMTP id fl5mr13203259oeb.72.1434209936576;
Sat, 13 Jun 2015 08:38:56 -0700 (PDT)
Received: by 10.182.47.229 with HTTP; Sat, 13 Jun 2015 08:38:56 -0700 (PDT)
In-Reply-To: <CACq0ZD4LDTWXsk8Lk5Yf3D7FOwnrgY_oVjRHgH0PhRYmb3ZOdg@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>
<CACq0ZD4LDTWXsk8Lk5Yf3D7FOwnrgY_oVjRHgH0PhRYmb3ZOdg@mail.gmail.com>
Date: Sat, 13 Jun 2015 09:38:56 -0600
Message-ID: <CAFdHNGhS8TZq9d8zysU=kmCxaNAW=P0Vg=QKaDbbNw5b9cj1_Q@mail.gmail.com>
From: Nathan Wilcox <nathan@leastauthority.com>
To: Aaron Voisine <voisine@gmail.com>
Content-Type: multipart/alternative; boundary=089e0111bce0cdc3f4051868052a
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1Z3nWQ-0002qe-2T
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: Sat, 13 Jun 2015 15:39:03 -0000
--089e0111bce0cdc3f4051868052a
Content-Type: text/plain; charset=UTF-8
On Thu, Jun 11, 2015 at 12:55 PM, Aaron Voisine <voisine@gmail.com> wrote:
> > 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.
>
>
Excellent point and alternative proposal. You're right: to get the specifi
fees, you'd need all transactions in a block, and all TxOuts with
membership proofs. Your alternative seems like a much leaner trade-off for
similar data.
>
> 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
>>
>
>
--
Nathan Wilcox
Least Authoritarian
email: nathan@leastauthority.com
twitter: @least_nathan
PGP: 11169993 / AAAC 5675 E3F7 514C 67ED E9C9 3BFE 5263 1116 9993
--089e0111bce0cdc3f4051868052a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Thu, Jun 11, 2015 at 12:55 PM, Aaron Voisine <span dir=3D"ltr"><<=
a href=3D"mailto:voisine@gmail.com" target=3D"_blank">voisine@gmail.com</a>=
></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span=
class=3D"">>=C2=A0<span style=3D"font-size:13px">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.=C2=A0</span><div><span style=3D"font=
-size:13px"><br></span></div></span><div>You don't know the fees paid b=
y any given transaction unless you also have all it's inputs. Transacti=
on inputs do not include an amount. You could however get the average fee-p=
er-kb paid by all transactions in a block by looking at the coinbase transa=
ction, subtracting the block reward, and dividing by the size of block minu=
s the header.</div></div><div class=3D"gmail_extra"><span class=3D""><br cl=
ear=3D"all"></span></div></blockquote><div><br></div><div>Excellent point a=
nd alternative proposal. You're right: to get the specifi fees, you'=
;d need all transactions in a block, and all TxOuts with membership proofs.=
Your alternative seems like a much leaner trade-off for similar data.<br>=
=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail_extra"><=
span class=3D""><div><div><div dir=3D"ltr"><div><div dir=3D"ltr"><div><br>A=
aron Voisine</div><div>co-founder and CEO<br><a href=3D"http://breadwallet.=
com" target=3D"_blank">breadwallet.com</a></div></div></div></div></div></d=
iv>
<br></span><div><div class=3D"h5"><div class=3D"gmail_quote">On Thu, Jun 11=
, 2015 at 11:30 AM, Nathan Wilcox <span dir=3D"ltr"><<a href=3D"mailto:n=
athan@leastauthority.com" target=3D"_blank">nathan@leastauthority.com</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span>O=
n Wed, Jun 10, 2015 at 2:03 PM, Peter Todd <span dir=3D"ltr"><<a href=3D=
"mailto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</a>></s=
pan> wrote:<br></span><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
><span><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:2=
7PM -0600, 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><div>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><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><br>-- =
<br><div>Nathan Wilcox<br>Least Authoritarian<br><br>email: <a href=3D"mail=
to:nathan@leastauthority.com" target=3D"_blank">nathan@leastauthority.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></div></div>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature">Nathan Wilcox<br>Least Authoritarian<br><br>email: <a href=3D"mailt=
o:nathan@leastauthority.com" target=3D"_blank">nathan@leastauthority.com</a=
><br>twitter: @least_nathan<br>PGP: 11169993 / AAAC 5675 E3F7 514C 67ED =C2=
=A0E9C9 3BFE 5263 1116 9993<br></div>
</div></div>
--089e0111bce0cdc3f4051868052a--
|
