{"type":"rich","version":"1.0","author_name":"npub139lamalg6mww4czepk75anugudczcglp8p9ej9kafmkvgxyk4uus7mvj0j","author_url":"https://nostr.ae/npub139lamalg6mww4czepk75anugudczcglp8p9ej9kafmkvgxyk4uus7mvj0j","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-08-10\n📝 Original message:\nHi,\n\nI think the ancestor bulking variant of pinning only matters if you are\ntrying to add a new descendant and can't due to the ancestor/descendant\nlimits. In this  example, since all of the outputs are locked with `1\nOP_CSV`, you can't add a descendant to the splice tx. The ancestor bulking\nalso shouldn't matter for RBF since you wouldn't be replacing any of the\nancestors, only the splice tx. I think it might matter if the new funding\noutput isn't encumbered.\n\nThe new funding output can't have `1 OP_CSV` unless we also change the\ncommit tx format, and I'm not sure if it would work. The commit tx has the\ndisable bit set in nSequence so it isn't compatible with the sequence lock.\nEnabling the bit might be tricky since then the commit tx may have a\ntime-based or block-based locktime based on the lower bits of the obscured\ncommitment number, and it must be block-based (and non-zero) for the\nsequence lock to work. That means if it's not encumbered, pinning exists\nsince an attacker can make a junk tree using the anchor output. It is\nreplaceable using RBF since you have your own commit tx (with anchor) to\nbroadcast.\n\nEugene\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220810/667a9a6b/attachment.html\u003e"}