From gsanders87 at gmail.com Wed Aug 10 16:31:20 2022 From: gsanders87 at gmail.com (Greg Sanders) Date: Wed, 10 Aug 2022 12:31:20 -0400 Subject: [Lightning-dev] Splice Pinning Prevention w/o Anchors In-Reply-To: References: Message-ID: Your reading is correct. My example was that if TxB, size 100vB with feerate 1000 sat/vbyte, has an 100kvB ancestor paying 1 sat/vbyte. The effective package rate for those two transactions will be (100*1,000 + 100,000*1)/(100,000 + 100) = ~2 sat/vybte This means TxB will not be picked up if the prevailing rate is > 2 sat/byte. Let's say it's 4 sat/vbyte prevailing rate. To replace it with TxB', one still has to pay to evict TxB, at roughly 1000/4=250 times the normal feerate. Sorry if I got the math wrong here, but at least trying to get the idea across. On Wed, Aug 10, 2022 at 12:20 PM Eugene Siegel wrote: > 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: