summaryrefslogtreecommitdiff
path: root/8e/213988426066728bbe0c54a0a6c872ee64a725
blob: 7cd6eb5b85dad69b0ac3b72c5f4ffdbe6ed56bb6 (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
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
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
Return-Path: <morcos@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id B895FAAC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  5 Oct 2015 20:02:43 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f180.google.com (mail-io0-f180.google.com
	[209.85.223.180])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id ACAC5168
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  5 Oct 2015 20:02:41 +0000 (UTC)
Received: by ioiz6 with SMTP id z6so198171827ioi.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 05 Oct 2015 13:02:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=A7+niDi1wfTk5qhzSR0z/oxwi6zX1i0U2QA68L6pHfg=;
	b=WPSX6XcMMimgIIx6c16TaNyx6kelSNy3QTj5a3SWgaiCtLlwrNJbzyrERUEF89LsMp
	HZpL0miFbcwNwpnVYPHxcANflViecFNTaSlvOzllTJxo3SsB/tiYTdEBdPeXoykkKCSI
	s6d0+9ynG3bxkXgZaj9ruB/JRNAO4wfVj8jKlfw55JzFZbyEuAYGHEiONrP+YbInKPJ1
	ippVI1n9zqNpUds1tcl+JAr68aWRONRGQXhqAmGykBP7E8jwEu2mbdB6KJVBznP1lJz1
	WUhJcLK5scMpQFVC2WAhjX2u7LHkhFb0wUb0dY7HODBW29c/fKzdZkD5Fma/2tDgHbNj
	pOjQ==
MIME-Version: 1.0
X-Received: by 10.107.10.140 with SMTP id 12mr31498238iok.160.1444075360976;
	Mon, 05 Oct 2015 13:02:40 -0700 (PDT)
Received: by 10.64.106.103 with HTTP; Mon, 5 Oct 2015 13:02:40 -0700 (PDT)
In-Reply-To: <CAJN5wHXJkFefminbnY6O93PUkQKCyLpvM57TCp+4q6p6CEzhzg@mail.gmail.com>
References: <CAPWm=eWuvC8zYM_ipAnaQttKQQG2Vas6np_bAFkxG31eR5w=xQ@mail.gmail.com>
	<55D77A7F.40402@mattcorallo.com>
	<CAJN5wHVzzo-dD6FFyaydEDm27HK2OkWxC0o0Pxcy-N9wTfv8Gw@mail.gmail.com>
	<CAPWm=eW-g9F5YZ9EdqXGzpzvs2mQJ8N5wKG15Ofz4cWGaHQ0BQ@mail.gmail.com>
	<CAPWm=eVVdyYxePrXur17P=FdMpUvNmByz30hey5=R46PQPhf-Q@mail.gmail.com>
	<CAJN5wHXJkFefminbnY6O93PUkQKCyLpvM57TCp+4q6p6CEzhzg@mail.gmail.com>
Date: Mon, 5 Oct 2015 16:02:40 -0400
Message-ID: <CAPWm=eWfnuW98aLhaULCM5BAXThOz1E_APLC+Yd2uOJ4-B4PsA@mail.gmail.com>
From: Alex Morcos <morcos@gmail.com>
To: Danny Thorpe <danny.thorpe@gmail.com>
Content-Type: multipart/alternative; boundary=001a113eeccaeb8799052160feaf
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,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] Proposed new policy for transactions that depend
 on other unconfirmed transactions
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: Mon, 05 Oct 2015 20:02:43 -0000

--001a113eeccaeb8799052160feaf
Content-Type: text/plain; charset=UTF-8

Yes, total number of dependent transactions regardless of chain depth.

A descendant package means all the transactions that can not be included in
a block before the transaction in question.

An ancestor package means all the transactions that are required to be
included in a block before the transaction in question can be.




On Mon, Oct 5, 2015 at 2:51 PM, Danny Thorpe <danny.thorpe@gmail.com> wrote:

