Looking it up, rule 3 is "The replacement transaction pays an absolute fee of at least the sum paid by the original transactions." but here the ancestors aren't getting replaced so I don't think the replacement has to pay for them? Or maybe your comment was just generally about how it can matter in certain cases
On Wed, Aug 10, 2022 at 12:06 PM Greg Sanders <[email protected]> wrote: > > I think the ancestor bulking variant of pinning only matters if you are > trying to add a new descendant and can't due to the ancestor/descendant > limits. > > Not quite. It also matters if you want to RBF that transaction, since low > feerate ancestor junk puts the transaction at the bottom of the mempool, so > to speak, even if it has a high feerate itself. You are forced to pay "full > freight" to replace it via bip125 rule#3 even though it's not going to be > mined. > > (I don't know if that applies here, just noting the wrinkle) > > On Wed, Aug 10, 2022 at 11:37 AM Eugene Siegel <[email protected]> wrote: > >> Hi, >> >> I think the ancestor bulking variant of pinning only matters if you are >> trying to add a new descendant and can't due to the ancestor/descendant >> limits. In this example, since all of the outputs are locked with `1 >> OP_CSV`, you can't add a descendant to the splice tx. The ancestor bulking >> also shouldn't matter for RBF since you wouldn't be replacing any of the >> ancestors, only the splice tx. I think it might matter if the new funding >> output isn't encumbered. >> >> The new funding output can't have `1 OP_CSV` unless we also change the >> commit tx format, and I'm not sure if it would work. The commit tx has the >> disable bit set in nSequence so it isn't compatible with the sequence lock. >> Enabling the bit might be tricky since then the commit tx may have a >> time-based or block-based locktime based on the lower bits of the obscured >> commitment number, and it must be block-based (and non-zero) for the >> sequence lock to work. That means if it's not encumbered, pinning exists >> since an attacker can make a junk tree using the anchor output. It is >> replaceable using RBF since you have your own commit tx (with anchor) to >> broadcast. >> >> Eugene >> _______________________________________________ >> Lightning-dev mailing list >> [email protected] >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> >
_______________________________________________ Lightning-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
