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
|
Return-Path: <bitcoin42@mail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 8AC3DB2A
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 8 May 2017 09:38:17 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mout.gmx.com (mout.gmx.com [74.208.4.201])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 26916E5
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 8 May 2017 09:38:17 +0000 (UTC)
Received: from [213.1.222.238] by 3capp-mailcom-lxa09.server.lan (via HTTP);
Mon, 8 May 2017 11:38:16 +0200
MIME-Version: 1.0
Message-ID: <trinity-a411f282-fb6a-4a08-9f17-55abd7762499-1494236296205@3capp-mailcom-lxa09>
From: "DJ Bitcoin" <bitcoin42@mail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: text/html; charset=UTF-8
Date: Mon, 8 May 2017 11:38:16 +0200
Importance: normal
Sensitivity: Normal
X-Priority: 3
X-Provags-ID: V03:K1:KrpcJzQyvtXnnMtS2KeADGsH7TyHRXNUt4r2f0ZICPl
IkfiCJI/jFganG3aF6tBxvPhpszIsfyE9Wawpq9TkfPBG6Ew1b
1D71BG3IobYWJlTfrF3aYcjcJkhI/1Tbvth0W/n0KfhYvi0T0V
5oPof20TfGWWI7D5Qt7K1sQUamwxAPKcGVQVrevv5tq3LyHQij
wRSM859LpbnNC+MlHRnqXG9UZ214t7+wuBBJR7l9ndFVd6Rs0A
p8B62kKKD1fxID1ksjId8oJcUguu/lWjokB1eNvOVI7gGpgHDy
kUBgoUIf4FCdd0QFRcVvGVOAOid
X-UI-Out-Filterresults: notjunk:1;V01:K0:oPIB9rb/bsU=:kdCfZbFR0seZj7zvqBLj+3
QWsEf/eSeRSXqVgYwL2ctoqaX/ifM3vf20AlFfk4S6FMCsjfjeiJhwxVaQzRAUspSB5SCY0Mu
ytSkfRKuF8ADraYGKG+hMhgNycGI68F/3UQikDe7+lP5DB93jHyeHcRZjdhgFaLwmmWd/QLos
7ao9MkSNrLDLqcJ+oghqO6JAGZLjJ6JrSagQkBMPax979bm5Zgv16G7gQsTmYezahb7NkX6qs
D16kE7sDdYUetI9yp6hloW0eHD3EpBr6TrvanQddJy2hozhKjOj4amm+Ep7X10aoqItDGcue2
fDZvf4W5sFjur0YbPv/2GMo/T7fyL5vJmRmvXBZK6XBoD2t89Ft+QIYRTatyGtE4J5OWFKMdp
Ot5f87X6gU7vaHebQ/HkhX4W1/WTy/a7EwAXaObf9L5Wnmr7azlL2Cx09nio3SFYCeV9luSpY
3RXYm0GImw==
X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,
FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,MIME_HTML_ONLY,
RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Mon, 08 May 2017 10:54:22 +0000
Subject: [bitcoin-dev] TXMempool and dirty entries
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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, 08 May 2017 09:38:17 -0000
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div style="font-family: Verdana;font-size: 12.0px;">
<div style="font-family: Verdana;font-size: 12.0px;">
<div>Hi Guys,</div>
<div> </div>
<div>I have a question about the use of txmempool. find attached the code in txmempool.h</div>
<div> </div>
<div> </div>
<div>======================================================</div>
<div>
<div>/* Adding transactions from a disconnected block can be very time consuming,<br/>
* because we don't have a way to limit the number of in-mempool descendants.<br/>
* To bound CPU processing, we limit the amount of work we're willing to do<br/>
* to properly update the descendant information for a tx being added from<br/>
* a disconnected block. If we would exceed the limit, then we instead mark<br/>
* the entry as "dirty", and set the feerate for sorting purposes to be equal<br/>
* the feerate of the transaction without any descendants. */</div>
<div><br/>
class CTxMemPoolEntry</div>
<div>{</div>
<div> private:</div>
<div> // ... </div>
<div> // Information about descendants of this transaction that are in the<br/>
// mempool; if we remove this transaction we must remove all of these</div>
<div> // descendants as well. if nCountWithDescendants is 0, treat this entry as<br/>
// dirty, and nSizeWithDescendants and nModFeesWithDescendants will not be</div>
<div> // correct.<br/>
</div>
<div> int64_t nCountWithDescendants; //!< number of descendant transactions<br/>
// ...</div>
<div>
<div>======================================================</div>
<div> </div>
<div> </div>
<div>Now, the only place where nCountWithDescendants is modified is the following (txmempool.cpp):</div>
<div> </div>
<div>
<div> </div>
<div>======================================================</div>
void CTxMemPoolEntry::UpdateDescendantState(int64_t modifySize, CAmount modifyFee, int64_t modifyCount)<br/>
{<br/>
nSizeWithDescendants += modifySize;<br/>
assert(int64_t(nSizeWithDescendants) > 0);<br/>
nModFeesWithDescendants += modifyFee;<br/>
nCountWithDescendants += modifyCount;<br/>
assert(int64_t(nCountWithDescendants) > 0);<br/>
}</div>
<div>
<div>======================================================</div>
<div> </div>
<div> </div>
<div>Therefore, nCountWithDescendants is never zero.</div>
<div>Am i missing something? Where is this concept of "dirty" defined?</div>
<div> </div>
<div>Thanks a lot,</div>
<div>DJ</div>
</div>
</div>
<div> </div>
</div>
<div> </div>
<div> </div>
<div> </div>
<div> </div>
</div>
</div></div></body></html>
|