> What does "package" mean here?
>
> When you say 25 txs, does that mean maximum linked chain depth, or total
> number of dependent transactions regardless of chain depth?
>
> Thanks,
> -Danny
>
>
>
> On Mon, Oct 5, 2015 at 11:45 AM, Alex Morcos via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I'd like to propose updates to the new policy limits on unconfirmed
>> transaction chains.
>>
>> The existing limits in master and scheduled for release in 0.12 are:
>> Ancestor packages = 100 txs and 900kb total size
>> Descendant packages = 1000 txs and 2500kb total size
>>
>> Before 0.12 is released I would like to propose a significant reduction
>> in these limits. In the course of analyzing algorithms for mempool
>> limiting, it became clear that large packages of unconfirmed transactions
>> were the primary vector for mempool clogging or relay fee boosting attacks.
>> Feedback from the initial proposed limits was that they were too generous
>> anyway.
>>
>> The proposed new limits are:
>> Ancestor packages = 25 txs and 100kb total size
>> Descendant packages = 25 txs and 100kb total size
>>
>> Based on historical transaction data, the most restrictive of these
>> limits is the 25 transaction count on descendant packages. Over the period
>> of April and May of this year (before stress tests), 5.8% of transactions
>> would have violated this limit alone. Applying all the limits together
>> would have affected 6.1% of transactions.
>>
>> Please keep in mind these are policy limits that affect transactions
>> which depend on other unconfirmed transactions only. They are not a change
>> to consensus rules and do not affect how many chained txs a valid block may
>> contain. Furthermore, any transaction that was unable to be relayed due to
>> these limits need only wait for some of its unconfirmed ancestors to be
>> included in a block and then it could be successfully broadcast. This is
>> unlikely to affect the total time from creation to inclusion in a block.
>> Finally, these limits are command line arguments that can easily be changed
>> on an individual node basis in Bitcoin Core.
>>
>> Please give your feedback if you know of legitimate use cases that would
>> be hindered by these limits.
>>
>> Thanks,
>> Alex
>>
>> On Mon, Sep 21, 2015 at 11:02 AM, Alex Morcos <morcos@gmail.com> wrote:
>>
>>> Thanks for everyone's review.  These policy changes have been merged in
>>> to master in 6654 <https://github.com/bitcoin/bitcoin/pull/6654>, which
>>> just implements these limits and no mempool limiting yet.  The default
>>> ancestor package size limit is 900kb not 1MB.
>>>
>>> Yes I think these limits are generous, but they were designed to be as
>>> generous as was computationally feasible so they were unobjectionable
>>> (since the existing policy was no limits).  This does not preclude future
>>> changes to policy that would reduce these limits.
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Aug 21, 2015 at 3:52 PM, Danny Thorpe <danny.thorpe@gmail.com>
>>> wrote:
>>>
>>>> The limits Alex proposed are generous (bordering on obscene!), but
>>>> dropping that down to allowing only two levels of chained unconfirmed
>>>> transactions is too tight.
>>>>
>>>> Use case: Brokered asset transfers may require sets of transactions
>>>> with a dependency tree depth of 3 to be published together. ( N seller txs,
>>>> 1 broker bridge tx, M buyer txs )
>>>>
>>>> If the originally proposed depth limit of 100 does not provide a
>>>> sufficient cap on memory consumption or loop/recursion depth, a depth limit
>>>> of 10 would provide plenty of headroom for this 3 level use case and
>>>> similar patterns.
>>>>
>>>> -Danny
>>>>
>>>> On Fri, Aug 21, 2015 at 12:22 PM, Matt Corallo via bitcoin-dev <
>>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>
>>>>> I dont see any problem with such limits. Though, hell, if you limited
>>>>> entire tx dependency trees (ie transactions and all required
>>>>> unconfirmed
>>>>> transactions for them) to something like 10 txn, maximum two levels
>>>>> deep, I also wouldnt have a problem.
>>>>>
>>>>> Matt
>>>>>
>>>>> On 08/14/15 19:33, Alex Morcos via bitcoin-dev wrote:
>>>>> > Hi everyone,
>>>>> >
>>>>> >
>>>>> > I'd like to propose a new set of requirements as a policy on when to
>>>>> > accept new transactions into the mempool and relay them.  This policy
>>>>> > would affect transactions which have as inputs other transactions
>>>>> which
>>>>> > are not yet confirmed in the blockchain.
>>>>> >
>>>>> > The motivation for this policy is 6470
>>>>> > <https://github.com/bitcoin/bitcoin/pull/6470> which aims to limit
>>>>> the
>>>>> > size of a mempool.  As discussed in that pull
>>>>> > <https://github.com/bitcoin/bitcoin/pull/6470#issuecomment-125324736
>>>>> >,
>>>>> > once the mempool is full a new transaction must be able to pay not
>>>>> only
>>>>> > for the transaction it would evict, but any dependent transactions
>>>>> that
>>>>> > would be removed from the mempool as well.  In order to make sure
>>>>> this
>>>>> > is always feasible, I'm proposing 4 new policy limits.
>>>>> >
>>>>> > All limits are command line configurable.
>>>>> >
>>>>> > The first two limits are required to make sure no chain of
>>>>> transactions
>>>>> > will be too large for the eviction code to handle:
>>>>> >
>>>>> > Max number of descendant txs : No transaction shall be accepted if it
>>>>> > would cause another transaction in the mempool to have too many
>>>>> > descendant transactions (all of which would have to be evicted if the
>>>>> > ancestor transaction was evicted).  Default: 1000
>>>>> >
>>>>> > Max descendant size : No transaction shall be accepted if it would
>>>>> cause
>>>>> > another transaction in the mempool to have the total size of all its
>>>>> > descendant transactions be too great.  Default : maxmempool / 200
>>>>> =  2.5MB
>>>>> >
>>>>> > The third limit is required to make sure calculating the state
>>>>> required
>>>>> > for sorting and limiting the mempool and enforcing the first 2
>>>>> limits is
>>>>> > computationally feasible:
>>>>> >
>>>>> > Max number of ancestor txs:  No transaction shall be accepted if it
>>>>> has
>>>>> > too many ancestor transactions which are not yet confirmed (ie, in
>>>>> the
>>>>> > mempool). Default: 100
>>>>> >
>>>>> > The fourth limit is required to maintain the pre existing policy goal
>>>>> > that all transactions in the mempool should be mineable in the next
>>>>> block.
>>>>> >
>>>>> > Max ancestor size: No transaction shall be accepted if the total
>>>>> size of
>>>>> > all its unconfirmed ancestor transactions is too large.  Default: 1MB
>>>>> >
>>>>> > (All limits include the transaction itself.)
>>>>> >
>>>>> > For reference, these limits would have affected less than 2% of
>>>>> > transactions entering the mempool in April or May of this year.
>>>>> During
>>>>> > the period of 7/6 through 7/14, while the network was under stress
>>>>> test,
>>>>> > as many as 25% of the transactions would have been affected.
>>>>> >
>>>>> > The code to implement the descendant package tracking and new policy
>>>>> > limits can be found in 6557
>>>>> > <https://github.com/bitcoin/bitcoin/pull/6557> which is built off
>>>>> of 6470.
>>>>> >
>>>>> > Thanks,
>>>>> > Alex
>>>>> >
>>>>> >
>>>>> >
>>>>> > _______________________________________________
>>>>> > bitcoin-dev mailing list
>>>>> > bitcoin-dev@lists.linuxfoundation.org
>>>>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>> >
>>>>> _______________________________________________
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev@lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>

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

