Eugene Siegel [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2021-04-23 to 2022-08-10
💬 Posted a total of 9 messages
📚 Participated in the following categories: Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 13:06:40

- 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 13:06:40

- 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 13:06:39

- 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 13:05:29

- reply

📅 Original date posted:2022-03-15
📝 Original message:
I'm not familiar with miniscript besides that it's a subset of script - how
would it help avoiding an unintended path being taken?
On Fri, Mar 11, 2022 at 8:47 AM darosior <darosior at protonmail.com> wrote:
> Also, using Miniscript (whether in Segwit v0 or v1) would prevent this
> kind of surprises. And many potential others. :-)
>
>
> I'll post something soon about how we could integrate Miniscript in
> Lightning.
> -------- Original Message --------
> On Mar 10, 2022, 2:55 PM, Eugene Siegel < elzeigel at gmail.com> wrote:
>
>
> Yes I think bip342 should solve it. Maybe splitting up all conditionals
> into leaves is a good idea for taproot lightning
>
> On Mon, Mar 7, 2022 at 5:46 PM Antoine Riard <antoine.riard at gmail.com>
> wrote:
>
>> Hi Eugene,
>>
>> > Since the remote party gives them a signature, after the timeout, the
>> offering party can
>> claim with the remote's signature + preimage, but can only spend with the
>> HTLC-timeout transaction because of SIGHASH_ALL.
>>
>> I've not exercised the witness against our test framework though the
>> description sounds to me correct.
>>
>> The offering counterparty spends the offered HTLC output with a
>> HTLC-timeout transaction where the witness is <<remote_sig>
>> <payment_preimage>>. SIGHASH_ALL is not committing to the spent Script
>> branch intended to be used. As you raised, it doesn't alleviate the
>> offering counterparty to respect the CLTV delay and as such the offered
>> HTLC timespan cannot be shortened. The implication I can think of, in case
>> of competing HTLC race, once the absolute timelock is expired, the offering
>> counterparty is able to compete against the receiving one with a more
>> feerate-efficient witness. However, from a receiving counterparty safety
>> viewpoint, if you're already suffering a contest, it means your HTLC-claim
>> on your own local commitment transaction inbound HTLC output has been
>> inefficient, and your fee-bumping strategy is to blame.
>>
>> If we think the issue is relevant, I believe splitting the Script
>> branches in two tapleaves and having bip342 signature digest committing to
>> the tapleaf_hash solves it.
>>
>> Antoine
>>
>> Le lun. 7 mars 2022 à 15:27, Eugene Siegel <elzeigel at gmail.com> a écrit :
>>
>>> I'm not sure if this is known, but I'm pretty sure it's benign and so I
>>> thought I'd share since I found it interesting and maybe someone else will
>>> too. I'm not sure if this is already known either.
>>>
>>>
>>> https://github.com/lightning/bolts/blob/master/03-transactions.md#offered-htlc-outputs
>>> Offered HTLCs have three claim paths: the revocation case, the offerer
>>> claiming through the HTLC-timeout transaction, and the receiver claiming
>>> via their sig + preimage. The offering party can claim via the HTLC-timeout
>>> case on their commitment transaction with their signature and the remote's
>>> signature (SIGHASH_ALL) after the cltv_expiry timeout. Since the remote
>>> party gives them a signature, after the timeout, the offering party can
>>> claim with the remote's signature + preimage, but can only spend with the
>>> HTLC-timeout transaction because of SIGHASH_ALL. This assumes that the
>>> remote party doesn't claim it first. I can't think of any cases where the
>>> offering party would know the preimage AND want to force close, so that's
>>> why I think it's benign. It does make the witness smaller. The same trick
>>> isn't possible with the Received HTLC's due to OP_CHECKLOCKTIMEVERIFY.
>>>
>>> Eugene (Crypt-iQ on github)
>>> _______________________________________________
>>> 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/20220315/f3f7ac11/attachment.html>

2023-06-09 13:05:28

- reply

