Eugene Siegel [ARCHIVE] on Nostr: 📅 Original date posted:2022-08-10 📝 Original message: Hi, I think the ancestor ...

📅 Original date posted:2022-08-10
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220810/667a9a6b/attachment.html>;