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
|
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 BDB577A
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 14 Aug 2015 19:33:33 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f170.google.com (mail-io0-f170.google.com
[209.85.223.170])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4066031
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 14 Aug 2015 19:33:32 +0000 (UTC)
Received: by iodt126 with SMTP id t126so95542698iod.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 14 Aug 2015 12:33:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:date:message-id:subject:from:to:content-type;
bh=5PB2NiENR0KjCr7+4ucsfeUdQnRVyRINBsGpDKLOKKw=;
b=C9WlzuNUJW4xZXicdQraWqEWvuHc3X5ndCyhEWizQE5drZ/97mdOMbRYMBpGR1Rcx2
HWZF2gOovO5la63LXR5fId0S7Zc4loe6aIx8BexmBu/xStOBXCkB3rnjteikskGIQch1
Q3smQNgwJDgtYqXzX3ppkZ1TR9Na3hz2mScrAvmBUGUjOk7OND4j+5QyTUWiKrCZeMTT
qJmt6O1wVry5ZJHlceiSwJiwDY2HpiJqxUfxAD2H8ag7fF2X2I/MjLnPyWfRq5/7GFWT
0SqeAii3N6wTVKbTYGvL5cy05buZIQAb8yK4Jjbg+xfbfWlaSVtcPZxlGyn96Jnf0Z6z
PGyQ==
MIME-Version: 1.0
X-Received: by 10.107.132.73 with SMTP id g70mr8494818iod.14.1439580811627;
Fri, 14 Aug 2015 12:33:31 -0700 (PDT)
Received: by 10.64.241.137 with HTTP; Fri, 14 Aug 2015 12:33:31 -0700 (PDT)
Date: Fri, 14 Aug 2015 15:33:31 -0400
Message-ID: <CAPWm=eWuvC8zYM_ipAnaQttKQQG2Vas6np_bAFkxG31eR5w=xQ@mail.gmail.com>
From: Alex Morcos <morcos@gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a113f93d4e712fe051d4a8680
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
Subject: [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: Fri, 14 Aug 2015 19:33:33 -0000
--001a113f93d4e712fe051d4a8680
Content-Type: text/plain; charset=UTF-8
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
--001a113f93d4e712fe051d4a8680
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi everyone,<br><br><br>I'd like to propose a new set =
of requirements as a policy on when to accept new transactions into the mem=
pool and relay them.=C2=A0 This policy would affect transactions which have=
as inputs other transactions which are not yet confirmed in the blockchain=
.<br><br>The motivation for this policy is <a href=3D"https://github.com/bi=
tcoin/bitcoin/pull/6470">6470</a> which aims to limit the size of a mempool=
. =C2=A0<a href=3D"https://github.com/bitcoin/bitcoin/pull/6470#issuecommen=
t-125324736">As discussed in that pull</a>, 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.=C2=A0 In order to make sure this is always feasible, I'm proposin=
g 4 new policy limits.<div><br></div><div>All limits are command line confi=
gurable.<br><br>The first two limits are required to make sure no chain of =
transactions will be too large for the eviction code to handle:<br><br>Max =
number of descendant txs : No transaction shall be accepted if it would cau=
se another transaction in the mempool to have too many descendant transacti=
ons (all of which would have to be evicted if the ancestor transaction was =
evicted).=C2=A0 Default: 1000<br><br>Max descendant size : No transaction s=
hall be accepted if it would cause another transaction in the mempool to ha=
ve the total size of all its descendant transactions be too great.=C2=A0 De=
fault : maxmempool / 200 =C2=A0=3D =C2=A02.5MB<br><br>The third limit is re=
quired to make sure calculating the state required for sorting and limiting=
the mempool and enforcing the first 2 limits is computationally feasible:<=
br><br>Max number of ancestor txs: =C2=A0No transaction shall be accepted i=
f it has too many ancestor transactions which are not yet confirmed (ie, in=
the mempool). Default: 100<br><br>The fourth limit is required to maintain=
the pre existing policy goal that all transactions in the mempool should b=
e mineable in the next block.<br><br>Max ancestor size: No transaction shal=
l be accepted if the total size of all its unconfirmed ancestor transaction=
s is too large.=C2=A0 Default: 1MB<br><br>(All limits include the transacti=
on itself.)<br><br>For reference, these limits would have affected less tha=
n 2% of transactions entering the mempool in April or May of this year.=C2=
=A0 During the period of 7/6 through 7/14, while the network was under stre=
ss test, as many as 25% of the transactions would have been affected.<br><b=
r></div><div>The code to implement the descendant package tracking and new =
policy limits can be found in <a href=3D"https://github.com/bitcoin/bitcoin=
/pull/6557">6557</a> which is built off of 6470.<br><br></div><div>Thanks,<=
/div><div>Alex</div><div><br></div></div>
--001a113f93d4e712fe051d4a8680--
|
