In this vector, I'm pretty sure feerate/total fee pinning is the same issue. Even if you don't have to increase feerate, you have to pay for 100*1000=100,000 sats due to rule#3.
There's been some work trying to document the exact replacement behavior implemented in core since it has drifted so much, and the feerate one would be "rule#6" in the doc: https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md Making sure inputs are confirmed completely mitigates this, so I'm guessing it's not much of an issue. On Wed, Aug 10, 2022 at 2:03 PM Eugene Siegel <elzei...@gmail.com> wrote: > 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
