From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 81AD7B1F for ; Mon, 8 May 2017 16:33:44 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ua0-f171.google.com (mail-ua0-f171.google.com [209.85.217.171]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9B2B318D for ; Mon, 8 May 2017 16:33:43 +0000 (UTC) Received: by mail-ua0-f171.google.com with SMTP id z47so45793355uaz.0 for ; Mon, 08 May 2017 09:33:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=rWtysE6Ks1uW6V/TwcbN2MBSglEu6gYrLQrLujAp0eI=; b=lGiO0ezpU8tW60PXW9XykoYweRiFRf8QFvPAmH/qoRExnvBg4ib/MBYBzqtqU1eR6q TE+guh0Qs7W+juw2aO+Fs9IcCyfoKgRmr/+XS0GLZxgMxwpBAqh0ISteiGKVJzPvKSmk 9lNyYbGrE/zhqIYTgW3h8Zu8IG9yaALfL6kjp4QloKLJWeatXllUJhzj9MV3zMH0uwFz X6dbPZr86+d+ZlC/3m3m7Bt24eaQRZw0FOSClJLKcv1buDIe870+YG5J6ZdxQa4AwJ9e 8zWXwnKK4zDM1qsb6r60bcM3lPe7uCIDTL1FMwQq/2Nn8/9SdTxgflm2JrJi+J0XqAGi 0ZUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=rWtysE6Ks1uW6V/TwcbN2MBSglEu6gYrLQrLujAp0eI=; b=jFaPSaljZzUoG+tuuMw/Jt82p1untG9Tsr57iA3oH/TB1K1+rXr7WCv0N+Obu5mbHb BgsLt8552cI+mBFkUjwNFMzlPP+pp7hFd59ZIixVDXZCGZRD6b5HLerYzJ1nEbPI023V xhrf/0qtF9IK3rhTRVOxFNfuN1RJOdF4YAbD+OVqVJarWz7YuFs1yKe6kZUmyNEtKldB DGqSWtD5G6N+SJRkqDG0OZv2kY71cTOwmVB0SIjxzUpQmDz4Ds03mrT6zFru5EwB3HFt YX7HCLg5jpbn6Ok9i6q4PZ9UjpdKM0p1RLxDclsBaCrTQ2eyylOmA7cIfiJPgVI1BMcF lt0w== X-Gm-Message-State: AN3rC/5CGJSKvm1g+m/TEy9tPl0PhyyHgq7YFaFVKZYC9YmILt2fFbED 3w8NCd2eKS5cHr4mLdAiyswDCphiOZ+M X-Received: by 10.176.74.66 with SMTP id r2mr14092617uae.39.1494261222593; Mon, 08 May 2017 09:33:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.40.196 with HTTP; Mon, 8 May 2017 09:33:42 -0700 (PDT) In-Reply-To: References: From: Suhas Daftuar Date: Mon, 8 May 2017 12:33:42 -0400 Message-ID: To: DJ Bitcoin Content-Type: multipart/alternative; boundary=f403045f88f65fd7e0054f05cdde X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham 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 17:15:55 +0000 Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 16:33:44 -0000 --f403045f88f65fd7e0054f05cdde Content-Type: text/plain; charset=UTF-8 Hi, I've moved the bitcoin-dev list to bcc:, as this question is better suited to forums dedicated to Bitcoin Core implementation specifics, rather than the general bitcoin development list. Please feel free in the future to ask questions like this on the bitcoin-core-dev mailing list (https://lists.linuxfoundation .org/mailman/listinfo/bitcoin-core-dev) or on the #bitcoin-core-dev freenode IRC channel. The work limit (that was put in place in https://github.com/bitcoin/ bitcoin/pull/6654, when the concept of "dirty" entries was introduced) was removed in https://github.com/bitcoin/bitcoin/pull/7594, in preparation for ancestor-feerate-mining. So those comments should have been cleaned up to match the new code. Please feel free to file an issue or open a PR to update those comments at https://github.com/bitcoin/bitcoin. Thanks, Suhas On Mon, May 8, 2017 at 5:38 AM, DJ Bitcoin via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi Guys, > > I have a question about the use of txmempool. find attached the code in > txmempool.h > > > ====================================================== > /* Adding transactions from a disconnected block can be very time > consuming, > * because we don't have a way to limit the number of in-mempool > descendants. > * To bound CPU processing, we limit the amount of work we're willing to do > * to properly update the descendant information for a tx being added from > * a disconnected block. If we would exceed the limit, then we instead > mark > * the entry as "dirty", and set the feerate for sorting purposes to be > equal > * the feerate of the transaction without any descendants. */ > > class CTxMemPoolEntry > { > private: > // ... > // Information about descendants of this transaction that are in the > // mempool; if we remove this transaction we must remove all of these > // descendants as well. if nCountWithDescendants is 0, treat this entry > as > // dirty, and nSizeWithDescendants and nModFeesWithDescendants will not > be > // correct. > > int64_t nCountWithDescendants; //!< number of descendant transactions > // ... > ====================================================== > > > Now, the only place where nCountWithDescendants is modified is the > following (txmempool.cpp): > > > ====================================================== > void CTxMemPoolEntry::UpdateDescendantState(int64_t modifySize, CAmount > modifyFee, int64_t modifyCount) > { > nSizeWithDescendants += modifySize; > assert(int64_t(nSizeWithDescendants) > 0); > nModFeesWithDescendants += modifyFee; > nCountWithDescendants += modifyCount; > assert(int64_t(nCountWithDescendants) > 0); > } > ====================================================== > > > Therefore, nCountWithDescendants is never zero. > Am i missing something? Where is this concept of "dirty" defined? > > Thanks a lot, > DJ > > > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --f403045f88f65fd7e0054f05cdde Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I've moved the bitcoin-dev list= to bcc:, as this question is better suited to forums dedicated to Bitcoin = Core implementation specifics, rather than the general bitcoin development = list.=C2=A0=C2=A0

Please feel free in the future t= o ask questions like this on the bitcoin-core-dev mailing list (https://lists.linuxfoundation.org/mailman/listinfo/bitcoin= -core-dev) or on the #bitcoin-core-dev freenode IRC channel.
=

The work limit (that was put in place in https://github= .com/bitcoin/bitcoin/pull/6654, when the concept of "dirty&qu= ot; entries was introduced) was removed=C2=A0in=C2=A0https://github.com/bitcoin/bitcoin/pull/7594, in preparation for ancestor-feerate-mining= .=C2=A0 So those comments should have been cleaned up to match the new code= .

Please feel free to file an issue or open a PR t= o update those comments at https://github.com/bitcoin/bitcoin.
Thanks,
Suhas
=C2=A0

On Mon, May 8, 2017 at 5= :38 AM, DJ Bitcoin via bitcoin-dev <bitcoin-dev@lists.= linuxfoundation.org> wrote:
Hi Guys,
=C2=A0
I have a question about the use of txmempool. find attached the code i= n txmempool.h
=C2=A0
=C2=A0
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
/* Adding transactions from a disconnected block can be very time cons= uming,
=C2=A0* because we don't have a way to limit the number of in-mempool d= escendants.
=C2=A0* To bound CPU processing, we limit the amount of work we're will= ing to do
=C2=A0* to properly update the descendant information for a tx being added = from
=C2=A0* a disconnected block.=C2=A0 If we would exceed the limit, then we i= nstead mark
=C2=A0* the entry as "dirty", and set the feerate for sorting pur= poses to be equal
=C2=A0* the feerate of the transaction without any descendants. */

class CTxMemPoolEntry
{
=C2=A0 =C2=A0private:
=C2=A0 =C2=A0// ...=C2=A0=C2=A0 =C2=A0
=C2=A0 =C2=A0// Information about descendants of this transaction that= are in the
=C2=A0 =C2=A0// mempool; if we remove this transaction we must remove all o= f these
=C2=A0 =C2=A0// descendants as well. if nCountWithDescendants is 0, tr= eat this entry as
=C2=A0 =C2=A0// dirty, and nSizeWithDescendants and nModFeesWithDescendants= will not be
=C2=A0 =C2=A0// correct.
=C2=A0 =C2=A0
=C2=A0 =C2=A0int64_t nCountWithDescendants; //!< number of descenda= nt transactions
=C2=A0 =C2=A0// ...
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0
=C2=A0
Now, the only place where=C2=A0nCountWithDescendants is modified is th= e following (txmempool.cpp):
=C2=A0
=C2=A0
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
void CTxMemPoolEntry::UpdateDescendantState(int64_t modifySize, CAmoun= t modifyFee, int64_t modifyCount)
{
=C2=A0 =C2=A0 nSizeWithDescendants +=3D modifySize;
=C2=A0 =C2=A0 assert(int64_t(nSizeWithDescendants) > 0);
=C2=A0 =C2=A0 nModFeesWithDescendants +=3D modifyFee;
=C2=A0 =C2=A0 nCountWithDescendants +=3D modifyCount;
=C2=A0 =C2=A0 assert(int64_t(nCountWithDescendants) > 0);
}
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0
=C2=A0
Therefore,=C2=A0nCountWithDescendants is never zero.
Am i missing something? Where is this concept of "dirty" def= ined?
=C2=A0
Thanks a lot,
DJ
=C2=A0
=C2=A0
=C2=A0
=C2=A0
=C2=A0

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev


--f403045f88f65fd7e0054f05cdde--