<div dir=3D"ltr">Yes, total number of dependent transactions regardless of =
chain depth. =C2=A0<div><br></div><div>A descendant package means all the t=
ransactions that can not be included in a block before the transaction in q=
uestion.</div><div><br></div><div>An ancestor package means all the transac=
tions that are required to be included in a block before the transaction in=
 question can be.</div><div><br><div><br></div><div><br></div></div></div><=
div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Oct 5, 201=
5 at 2:51 PM, Danny Thorpe <span dir=3D"ltr">&lt;<a href=3D"mailto:danny.th=
orpe@gmail.com" target=3D"_blank">danny.thorpe@gmail.com</a>&gt;</span> wro=
te:<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">What does &quot;pack=
age&quot; mean here? =C2=A0<div><br></div><div>When you say 25 txs, does th=
at mean maximum linked chain depth, or total number of dependent transactio=
ns regardless of chain depth?</div><div><br></div><div>Thanks,</div><div>-D=
anny<br><div><br></div><div><br></div></div></div><div class=3D"HOEnZb"><di=
v class=3D"h5"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On=
 Mon, Oct 5, 2015 at 11:45 AM, Alex Morcos via bitcoin-dev <span dir=3D"ltr=
">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_b=
lank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div dir=3D"ltr">I&#39;d like to propose updates t=
o the new policy limits on unconfirmed transaction chains.=C2=A0<div><br></=
div><div>The existing limits in master and scheduled for release in 0.12 ar=
e:=C2=A0</div><div>Ancestor packages =3D 100 txs and 900kb total size</div>=
<div>Descendant packages =3D 1000 txs and 2500kb total size=C2=A0</div><div=
><br></div><div>Before 0.12 is released I would like to propose a significa=
nt reduction in these limits. In the course of analyzing algorithms for mem=
pool limiting, it became clear that large packages of unconfirmed transacti=
ons were the primary vector for mempool clogging or relay fee boosting atta=
cks. Feedback from the initial proposed limits was that they were too gener=
ous anyway.=C2=A0</div><div><br></div><div>The proposed new limits are:=C2=
=A0</div><div>Ancestor packages =3D 25 txs and 100kb total size</div><div>D=
escendant packages =3D 25 txs and 100kb total size=C2=A0</div><div><br></di=
v><div>Based on historical transaction data, the most restrictive of these =
limits is the 25 transaction count on descendant packages. Over the period =
of April and May of this year (before stress tests), 5.8% of transactions w=
ould have violated this limit alone. Applying all the limits together would=
 have affected 6.1% of transactions.=C2=A0</div><div><br></div><div>Please =
