From: Matt Whitlock <bip@mattwhitlock.name>
To: Jeff Garzik <jgarzik@gmail.com>
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: <CADm_Wcaed61oWMGu_FVCeRUWOS6jfFvGwNGEwh9GymfrqgtQKQ@mail.gmail.com>
References: <6D3AACE5-D6CD-4785-8A55-F6DF0B94D927@ricmoo.com>
	<CAAUFj12JC1e7wY1M-_U_Kh5wQv8V4X0SeGGtONn7m8PcOEhp_Q@mail.gmail.com>
	<CADm_Wcaed61oWMGu_FVCeRUWOS6jfFvGwNGEwh9GymfrqgtQKQ@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Why not Child-Pays-For-Parent?
Precedence: list

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 <dkbryant@gmail.com> 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 <michabailey@gmail.com>
> > 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.