From: Dmitry Petukhov <dp@simplexum•com>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] [was BIP OP_CHECKTEMPLATEVERIFY] Fee Bumping Operation
Date: Mon, 8 Jun 2020 12:15:11 +0500 [thread overview]
Message-ID: <20200608121511.4dbadea8@simplexum.com> (raw)
In-Reply-To: <CAD5xwhjhcSDX_e8RFHveOdEEwC6YTe8kPaUw_egKkrdE0fVe1w@mail.gmail.com>
В 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
> >
> already confirmed, so the miners could have more fees than strictly
> necessary. But this is the same as with CPFP.
>
> 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.
>
> 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)
prev parent reply other threads:[~2020-06-08 7:12 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-26 1:50 [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY Jeremy
2019-11-27 21:32 ` Russell O'Connor
2019-11-28 19:59 ` Jeremy
2019-12-11 0:37 ` Jeremy
2019-12-13 23:06 ` Jeremy
2019-12-19 20:08 ` Jeremy
[not found] ` <20191214122546.5e72eb93@simplexum.com>
[not found] ` <CAD5xwhgwhOwuPjKz-0_y7HP=jTi=6wJo8uH6HqCvOndr6wo0+Q@mail.gmail.com>
2020-02-14 11:18 ` Dmitry Petukhov
2020-02-14 19:16 ` Jeremy
2020-09-03 14:42 ` Dmitry Petukhov
2020-09-03 17:34 ` Jeremy
2020-09-03 17:47 ` Jeremy
2020-02-15 0:24 ` ZmnSCPxj
2020-06-07 16:51 ` Joachim Strömbergson
2020-06-07 22:45 ` Jeremy
2020-06-08 6:05 ` Dmitry Petukhov
2020-06-08 6:43 ` [bitcoin-dev] [was BIP OP_CHECKTEMPLATEVERIFY] Fee Bumping Operation Jeremy
2020-06-08 7:15 ` Dmitry Petukhov [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=20200608121511.4dbadea8@simplexum.com \
--to=dp@simplexum$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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