From elzeigel at gmail.com Wed Aug 10 16:20:10 2022 From: elzeigel at gmail.com (Eugene Siegel) Date: Wed, 10 Aug 2022 12:20:10 -0400 Subject: [Lightning-dev] Splice Pinning Prevention w/o Anchors In-Reply-To: References: Message-ID: 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 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 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: