Greg Sanders [ARCHIVE] on Nostr: 📅 Original date posted:2022-08-10 📝 Original message: Your reading is correct. ...
📅 Original date posted:2022-08-10
📝 Original message:
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/7ae290f0/attachment-0001.html>;
📝 Original message:
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/7ae290f0/attachment-0001.html>;