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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <morcos@gmail.com>) id 1Xj8sJ-0004gS-EP
for bitcoin-development@lists.sourceforge.net;
Tue, 28 Oct 2014 15:39:59 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.169 as permitted sender)
client-ip=209.85.213.169; envelope-from=morcos@gmail.com;
helo=mail-ig0-f169.google.com;
Received: from mail-ig0-f169.google.com ([209.85.213.169])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Xj8sI-0001n6-DM
for bitcoin-development@lists.sourceforge.net;
Tue, 28 Oct 2014 15:39:59 +0000
Received: by mail-ig0-f169.google.com with SMTP id a13so2737066igq.2
for <bitcoin-development@lists.sourceforge.net>;
Tue, 28 Oct 2014 08:39:53 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.23.80 with SMTP id k16mr5572563igf.26.1414510792896; Tue,
28 Oct 2014 08:39:52 -0700 (PDT)
Received: by 10.50.223.146 with HTTP; Tue, 28 Oct 2014 08:39:52 -0700 (PDT)
In-Reply-To: <CABsx9T2ET_Guoa8J-9irjwOo7vN+9Y3TyEUhdDBWxaYKV1J95w@mail.gmail.com>
References: <CAPWm=eXxs=AfFhaT2EeGFsR+2r96WcaOeWL_Z59-6LixH+=4AQ@mail.gmail.com>
<CABsx9T35NdEkFmdVDX19gOO1p0h1M_ZDK1iXxTFNLHE9dtC3hQ@mail.gmail.com>
<CAPWm=eX0MMBOPvugETxq+pyDzZ00xc90hZAJe8qgg4Shftm-9w@mail.gmail.com>
<CABsx9T2ET_Guoa8J-9irjwOo7vN+9Y3TyEUhdDBWxaYKV1J95w@mail.gmail.com>
Date: Tue, 28 Oct 2014 11:39:52 -0400
Message-ID: <CAPWm=eWdWqDpB29HW1xMc5i-dWQaLRLpK3MWLPOnpQoRRkhJEA@mail.gmail.com>
From: Alex Morcos <morcos@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=089e01538ca057786205067d7505
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
(morcos[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: 1Xj8sI-0001n6-DM
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Reworking the policy estimation code (fee
estimates)
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, 28 Oct 2014 15:39:59 -0000
--089e01538ca057786205067d7505
Content-Type: text/plain; charset=UTF-8
RE: 90% : I think it's fine to use 90% for anything other than 1
confirmation, but if you look at the real world data test I did, or the raw
data from this new code, you'll see that even the highest fee rate
transactions only get confirmed at about a 90% rate in 1 block, so that if
you use that as your cut-off you will sometimes get no answer and sometimes
get a very high fee rate and sometimes get a reasonable fee rate, it just
depends because the data is too noisy. I think thats just because there is
no good answer to that question. There is no fee you can put on your
transaction to guarantee greater than 90% chance of getting confirmed in
one block. I think 85% might be safe?
RE: tunable as command-line/bitcoin.conf: sounds good!
OK, sorry to have all this conversation on the dev list, maybe i'll turn
this into an actual PR if we want to comment on the code?
I just wanted to see if it even made sense to make a PR for this or this
isn't the way we wanted to go about it.
On Tue, Oct 28, 2014 at 10:58 AM, Gavin Andresen <gavinandresen@gmail.com>
wrote:
> On Tue, Oct 28, 2014 at 10:30 AM, Alex Morcos <morcos@gmail.com> wrote:
>>
>> Do you think it would make sense to make that 90% number an argument to
>> rpc call? For instance there could be a default (I would use 80%) but then
>> you could specify if you required a different certainty. It wouldn't
>> require any code changes and might make it easier for people to build more
>> complicated logic on top of it.
>>
>
> RE: 80% versus 90% : I think a default of 80% will get us a lot of "the
> fee estimation logic is broken, I want my transactions to confirm quick and
> a lot of them aren't confirming for 2 or 3 blocks."
>
> RE: RPC argument: I'm reluctant to give too many 'knobs' for the RPC
> interface. I think the default percentage makes sense as a
> command-line/bitcoin.conf option; I can imagine services that want to save
> on fees running with -estimatefeethreshold=0.5 (or
> -estimatefeethreshold=0.95 if as-fast-as-possible confirmations are
> needed). Setting both the number of confirmations and the estimation
> threshold on a transaction-by-transaction basis seems like overkill to me.
>
> --
> --
> Gavin Andresen
>
--089e01538ca057786205067d7505
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">RE: 90% : I think it's fine to use 90% for anything ot=
her than 1 confirmation, but if you look at the real world data test I did,=
or the raw data from this new code, you'll see that even the highest f=
ee rate transactions only get confirmed at about a 90% rate in 1 block, so =
that if you use that as your cut-off you will sometimes get no answer and s=
ometimes get a very high fee rate and sometimes get a reasonable fee rate, =
it just depends because the data is too noisy.=C2=A0 I think thats just bec=
ause there is no good answer to that question.=C2=A0 There is no fee you ca=
n put on your transaction to guarantee greater than 90% chance of getting c=
onfirmed in one block.=C2=A0 I think 85% might be safe?<div><br></div><div>=
RE: tunable as command-line/bitcoin.conf: sounds good!</div><div><br></div>=
<div>OK, sorry to have all this conversation on the dev list, maybe i'l=
l turn this into an actual PR if we want to comment on the code?</div><div>=
I just wanted to see if it even made sense to make a PR for this or this is=
n't the way we wanted to go about it.</div><div><br></div><div><br></di=
v><div><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_q=
uote">On Tue, Oct 28, 2014 at 10:58 AM, Gavin Andresen <span dir=3D"ltr">&l=
t;<a href=3D"mailto:gavinandresen@gmail.com" target=3D"_blank">gavinandrese=
n@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=
=3D"">On Tue, Oct 28, 2014 at 10:30 AM, Alex Morcos <span dir=3D"ltr"><<=
a href=3D"mailto:morcos@gmail.com" target=3D"_blank">morcos@gmail.com</a>&g=
t;</span> wrote:</span><span class=3D""><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
dir=3D"ltr"><div>Do you think it would make sense to make that 90% number =
an argument to rpc call?=C2=A0 For instance there could be a default (I wou=
ld use 80%) but then you could specify if you required a different certaint=
y.=C2=A0 It wouldn't require any code changes and might make it easier =
for people to build more complicated logic on top of it.</div></div></block=
quote><div><br></div></span><div>RE: 80% versus 90% : =C2=A0I think a defau=
lt of 80% will get us a lot of "the fee estimation logic is broken, I =
want my transactions to confirm quick and a lot of them aren't confirmi=
ng for 2 or 3 blocks."</div><div><br></div><div>RE: RPC argument: =C2=
=A0I'm reluctant to give too many 'knobs' for the RPC interface=
. I think the default percentage makes sense as a command-line/bitcoin.conf=
option; I can imagine services that want to save on fees running with -est=
imatefeethreshold=3D0.5 =C2=A0(or -estimatefeethreshold=3D0.95 if as-fast-a=
s-possible confirmations are needed). Setting both the number of confirmati=
ons and the estimation threshold on a transaction-by-transaction basis seem=
s like overkill to me.</div></div><span class=3D"HOEnZb"><font color=3D"#88=
8888"><div><br></div>-- <br>--<br>Gavin Andresen<br>
</font></span></div></div>
</blockquote></div><br></div>
--089e01538ca057786205067d7505--
|
