В 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) _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
