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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gavinandresen@gmail.com>) id 1VZRgz-0004ND-Ns
for bitcoin-development@lists.sourceforge.net;
Thu, 24 Oct 2013 20:39:41 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.177 as permitted sender)
client-ip=209.85.212.177; envelope-from=gavinandresen@gmail.com;
helo=mail-wi0-f177.google.com;
Received: from mail-wi0-f177.google.com ([209.85.212.177])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VZRgy-0001wE-Ne
for bitcoin-development@lists.sourceforge.net;
Thu, 24 Oct 2013 20:39:41 +0000
Received: by mail-wi0-f177.google.com with SMTP id h11so131801wiv.16
for <bitcoin-development@lists.sourceforge.net>;
Thu, 24 Oct 2013 13:39:34 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.211.111 with SMTP id nb15mr3695954wic.55.1382647174516;
Thu, 24 Oct 2013 13:39:34 -0700 (PDT)
Received: by 10.194.156.163 with HTTP; Thu, 24 Oct 2013 13:39:34 -0700 (PDT)
In-Reply-To: <20131024145447.GA19949@savin>
References: <20131024143043.GA12658@savin>
<CANEZrP100Lg_1LcFMKx1yWrGTSFb5GZmLmXNbZjPGaiEgOeuwA@mail.gmail.com>
<20131024144358.GA17142@savin>
<CANEZrP1TfM+wYbGjUk3+8JJZs6cKZXdb57xGMc=hDr9dQjMMZA@mail.gmail.com>
<20131024145447.GA19949@savin>
Date: Fri, 25 Oct 2013 06:39:34 +1000
Message-ID: <CABsx9T0T0v=HnRRr6BLKNQOFMBJWrhF4G4SOCJ9DidGJBB8Eow@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=001a11c34854afd87304e982a12d
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
(gavinandresen[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
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: petertodd.org]
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: 1VZRgy-0001wE-Ne
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Making fee estimation better
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, 24 Oct 2013 20:39:42 -0000
--001a11c34854afd87304e982a12d
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Oct 25, 2013 at 12:54 AM, Peter Todd <pete@petertodd.org> wrote:
> Eligius has contracts to do transaction mining, and it's currently 10%
> of the hashing power.
>
Yes, and I asked Luke what percentage of that 10% is OOB fee payments, and
the answer is "a small percentage."
So: there are multiple layers of reasons why OOB fee payments will not
screw up the fee estimation code:
+ If the transactions are not broadcast, then they have no effect on the
estimates.
+ If the transactions are broadcast but not relayed because their priority
and fee are way below current estimates then they will have very close to
zero effect on the estimates.
+ If the OOB transaction is zero-fee, zero-priority (e.g comes from a
high-tx-volume service and relies on recently spent outputs) it will have
zero effect on the estimates.
+ If they make up less than about 40% of broadcast transactions they will
have very close to zero effect on the fee estimate (because of the
distribution of fees and behavior of taking a median)
The only case where the estimation code is even slightly likely to get
confused is estimating the priority needed to get into a block IF there are
a significant number of zero-fee, low-but-not-zero-priority OOB
transactions being broadcast.
And since priority naturally increases over time, even if that case DOES
occur the failure is very mild-- it means your free transactions might have
to build up more priority than the code estimates before successfully
entering a block. If that gets to be an actual problem, then implementing
Pieter's idea of keeping track of memory pool transactions that are NOT
getting mined would fix it. But I don't want to waste time on a theoretical
problem when it is very possible miners will decide to stop accepting free
transactions alltogether.
And all of the above is completely orthogonal to child-pays-for-parent
and/or replace-with-higher-fee.
PS: I would appreciate it if you stop saying things like "Regarding the
transaction fee estimate code, it's not very well thought out."
--
--
Gavin Andresen
--001a11c34854afd87304e982a12d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Oct 25, 2013 at 12:54 AM, Peter Todd <span dir=3D"ltr"><<a href=3D"m=
ailto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</a>></spa=
n> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div class=3D"im"><span style=3D"color:rgb(34,34,34)">Elig=
ius has contracts to do transaction mining, and it's currently 10%</spa=
n><br>
</div>
of the hashing power.<br></blockquote><div><br></div><div>Yes, and I asked =
Luke what percentage of that 10% is OOB fee payments, and the answer is &qu=
ot;a small percentage."</div><div><br></div><div>So: there are multipl=
e layers of reasons why OOB fee payments will not screw up the fee estimati=
on code:</div>
<div><br></div><div>+ If the transactions are not broadcast, then they have=
no effect on the estimates.</div><div><br></div><div>+ If the transactions=
are broadcast but not relayed because their priority and fee are way below=
current estimates then they will have very close to zero effect on the est=
imates.</div>
<div><br></div><div>+ If the OOB transaction is zero-fee, zero-priority (e.=
g comes from a high-tx-volume service and relies on recently spent outputs)=
it will have zero effect on the estimates.<br></div><div><br></div><div>
+ If they make up less than about 40% of broadcast transactions they will h=
ave very close to zero effect on the fee estimate (because of the distribut=
ion of fees and behavior of taking a median)</div></div><div><br></div>
<div>The only case where the estimation code is even slightly likely to get=
confused is estimating the priority needed to get into a block IF there ar=
e a significant number of zero-fee, low-but-not-zero-priority OOB transacti=
ons being broadcast.</div>
<div><br></div><div>And since priority naturally increases over time, even =
if that case DOES occur the failure is very mild-- it means your free trans=
actions might have to build up more priority than the code estimates before=
successfully entering a block. =A0If that gets to be an actual problem, th=
en implementing Pieter's idea of keeping track of memory pool transacti=
ons that are NOT getting mined would fix it. But I don't want to waste =
time on a theoretical problem when it is very possible miners will decide t=
o stop accepting free transactions alltogether.</div>
<div><br></div><div><br></div><div><br></div><div>And all of the above is c=
ompletely orthogonal to child-pays-for-parent and/or replace-with-higher-fe=
e.<br><br>PS: I would appreciate it if you stop saying things like "<s=
pan style=3D"color:rgb(0,0,0);font-family:Verdana,arial,sans-serif;line-hei=
ght:16.890625px">Regarding the transaction fee estimate code, it's not =
very well thought out."</span></div>
<div><br></div>-- <br>--<br>Gavin Andresen<br>
</div><div class=3D"gmail_extra"><br></div></div>
--001a11c34854afd87304e982a12d--
|
