Eugene Siegel [ARCHIVE] on Nostr: ð Original date posted:2022-08-10 ð Original message: I quickly looked it up ...
ð
Original date posted:2022-08-10
ð Original message:
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 <gsanders87 at 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 <elzeigel at 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 <gsanders87 at 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 <elzeigel at 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 at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220810/547ba05f/attachment.html>;
ð Original message:
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 <gsanders87 at 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 <elzeigel at 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 <gsanders87 at 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 <elzeigel at 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 at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220810/547ba05f/attachment.html>;