[bitcoin-dev] Why not Child-Pays-For-Parent?

Alex Morcos morcos at gmail.com
Fri Jul 10 17:51:00 UTC 2015

I think the biggest problem with merging CPFP right now is that at least in
its current implementation it is not efficient enough in certain

On Fri, Jul 10, 2015 at 1:02 PM, Justus Ranvier <
justus at openbitcoinprivacyproject.org> wrote:

> On 07/10/2015 11:31 AM, Jeff Garzik wrote:
> > This is a good explanation but it does not address reachability.  TX_a,
> the
> > first tx sent out on the network, presumably has insufficient fee to get
> > mined - which also means it did not necessarily even reach all miners.
> >
> > Simply sending out TX_b with added fee does not guarantee that nodes
> > suddenly have TX_a, which they may have ignored/dropped before.
> I'm not sure why that's actually a problem.
> CPFP is initiated by the recipient of the parent transaction, and so if
> the recipient is creating this transaction in the first place they must
> have a copy of the parent transaction which can/should broadcast at the
> same time.
> If the child reaches a CPFP miner, then presumably the parents made it
> as well (any path between the sender and the miner that doesn't relay
> the parent should reject the child as trying to spend non-existent
> coins), so both of the transactions can be mined at the same time.
> --
> Justus Ranvier
> Open Bitcoin Privacy Project
> http://www.openbitcoinprivacyproject.org/
> justus at openbitcoinprivacyproject.org
> E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150710/4b36fab9/attachment.html>

More information about the bitcoin-dev mailing list