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

[Tier Nolan <tier.nolan@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1072 bytes --]

On Fri, Jul 10, 2015 at 5:31 PM, Jeff Garzik <jgarzik@gmail.com> 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.
>

When the peer adds both parent and child to the memory pool, it should
forward both of them.

CPFP inherently requires that nodes keep transactions that they have
rejected due to low fees.

If peers requested parents, then it would be possible to forward them
onwards.

If a node receives a high-fee transaction and doesn't have the parent, it
could request the parent.

Spam protection could be handled by banning nodes which send lots of
"children" and then never having the parent to the transaction.

The rule would be that forwarding a transaction means that you have all its
parents back to transactions contained in blocks.

[-- Attachment #2: Type: text/html, Size: 1684 bytes --]