<unnamed>

Public Key

npub139lamalg6mww4czepk75anugudczcglp8p9ej9kafmkvgxyk4uus7mvj0j

Profile Code

nprofile1qqsgjl7a7l5ddh82upvsm02we7ywxupvy0snsjuezmw5amxyrzt27wgprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hszrthwden5te0dehhxtnvdakqd50yza

Publishing to

relay.snort.social

relay.damus.io

nos.lol

Last Notes

2023-06-09 15:06:40 CEST

- reply

📅 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>

2023-06-09 15:06:40 CEST

- reply

📅 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>

2023-06-09 15:06:39 CEST

- reply

📅 Original date posted:2022-08-10
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220810/667a9a6b/attachment.html>

2023-06-09 15:02:23 CEST

- reply

📅 Original date posted:2021-04-26
📝 Original message:
Lnd counts dust + trimmed HTLCs towards max_accepted_htlcs. We definitely
shouldn't be counting dust towards that amount. I would have to think more
about the issue where it's not possible to lower the feerate though. That
seems like a spec issue?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210426/cf896556/attachment.html>

2023-06-09 15:02:22 CEST

- reply

📅 Original date posted:2021-04-23
📝 Original message:
Thanks for replying.
I was under the impression that long-term update_fee was going to be
removed since second-level HTLC txn's can bring their own fees?
On Fri, Apr 23, 2021 at 12:24 PM Bastien TEINTURIER <bastien at acinq.fr>
wrote:
> Hi Eugene,
>
> The reason dust HTLCs count for the 483 HTLC limit is because of
> `update_fee`.
> If you don't count them and exceed the 483 HTLC limit, you can't lower the
> fee anymore
> because some HTLCs that were previously dust won't be dust anymore and you
> may end
> up with more than 483 HTLC outputs in your commitment, which opens the
> door to other
> kinds of attacks.
>
> This is the first issue that comes to mind, but there may be other
> drawbacks if we dig into
> this enough with an attacker's mindset.
>
> Bastien
>
> Le ven. 23 avr. 2021 à 17:58, Eugene Siegel <elzeigel at gmail.com> a écrit :
>
>> I propose a simple mitigation to increase the capital requirement of
>> channel-jamming attacks. This would prevent an unsophisticated attacker
>> with low capital from jamming a target channel. It seems to me that this
>> is a *free* mitigation without any downsides (besides code-writing), so I'd
>> like to hear other opinions.
>>
>> In a commitment transaction, we trim dust HTLC outputs. I believe that
>> the reason for the 483 HTLC limit each side has in the spec is to prevent
>> commitment tx's from growing unreasonably large, and to ensure they are
>> still valid tx's that can be included in a block. If we don't include dust
>> HTLCs in this calculation, since they are not on the commitment tx, we
>> still allow 483 (x2) non-dust HTLCs to be included on the commitment tx.
>> There could be a configurable limit on the number of outstanding dust
>> HTLCs, but the point is that it doesn't affect the non-dust throughput of
>> the channel. This raises the capital requirement of channel-jamming so
>> that each HTLC must be non-dust, rather than spamming 1 sat payments.
>>
>> Interested in others' thoughts.
>>
>> Eugene (Crypt-iQ)
>> _______________________________________________
>> 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/20210423/5765f8e9/attachment.html>