Greg Sanders [ARCHIVE] on Nostr: 📅 Original date posted:2022-08-10 📝 Original message: > I think the ancestor ...
📅 Original date posted:2022-08-10
📝 Original message:
> 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 <elzeigel at gmail.com> 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
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220810/cedb54f6/attachment.html>;
📝 Original message:
> 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 <elzeigel at gmail.com> 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
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220810/cedb54f6/attachment.html>;