Eugene Siegel [ARCHIVE] on Nostr: ð Original date posted:2022-08-10 ð Original message: Looking it up, rule 3 is ...
ð
Original date posted:2022-08-10
ð Original message:
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/d2cd3edd/attachment.html>;
ð Original message:
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/d2cd3edd/attachment.html>;