Date: Mon, 8 Jun 2020 12:15:11 +0500
From: Dmitry Petukhov <dp@simplexum.com>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <20200608121511.4dbadea8@simplexum.com>
In-Reply-To: <CAD5xwhjhcSDX_e8RFHveOdEEwC6YTe8kPaUw_egKkrdE0fVe1w@mail.gmail.com>
References: <CAD5xwhjXidpeLLUr4TO30t7U3z_zUxTpU9GBpLxu3MWX3ZFeTA@mail.gmail.com>
 <1cQUGt1pX0_lWPJm-tFDr9fQCvrPd5vqmCorgN89jy7gUF0m9wsouUosrFm1eal3jO9oB1BvMtORGE2htLdFjyDD5lno_QkXCFn971LQNZY=@protonmail.com>
 <CAD5xwhhZyAkQE3DpLku_xrOnixL344AqkWB=+a=fOBbekobY6g@mail.gmail.com>
 <20200608110545.078f8e81@simplexum.com>
 <CAD5xwhjhcSDX_e8RFHveOdEEwC6YTe8kPaUw_egKkrdE0fVe1w@mail.gmail.com>
Organization: simplexum.com
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] [was BIP OP_CHECKTEMPLATEVERIFY] Fee Bumping
 Operation
Precedence: list

=D0=92 Sun, 7 Jun 2020 23:43:39 -0700
Jeremy via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

> > PFN transaction would still be valid if some of 'ghost parents' are
> > =20
> already confirmed, so the miners could have more fees than strictly
> necessary. But this is the same as with CPFP.
>=20
> This is problematic and can't be done as it requires a new index of
> all past txns for consensus.

If the logic would match CPFP, then PFN would be valid if some of the
'ghost parents' are confirmed, but would be invalid if some of them are
spent. I believe in this case txindex won't be required.

> My thinking is that a Fee Bump transaction can name a list of TXIDs
> (Or one TXID which implies all ancestors of) that it wishes to be
> included in a block with. It must be included in that block. A Fee
> Bump transaction may have no unconfirmed ancestors nor any children.
> Potentially, it also may not be RBF'd. You treat the Fee Bump
> Transactions as the lowest descendant of whatever it targets and then
> set it's feerate/total fee based on the package that would have to
> co-confirm for it to be worth mining. This makes it sort like normal
> transactions for inclusion. You can require some minimums for mempool
> inclusion at all.
>=20
> If it's target is confirmed or replaced, it should drop from the
> mempool.

Re "may not be RBF'd": What if the sender of PFN tx wants to increase
the fee it offers for the 'ghost parents'? RBF-ing PFN tx itself seems
like less wasteful way than RBF-ing some of the parents/'ghost parents'
just for this purpose. Sometimes I think the sender of PFN will not be
even able to replace any other transactions beside their own PFN tx
(like when they offer 'fee bumping' service for others)