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
|
Return-Path: <dscotese@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 0BAB48A7
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 9 Aug 2015 20:43:51 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com
[209.85.212.176])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CBE9E17B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 9 Aug 2015 20:43:49 +0000 (UTC)
Received: by wicja10 with SMTP id ja10so15784358wic.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 09 Aug 2015 13:43:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:date:message-id:subject
:from:to:cc:content-type;
bh=p93UHjJtlGO+ItxKsVEvx3U0msp9616bXCxCp94Gwu4=;
b=Ojaezy6jn2DblvKv4VkX0hUACA9SGN4oLKgHONFJIcApSFTeKz651wRXnuq4shd/2i
QcA2sONpyMCyTyjgx2NqnhsVURJVAa7f4PcuYDF6+/w0VngQhyyJt/WUosqvv86OdXEP
Xd/L5DC687QmTiI04+42SBKEFLyE6WunnT7X8ZYtGurCvaUkl+Xga2GnkywIVRIW9wmV
ce6+rtTR8AAgmhxf7b4KtmZokXvpAghEgVQcZksPAm9WPa/aeabADYzhaybCXX5SXb8h
lOfcMx2UHk5hVL17DTziQbi2U8mFiA4bCYtgD90n4qVm/ti1zCTDqlkWCwJD66bC7BXU
eDzg==
MIME-Version: 1.0
X-Received: by 10.180.76.232 with SMTP id n8mr18607619wiw.72.1439153028500;
Sun, 09 Aug 2015 13:43:48 -0700 (PDT)
Sender: dscotese@gmail.com
Received: by 10.27.184.134 with HTTP; Sun, 9 Aug 2015 13:43:48 -0700 (PDT)
In-Reply-To: <1905570.ujI5LhNI6Z@coldstorage>
References: <CABsx9T16fH+56isq95m4+QWsKwP==tf75ep8ghnEcBoV4OtZJA@mail.gmail.com>
<CALqxMTGDET0dEuw9bi=LBXF8jiuLdoPoGYaDCPpXtPvqeDW30A@mail.gmail.com>
<CAGLBAhcfUv0ptwczgCkgwVxo7d=pK4GLowkwV2viqAbq6vRaDQ@mail.gmail.com>
<1905570.ujI5LhNI6Z@coldstorage>
Date: Sun, 9 Aug 2015 13:43:48 -0700
X-Google-Sender-Auth: ylw4rzsobICe74aNBB_yTm0fKEI
Message-ID: <CAGLBAhd7s4QoXDfyxCACuVXPA-dRzULuiiW_1AVO0o4_jO8TyQ@mail.gmail.com>
From: Dave Scotese <dscotese@litmocracy.com>
To: Thomas Zander <thomas@thomaszander.se>
Content-Type: multipart/alternative; boundary=f46d043893f90a943c051ce6edf3
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham
version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Fees and the block-finding process
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Aug 2015 20:43:51 -0000
--f46d043893f90a943c051ce6edf3
Content-Type: text/plain; charset=UTF-8
On Sun, Aug 9, 2015 at 3:42 AM, Thomas Zander via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Saturday 8. August 2015 15.45.28 Dave Scotese via bitcoin-dev wrote:
> > Someone mentioned that when the backlog grows faster than it shrinks,
> that
> > is a real problem. I don't think it is. It is a problem for those who
> > don't wait for even one confirmation
>
> The mention you refer to was about the fact that the software doesn't cope
> well with a continuously growing mempool.
> If Bitcoind starts eating more and more memory, I expect lots of people
> that
> run it now to turn it off.
>
That is a real problem then. While emptying the mempool faster with bigger
blocks will help to reduce the occurrence of that problem, I propose a
user-configurable default limit to the size of the mempool as a permanent
solution regardless of block size. "This software has stopped consuming
memory necessary to validate transactions. You can override this by ..."
If anyone feels that protecting those running full nodes from bitcoind
eating more and more memory this way is a good idea, I can make a BIP out
of it if that would help.
> > but backlogs in the past have already
> > started training users to wait for at least one confirmation, or go
> > off-chain.
>
> I am wondering how you concluded that? The only time we saw full blocks
> for a
> considerable amount of time was when we had a spammer, and the only thing
> we taught people was to use higher fees.
>
I concluded that because I don't think I'm all that different than others,
and that is what I have done. The "training" of which I speak is not
always recognized by the bitcoiner on whom it operates. A similar
"training" is how we all learn to ignore teachers because governments force
our attendance at school.
> > Everyone else can double-spend (perhaps that's not as easy as
> > it should be in bitcoin core) and use a higher fee, thus competing for
> > block space.
>
> This is false, if you want to double spent you have to do a lot of work and
> have non-standard software. For instance sending your newer transaction
> to a
> random node will almost always get it rejected because its a double spent.
> Replace by fee (even safe) is not supported in the vast majority of Bitcoin
> land.
>
I don't know what you meant to say is false. I agree with the other stuff
you wrote. Thanks for confirming that it is difficult.
I did some research on replace by fee (FSS-RBF) and on
Child-pays-for-parent (CPFP). You point out that these solutions to paying
too-low fees are "not supported in the vast majority...". Do you mean
philosophically or programmatically? The trend seems to me toward
improvements, just as I insinuated may be necessary ("perhaps that's not as
easy as it should be in bitcoin core"), so, once again, I have to reiterate
that transaction backlog has valuable solutions other than increasing the
block size.
I also realized that we have already been through a period of full blocks,
so that tremendously reduces the value I see in doing it again. It was
that "spam" test someone ran that did it for us, and I love that. It seems
to have kicked the fee-increasability efforts in the butt, which is great.
I now place a higher priority on enabling senders to increase their fee
when necessary than on increasing the Txns per second that the network can
handle. The competition between these two is rather unfair because of how
easy it is to apply the "N MB-blocks bandaid".
Dave
--f46d043893f90a943c051ce6edf3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>On Sun, Aug 9, 2015 at 3:42 AM, Thomas Zander vi=
a bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.lin=
uxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</=
a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quot=
e"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">On Saturday 8. August <a href=3D"tel:2015=
%2015.45.28" value=3D"+12015154528">2015 15.45.28</a> Dave Scotese via bitc=
oin-dev wrote:<br>
> Someone mentioned that when the backlog grows faster than it shrinks, =
that<br>
> is a real problem.=C2=A0 I don't think it is.=C2=A0 It is a proble=
m for those who<br>
> don't wait for even one confirmation<br>
<br>
The mention you refer to was about the fact that the software doesn't c=
ope<br>
well with a continuously growing mempool.<br>
If Bitcoind starts eating more and more memory, I expect lots of people tha=
t<br>
run it now to turn it off.<br></blockquote><div><br></div><div>That is a re=
al problem then.=C2=A0 While emptying the mempool faster with bigger blocks=
will help to reduce the occurrence of that problem, I propose a user-confi=
gurable default limit to the size of the mempool as a permanent solution re=
gardless of block size.=C2=A0 "This software has stopped consuming mem=
ory necessary to validate transactions.=C2=A0 You can override this by ...&=
quot;=C2=A0 If anyone feels that protecting those running full nodes from b=
itcoind eating more and more memory this way is a good idea, I can make a B=
IP out of it if that would help.<br><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">
<br>
> but backlogs in the past have already<br>
> started training users to wait for at least one confirmation, or go<br=
>
> off-chain.<br>
<br>
I am wondering how you concluded that? The only time we saw full blocks for=
a<br>
considerable amount of time was when we had a spammer, and the only thing<b=
r>
we taught people was to use higher fees.<br></blockquote><div><br></div><di=
v>I concluded that because I don't think I'm all that different tha=
n others, and that is what I have done.=C2=A0 The "training" of w=
hich I speak is not always recognized by the bitcoiner on whom it operates.=
=C2=A0 A similar "training" is how we all learn to ignore teacher=
s because governments force our attendance at school.<br></div><div>=C2=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">
> Everyone else can double-spend (perhaps that's not as easy as<br>
> it should be in bitcoin core) and use a higher fee, thus competing for=
<br>
> block space.<br>
<br>
This is false, if you want to double spent you have to do a lot of work and=
<br>
have non-standard software.=C2=A0 For instance sending your newer transacti=
on to a<br>
random node will almost always get it rejected because its a double spent.<=
br>
Replace by fee (even safe) is not supported in the vast majority of Bitcoin=
<br>
land.<br>
<span class=3D"HOEnZb"></span></blockquote></div><br></div><div class=3D"gm=
ail_extra">I don't know what you meant to say is false.=C2=A0 I agree w=
ith the other stuff you wrote.=C2=A0 Thanks for confirming that it is diffi=
cult.<br><br></div><div class=3D"gmail_extra">I did some research on replac=
e by fee (FSS-RBF) and on Child-pays-for-parent (CPFP).=C2=A0 You point out=
that these solutions to paying too-low fees are "not supported in the=
vast majority...".=C2=A0 Do you mean philosophically or programmatica=
lly?=C2=A0 The trend seems to me toward improvements, just as I insinuated =
may be necessary ("perhaps that's not as easy as it should be in b=
itcoin core"), so, once again, I have to reiterate that transaction ba=
cklog has valuable solutions other than increasing the block size.</div><br=
></div>I also realized that we have already been through a period of full b=
locks, so that tremendously reduces the value I see in doing it again.=C2=
=A0 It was that "spam" test someone ran that did it for us, and I=
love that.=C2=A0 It seems to have kicked the fee-increasability efforts in=
the butt, which is great.<br><br>I now place a higher priority on enabling=
senders to increase their fee when necessary than on increasing the Txns p=
er second that the network can handle.=C2=A0 The competition between these =
two is rather unfair because of how easy it is to apply the "N MB-bloc=
ks bandaid".<br><br></div><div>Dave<br></div></div>
--f46d043893f90a943c051ce6edf3--
|
