> I think this mitigation requires reliable access to the UTXO set
In this case, how about just setting nsequence to the value 1? UTXO may not
exist, but maybe that's ok since it means it cannot pin the commitment tx.
> If this concern is correct, I'm not sure we have a current good solution,
Hi Dustin,
>From my understanding, splice pinning is problematic for channel funds
safety. In the sense once you have a splice floating in network mempools
and your latest valid commitment transaction pre-signed fees isn't enough
to replace the splice, lack of confirmation might damage the claim
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
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
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
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
> 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
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
As raised by @crypto-iq and @roasbeef, splices which permit arbitrary
script and input inclusion are at risk of being mempool pinned. Here we
present a solution to this splice pinning problem.
## Background
Pinning can be done by building a very large “junk” transaction that spends
from an