keep in mind these are policy limits that affect transactions which depend =
on other unconfirmed transactions only. They are not a change to consensus =
rules and do not affect how many chained txs a valid block may contain. Fur=
thermore, any transaction that was unable to be relayed due to these limits=
 need only wait for some of its unconfirmed ancestors to be included in a b=
lock and then it could be successfully broadcast. This is unlikely to affec=
t the total time from creation to inclusion in a block. Finally, these limi=
ts are command line arguments that can easily be changed on an individual n=
ode basis in Bitcoin Core.=C2=A0</div><div><br></div><div>Please give your =
feedback if you know of legitimate use cases that would be hindered by thes=
e limits.=C2=A0</div><div><br></div><div>Thanks,=C2=A0</div><span><font col=
or=3D"#888888"><div>Alex</div></font></span></div><div><div><div class=3D"g=
mail_extra"><br><div class=3D"gmail_quote">On Mon, Sep 21, 2015 at 11:02 AM=
, Alex Morcos <span dir=3D"ltr">&lt;<a href=3D"mailto:morcos@gmail.com" tar=
get=3D"_blank">morcos@gmail.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">Thanks for everyone&#39;s review.=C2=A0 Thes=
e policy changes have been merged in to master in <a href=3D"https://github=
.com/bitcoin/bitcoin/pull/6654" target=3D"_blank">6654</a>, which just impl=
ements these limits and no mempool limiting yet.=C2=A0 The default ancestor=
 package size limit is 900kb not 1MB.<div><br></div><div>Yes I think these =
limits are generous, but they were designed to be as generous as was comput=
ationally feasible so they were unobjectionable (since the existing policy =
was no limits).=C2=A0 This does not preclude future changes to policy that =
would reduce these limits.</div><div><br></div><div><br></div><div><br></di=
v><div><br></div></div><div><div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Fri, Aug 21, 2015 at 3:52 PM, Danny Thorpe <span dir=3D=
"ltr">&lt;<a href=3D"mailto:danny.thorpe@gmail.com" target=3D"_blank">danny=
.thorpe@gmail.com</a>&gt;</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">The limits Alex proposed are generous (bordering on obscene=
!), but dropping that down to allowing only two levels of chained unconfirm=
ed transactions is too tight. =C2=A0<div><br></div><div>Use case: Brokered =
asset transfers may require sets of transactions with a dependency tree dep=
th of 3 to be published together. ( N seller txs, 1 broker bridge tx, M buy=
er txs )</div><div><br></div><div>If the originally proposed depth limit of=
 100 does not provide a sufficient cap on memory consumption or loop/recurs=
ion depth, a depth limit of 10 would provide plenty of headroom for this 3 =
level use case and similar patterns.</div><span><font color=3D"#888888"><di=
v><br></div><div>-Danny</div></font></span></div><div><div><div class=3D"gm=
ail_extra"><br><div class=3D"gmail_quote">On Fri, Aug 21, 2015 at 12:22 PM,=
 Matt Corallo via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitco=
