rich1.0npub139lamalg6mww4czepk75anugudczcglp8p9ej9kafmkvgxyk4uus7mvj0jhttps://nostr.ae/npub139lamalg6mww4czepk75anugudczcglp8p9ej9kafmkvgxyk4uus7mvj0jnjumphttps://nostr.ae📅 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>