summaryrefslogtreecommitdiff
path: root/51/e51951d0027913b734aa3cf614d23f034f0765
blob: 788044fa65c4a16938660ae038eb7eeebba7dadd (plain)
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
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 <nathan@leastauthority.com>) id 1Z37Fo-0002Iu-MC
	for bitcoin-development@lists.sourceforge.net;
	Thu, 11 Jun 2015 18:31:04 +0000
X-ACL-Warn: 
Received: from mail-oi0-f41.google.com ([209.85.218.41])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Z37Fk-0003mo-5N
	for bitcoin-development@lists.sourceforge.net;
	Thu, 11 Jun 2015 18:31:04 +0000
Received: by oihd6 with SMTP id d6so8460990oih.2
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 11 Jun 2015 11:30:54 -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=MzkUZUmMD96atMY3EgbmHFgkh8JHK/rmV/PCVXhDhpM=;
	b=DF1SJstruPutsAtZxEEI4XMupj6W6lk8rtoAHqiJjAVeXyC/3BP/23qsmLqoK4chx7
	UKSkVpFnxr+BivnioaH+9oaDnArORhaxh2ff29STijewoIDBD8HhbStH9pjyWKAZDWcV
	ADwmGU0jUBDFwCRR6PV4zZcfMmH8nINe56oEUHAxuWTXWL/dF/LMaObK6x/bjmzjjKwQ
	Qt7M79hpFEJ0JTPJHRVLRKBcj4MHFsvBffwO/c6VCya2fa/qYUeINv5OTU6upuCLxE04
	nF75wfft/FqoACohin7VSWsm6JjLhll1/Xd3xVMtBpbWbHKyg1DJVNunHngGS28vSrnc
	+Q+A==
X-Gm-Message-State: ALoCoQmA3XUvv9lqL8hHDLNfGOeQlyQ+Kf1Gh1WNZruqimiecb8g/6+g1LSuEjlOThaitNI7uYkE
MIME-Version: 1.0
X-Received: by 10.182.240.228 with SMTP id wd4mr8687264obc.79.1434047454744;
	Thu, 11 Jun 2015 11:30:54 -0700 (PDT)
Received: by 10.182.47.229 with HTTP; Thu, 11 Jun 2015 11:30:54 -0700 (PDT)
In-Reply-To: <20150610200323.GA13724@savin.petertodd.org>
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>
Date: Thu, 11 Jun 2015 12:30:54 -0600
Message-ID: <CAFdHNGg-gJ99L4oartyMMX3PhykhekNbuLrs7Z8JN0zTpwgaZw@mail.gmail.com>
From: Nathan Wilcox <nathan@leastauthority.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=089e01634d6e21a5e10518423130
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: 1Z37Fk-0003mo-5N
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:31:04 -0000

--089e01634d6e21a5e10518423130
Content-Type: text/plain; charset=UTF-8

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

--089e01634d6e21a5e10518423130
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wed, Jun 10, 2015 at 2:03 PM, Peter Todd <span dir=3D"l=
tr">&lt;<a href=3D"mailto:pete@petertodd.org" target=3D"_blank">pete@petert=
odd.org</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"g=
mail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Wed, Jun 10,=
 2015 at 02:00:27PM -0600, Nathan Wilcox wrote:<br>
&gt; On Wed, Jun 10, 2015 at 1:19 PM, Aaron Voisine &lt;<a href=3D"mailto:v=
oisine@gmail.com">voisine@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; It could be done by agreeing on a data format and encoding it in =
an<br>
&gt; &gt; op_return output in the coinbase transaction. If it catches on it=
 could<br>
&gt; &gt; later be enforced with a soft fork.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; Sounds plausible, except SPV protocols would need to include this coin=
base<br>
&gt; txn if it&#39;s going to help SPV clients. (Until a softfork is activa=
ted, SPV<br>
&gt; clients should not rely on this encoding, since until that time the re=
sults<br>
&gt; 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 class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquo=
te><div><br></div><div>This is a point I hadn&#39;t considered carefully be=
fore. I don&#39;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&#39;s the scope o=
f consensus rules, and thus the proposal is only as useful as the informati=
on of in-band fees is useful.<br><br>I&#39;ve also noticed a detracting tec=
hnical argument given a particular tradeoff:<br><br>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 The trade-off is the size of th=
ose transactions versus the need to alter any consensus rules or do soft fo=
rks.<br><br></div><div>Notice how this trade-off&#39;s costs change with ma=
ximum block size.<br><br><br></div><div>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><span class=3D"HOEnZb"><font color=3D"#888888">
--<br>
&#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org" target=3D"_blank">pet=
ertodd.org</a><br>
00000000000000001245bd2f5c99379ee76836227ded9c08324894faabc0d27f<br>
</font></span></blockquote></div><br><br clear=3D"all"><br>-- <br><div clas=
s=3D"gmail_signature">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>
</div></div>

--089e01634d6e21a5e10518423130--