📅 Original date posted:2022-03-10
📝 Original message:
Yes I think bip342 should solve it. Maybe splitting up all conditionals
into leaves is a good idea for taproot lightning
On Mon, Mar 7, 2022 at 5:46 PM Antoine Riard <antoine.riard at gmail.com>
wrote:
> Hi Eugene,
>
> > Since the remote party gives them a signature, after the timeout, the
> offering party can
> claim with the remote's signature + preimage, but can only spend with the
> HTLC-timeout transaction because of SIGHASH_ALL.
>
> I've not exercised the witness against our test framework though the
> description sounds to me correct.
>
> The offering counterparty spends the offered HTLC output with a
> HTLC-timeout transaction where the witness is <<remote_sig>
> <payment_preimage>>. SIGHASH_ALL is not committing to the spent Script
> branch intended to be used. As you raised, it doesn't alleviate the
> offering counterparty to respect the CLTV delay and as such the offered
> HTLC timespan cannot be shortened. The implication I can think of, in case
> of competing HTLC race, once the absolute timelock is expired, the offering
> counterparty is able to compete against the receiving one with a more
> feerate-efficient witness. However, from a receiving counterparty safety
> viewpoint, if you're already suffering a contest, it means your HTLC-claim
> on your own local commitment transaction inbound HTLC output has been
> inefficient, and your fee-bumping strategy is to blame.
>
> If we think the issue is relevant, I believe splitting the Script branches
> in two tapleaves and having bip342 signature digest committing to the
> tapleaf_hash solves it.
>
> Antoine
>
> Le lun. 7 mars 2022 à 15:27, Eugene Siegel <elzeigel at gmail.com> a écrit :
>
>> I'm not sure if this is known, but I'm pretty sure it's benign and so I
>> thought I'd share since I found it interesting and maybe someone else will
>> too. I'm not sure if this is already known either.
>>
>>
>> https://github.com/lightning/bolts/blob/master/03-transactions.md#offered-htlc-outputs
>> Offered HTLCs have three claim paths: the revocation case, the offerer
>> claiming through the HTLC-timeout transaction, and the receiver claiming
>> via their sig + preimage. The offering party can claim via the HTLC-timeout
>> case on their commitment transaction with their signature and the remote's
>> signature (SIGHASH_ALL) after the cltv_expiry timeout. Since the remote
>> party gives them a signature, after the timeout, the offering party can
>> claim with the remote's signature + preimage, but can only spend with the
>> HTLC-timeout transaction because of SIGHASH_ALL. This assumes that the
>> remote party doesn't claim it first. I can't think of any cases where the
>> offering party would know the preimage AND want to force close, so that's
>> why I think it's benign. It does make the witness smaller. The same trick
>> isn't possible with the Received HTLC's due to OP_CHECKLOCKTIMEVERIFY.
>>
>> Eugene (Crypt-iQ on github)
>> _______________________________________________
>> 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/20220310/dbf38c56/attachment.html>

2023-06-09 13:05:27

- reply

📅 Original date posted:2022-03-07
📝 Original message:
I'm not sure if this is known, but I'm pretty sure it's benign and so I
thought I'd share since I found it interesting and maybe someone else will
too. I'm not sure if this is already known either.
https://github.com/lightning/bolts/blob/master/03-transactions.md#offered-htlc-outputs
Offered HTLCs have three claim paths: the revocation case, the offerer
claiming through the HTLC-timeout transaction, and the receiver claiming
via their sig + preimage. The offering party can claim via the HTLC-timeout
case on their commitment transaction with their signature and the remote's
signature (SIGHASH_ALL) after the cltv_expiry timeout. Since the remote
party gives them a signature, after the timeout, the offering party can
claim with the remote's signature + preimage, but can only spend with the
HTLC-timeout transaction because of SIGHASH_ALL. This assumes that the
remote party doesn't claim it first. I can't think of any cases where the
offering party would know the preimage AND want to force close, so that's
why I think it's benign. It does make the witness smaller. The same trick
isn't possible with the Received HTLC's due to OP_CHECKLOCKTIMEVERIFY.
Eugene (Crypt-iQ on github)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220307/b2eda6a8/attachment.html>

2023-06-09 13:02:23

- 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 13:02:22

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

2023-06-09 13:02:22

- reply

📅 Original date posted:2021-04-23
📝 Original message:
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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210423/28a7f555/attachment.html>

2023-06-09 12:40:01

- reply

2023-06-09 12:40:00

- reply

2023-06-09 12:39:59

- reply