in-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linux=
foundation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I do=
nt see any problem with such limits. Though, hell, if you limited<br>
entire tx dependency trees (ie transactions and all required unconfirmed<br=
>
transactions for them) to something like 10 txn, maximum two levels<br>
deep, I also wouldnt have a problem.<br>
<br>
Matt<br>
<br>
On 08/14/15 19:33, Alex Morcos via bitcoin-dev wrote:<br>
&gt; Hi everyone,<br>
&gt;<br>
&gt;<br>
&gt; I&#39;d like to propose a new set of requirements as a policy on when =
to<br>
&gt; accept new transactions into the mempool and relay them.=C2=A0 This po=
licy<br>
&gt; would affect transactions which have as inputs other transactions whic=
h<br>
&gt; are not yet confirmed in the blockchain.<br>
&gt;<br>
&gt; The motivation for this policy is 6470<br>
&gt; &lt;<a href=3D"https://github.com/bitcoin/bitcoin/pull/6470" rel=3D"no=
referrer" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/6470</a=
>&gt; which aims to limit the<br>
&gt; size of a mempool.=C2=A0 As discussed in that pull<br>
&gt; &lt;<a href=3D"https://github.com/bitcoin/bitcoin/pull/6470#issuecomme=
nt-125324736" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitco=
in/bitcoin/pull/6470#issuecomment-125324736</a>&gt;,<br>
&gt; once the mempool is full a new transaction must be able to pay not onl=
y<br>
&gt; for the transaction it would evict, but any dependent transactions tha=
t<br>
&gt; would be removed from the mempool as well.=C2=A0 In order to make sure=
 this<br>
&gt; is always feasible, I&#39;m proposing 4 new policy limits.<br>
&gt;<br>
&gt; All limits are command line configurable.<br>
&gt;<br>
&gt; The first two limits are required to make sure no chain of transaction=
s<br>
&gt; will be too large for the eviction code to handle:<br>
&gt;<br>
&gt; Max number of descendant txs : No transaction shall be accepted if it<=
br>
&gt; would cause another transaction in the mempool to have too many<br>
&gt; descendant transactions (all of which would have to be evicted if the<=
br>
&gt; ancestor transaction was evicted).=C2=A0 Default: 1000<br>
&gt;<br>
&gt; Max descendant size : No transaction shall be accepted if it would cau=
se<br>
&gt; another transaction in the mempool to have the total size of all its<b=
r>
&gt; descendant transactions be too great.=C2=A0 Default : maxmempool / 200=
=C2=A0 =3D=C2=A0 2.5MB<br>
&gt;<br>
&gt; The third limit is required to make sure calculating the state require=
d<br>
&gt; for sorting and limiting the mempool and enforcing the first 2 limits =
is<br>
&gt; computationally feasible:<br>
&gt;<br>
&gt; Max number of ancestor txs:=C2=A0 No transaction shall be accepted if =
it has<br>
&gt; too many ancestor transactions which are not yet confirmed (ie, in the=
<br>
&gt; mempool). Default: 100<br>
&gt;<br>
&gt; The fourth limit is required to maintain the pre existing policy goal<=
br>
&gt; that all transactions in the mempool should be mineable in the next bl=
ock.<br>
&gt;<br>
&gt; Max ancestor size: No transaction shall be accepted if the total size =
of<br>
&gt; all its unconfirmed ancestor transactions is too large.=C2=A0 Default:=
 1MB<br>
&gt;<br>
&gt; (All limits include the transaction itself.)<br>
&gt;<br>
&gt; For reference, these limits would have affected less than 2% of<br>
&gt; transactions entering the mempool in April or May of this year.=C2=A0 =
During<br>
&gt; the period of 7/6 through 7/14, while the network was under stress tes=
t,<br>
&gt; as many as 25% of the transactions would have been affected.<br>
&gt;<br>
&gt; The code to implement the descendant package tracking and new policy<b=
r>
&gt; limits can be found in 6557<br>
&gt; &lt;<a href=3D"https://github.com/bitcoin/bitcoin/pull/6557" rel=3D"no=
referrer" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/6557</a=
>&gt; which is built off of 6470.<br>
&gt;<br>
&gt; Thanks,<br>
&gt; Alex<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
&gt;<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>

--001a113eeccaeb8799052160feaf--