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 0457FBB6 for ; Sun, 12 Jul 2015 10:18:51 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from resqmta-po-10v.sys.comcast.net (resqmta-po-10v.sys.comcast.net [96.114.154.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A5537E9 for ; Sun, 12 Jul 2015 10:18:50 +0000 (UTC) Received: from resomta-po-03v.sys.comcast.net ([96.114.154.227]) by resqmta-po-10v.sys.comcast.net with comcast id rNJp1q0014ueUHc01NJpqb; Sun, 12 Jul 2015 10:18:49 +0000 Received: from crushinator.localnet ([IPv6:2601:186:c000:825e:e9f4:8901:87c7:24a0]) by resomta-po-03v.sys.comcast.net with comcast id rNJn1q00A4eLRLv01NJppR; Sun, 12 Jul 2015 10:18:49 +0000 From: Matt Whitlock To: Jeff Garzik Date: Sun, 12 Jul 2015 06:18:47 -0400 Message-ID: <4773632.c9JArRaIev@crushinator> User-Agent: KMail/4.14.10 (Linux/4.0.5-gentoo; KDE/4.14.10; x86_64; ; ) In-Reply-To: References: <6D3AACE5-D6CD-4785-8A55-F6DF0B94D927@ricmoo.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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 Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] Why not Child-Pays-For-Parent? X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2015 10:18:51 -0000 I keep seeing (on /r/bitcoin) mentions of a 24-hour or 48-hour (varying accounts) interval at which miners clear their mempools. Is this a matter of local policy or something Bitcoin Core does by design? On Saturday, 11 July 2015, at 5:29 pm, Jeff Garzik wrote: > It sounds like you are seeking transaction expiration from the mempool, not > CPFP. > > On Sat, Jul 11, 2015 at 4:30 PM, Dan Bryant wrote: > > > I think a compromise will be somewhere in the middle. I think most people > > would be OK with TXs that don't have enough fees for P2P transfer to stay > > in deadmans land. Most people are stuck in a situation where they payed > > enough to get it into (and keep it in) the pool, but not enough to get it > > out. > > > > If we could get CPFP that only worked on TXs that met the minimum > > threshold for peer propagation, then I think we would be in much better > > position to battle this spam flood. > > > > On Sat, Jul 11, 2015 at 3:28 PM, Micha Bailey > > wrote: > > > >> Right. The issue (AIUI) is that, right now, even though transactions are > >> evaluated for inclusion as a group with CPFP, they're not yet evaluated for > >> relaying as a unit, nor can they be, because the current p2p protocol > >> doesn't have a way to send multiple transactions in a single protocol > >> message to signify that they should be evaluated together.