I quickly looked it up and it seems that bitcoind has a function PaysMoreThanConflicts which checks that the tx pays a higher feerate than the replaced tx. This isn't a BIP125 rule AFAICT so I think that's what tripped me up. That means I'm wrong about the ancestor bulking variant as a malicious counterparty can put a high feerate splice tx at the bottom of the mempool, requiring a higher feerate to replace it.
On Wed, Aug 10, 2022 at 12:31 PM Greg Sanders <gsander...@gmail.com> wrote: > 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 <elzei...@gmail.com> 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 <gsander...@gmail.com> >> 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 <elzei...@gmail.com> >>> 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@lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >>>> >>>
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
