public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Tier Nolan <tier.nolan@gmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Why not Child-Pays-For-Parent?
Date: Fri, 10 Jul 2015 18:28:14 +0100	[thread overview]
Message-ID: <CAE-z3OWvrhXzE907Ano+KPV28obDL3PdFCUCs7KzD09qNsFfAw@mail.gmail.com> (raw)
In-Reply-To: <CADm_WcYQLzqQLY-Dspd1jUtF9Z=_721TReoc_eKYk5JCQ4fejg@mail.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 --]

      parent reply	other threads:[~2015-07-10 17:28 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-10 16:09 [bitcoin-dev] Why not Child-Pays-For-Parent? Richard Moore
2015-07-10 16:13 ` Jeff Garzik
2015-07-10 16:25   ` Richard Moore
2015-07-10 16:26     ` Dan Bryant
2015-07-10 16:28 ` Tier Nolan
2015-07-10 16:31   ` Jeff Garzik
2015-07-10 17:02     ` Justus Ranvier
2015-07-10 17:16       ` Dan Bryant
2015-07-10 17:51       ` Alex Morcos
2015-07-10 19:39         ` Tier Nolan
2015-07-10 21:10           ` Luke Dashjr
2015-07-11 20:28             ` Micha Bailey
2015-07-11 21:30               ` Dan Bryant
2015-07-11 22:29                 ` Jeff Garzik
2015-07-12 10:18                   ` Matt Whitlock
2015-07-11 23:19                 ` Tier Nolan
2015-07-10 17:28     ` Tier Nolan [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAE-z3OWvrhXzE907Ano+KPV28obDL3PdFCUCs7KzD09qNsFfAw@mail.gmail.com \
    --to=tier.nolan@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox