<blockquote>
<p>Are there any significant hurdles preventing us from using multiple penalty transactions, where the nth penalty transaction spends HTLCs [n*483; (n+1)*483[ from the commitment transaction? At first sight, it seems like quite a straightforward upgrade.</p>
</blockquote>
<p>If the only goal is to increase the maximum number of HTLC outputs, the above solution doesn't have any hurdles of which I'm aware.  I believe it's something LN devs have discussed before, for example in <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-October/001455.html" rel="nofollow noreferrer">this post</a> I believe it's what's being called &quot;commitment fan out&quot;.</p>
<p>However, it's probably worth noting that most LN implementations currently limit the maximum number of pending HTLCs well below 483 for various reasons, such as:</p>
<ul>
<li><a href="https://bitcoinops.org/en/newsletters/2020/06/24/#ln-fee-ransom-attack" rel="nofollow noreferrer">LN fee ransom attack</a>, leading CLN and Eclair to lower their max HTLCs to 30.  See also the <a href="https://github.com/lightningnetwork/lnd/pull/4527" rel="nofollow noreferrer">PR</a> where LND made this configurable.</li>
<li>Mass closure attacks (described in the original LN paper) where Mallory can get a large number of channels to all be forced closed at the same time, making them compete against each other for block space, raising fees massively and possibly leading to some channels not closing on time.  More HTLC outputs per channel means (in the worst case) more data per channel so fewer channels need to be forced closed for the attack to become viable.</li>
<li><a href="https://bitcoinops.org/en/topics/channel-jamming-attacks/" rel="nofollow noreferrer">Channel jamming attacks</a>, which isn't made relatively worse by having more HTLC outputs available, but just makes the absolute number of blocked HTLCs higher</li>
</ul>
<p>Another consideration is that it's possible for two peers to have more than 483 HTLC slots between them by simply opening a second channel between themselves.  When forwarding a payment, they can then use whichever channel they prefer, not necessarily the one requested by the payment creator (e.g. they can use a different one of their channels for liquidity reasons).  This has most of the advantages of the nested-HTLCs you propose (and all of the downsides described here previously) and doesn't require any changes to the protocol.</p>
<p>In short, I think the approach you describe is possible but there isn't high demand for more than 483 slots per channel, and what demand exists is being met using alternative approaches.</p>

CC BY-SA 4.0
2023-02-26T03:38:19.570Z
2023-02-26T03:38:19.570Z
David A. Harding
<p>Pre-eltoo a penalty (or justice) transaction is stored for every commitment transaction in case a revoked commitment transaction is broadcast by the counterparty. If each commitment transaction required multiple (e.g. x) penalty transactions to sweep all the funds that would multiply the storage requirements by that factor of x and require multiple transactions to be confirmed on the blockchain in a timely fashion. It would be possible but far from ideal.</p>
<p>Post eltoo there are no penalty transactions, the latest commitment transaction can spend the outputs from the revoked commitment transaction so everything has to be a standalone commitment transaction.</p>

CC BY-SA 4.0
2023-02-08T17:00:47.520Z
Having multiple penalty transactions doesn't really change the on-chain scaling behaviour much. For any meaningful number of HTLCs, the transaction overhead is already negligible compared to the combined witness size of spending all the HTLCs.

The per-transaction compute and storage requirements would indeed scale linearly with the number of penalty txs, but only affects the two channel partners - and can be a worthwhile trade-off for partners that prefer to have more HTLCs on their channel, e.g. in a semi-trusted relationship, I think?
stickies-v
CC BY-SA 4.0
2023-02-08T16:26:01.843Z
2023-02-08T16:26:01.843Z
Michael Folkson
<p><a href="https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#rationale-7" rel="nofollow noreferrer">BOLT#2</a> states the below as one rationale to limit a Lighting Network channel to 483 HTLCs:</p>
<blockquote>
<p>It also ensures that a single penalty transaction can spend the entire commitment transaction, as calculated in BOLT #5.</p>
</blockquote>
<p>In other words: we're constrained by the maximum size (according to standardness rules) of the <em>penalty</em> transaction. With a P2WSH output being 43 bytes, the <em>commitment</em> transaction could accommodate a significantly higher number of outputs (and thus, HTLCs) and stay within the max (standardness) size of 400,000 WU. Are there any significant hurdles preventing us from using multiple penalty transactions, where the <code>nth</code> penalty transaction spends HTLCs <code>[n*483; (n+1)*483[</code> from the commitment transaction? At first sight, it seems like quite a straightforward upgrade.</p>
<p><em>To keep the questions focused, let's ignore the other rationale of 483 signatures fitting in a single <code>commitment_signed</code> message.</em></p>
<p>Related question (and very useful answer): <a href="https://bitcoin.stackexchange.com/questions/93720/lightning-network-how-was-the-maximum-allowed-htlcs-in-flight-computed/93763#93763">Lightning Network: How was the maximum allowed HTLCs in flight computed?</a></p>

<lightning-network><hash-time-locked-contract><p2wsh><ln-penalty-transaction><ln-commitment-transaction>
Using multiple penalty transactions to increase max HTLCs per LN channel
stickies-v
# Using multiple penalty transactions to increase max HTLCs per LN channel

(Asked by: username_0 on 2023-02-08)

[BOLT#2](https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#rationale-7) states the below as one rationale to limit a Lighting Network channel to 483 HTLCs:

> It also ensures that a single penalty transaction can spend the entire commitment transaction, as calculated in BOLT #5.

In other words: we're constrained by the maximum size (according to standardness rules) of the *penalty* transaction. With a P2WSH output being 43 bytes, the *commitment* transaction could accommodate a significantly higher number of outputs (and thus, HTLCs) and stay within the max (standardness) size of 400,000 WU. Are there any significant hurdles preventing us from using multiple penalty transactions, where the `nth` penalty transaction spends HTLCs `[n*483; (n+1)*483[` from the commitment transaction? At first sight, it seems like quite a straightforward upgrade.

*To keep the questions focused, let's ignore the other rationale of 483 signatures fitting in a single `commitment_signed` message.*

Related question (and very useful answer): [Lightning Network: How was the maximum allowed HTLCs in flight computed?](https://bitcoin.stackexchange.com/questions/93720/lightning-network-how-was-the-maximum-allowed-htlcs-in-flight-computed/93763#93763)

**Tags:** lightning-network, hash-time-locked-contract, p2wsh, ln-penalty-transaction, ln-commitment-transaction


---

## 2 answers

### Answer by username_1 on 2023-02-26. Score: 1 | Accepted answer

> Are there any significant hurdles preventing us from using multiple penalty transactions, where the nth penalty transaction spends HTLCs [n\*483; (n+1)\*483[ from the commitment transaction? At first sight, it seems like quite a straightforward upgrade.

If the only goal is to increase the maximum number of HTLC outputs, the above solution doesn't have any hurdles of which I'm aware. I believe it's something LN devs have discussed before, for example in [this post](https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-October/001455.html) I believe it's what's being called "commitment fan out".

However, it's probably worth noting that most LN implementations currently limit the maximum number of pending HTLCs well below 483 for various reasons, such as:

* [LN fee ransom attack](https://bitcoinops.org/en/newsletters/2020/06/24/#ln-fee-ransom-attack), leading CLN and Eclair to lower their max HTLCs to 30. See also the [PR](https://github.com/lightningnetwork/lnd/pull/4527) where LND made this configurable.
* Mass closure attacks (described in the original LN paper) where Mallory can get a large number of channels to all be forced closed at the same time, making them compete against each other for block space, raising fees massively and possibly leading to some channels not closing on time. More HTLC outputs per channel means (in the worst case) more data per channel so fewer channels need to be forced closed for the attack to become viable.
* [Channel jamming attacks](https://bitcoinops.org/en/topics/channel-jamming-attacks/), which isn't made relatively worse by having more HTLC outputs available, but just makes the absolute number of blocked HTLCs higher

Another consideration is that it's possible for two peers to have more than 483 HTLC slots between them by simply opening a second channel between themselves. When forwarding a payment, they can then use whichever channel they prefer, not necessarily the one requested by the payment creator (e.g. they can use a different one of their channels for liquidity reasons). This has most of the advantages of the nested-HTLCs you propose (and all of the downsides described here previously) and doesn't require any changes to the protocol.

In short, I think the approach you describe is possible but there isn't high demand for more than 483 slots per channel, and what demand exists is being met using alternative approaches.


---

### Answer by username_2 on 2023-02-08. Score: 0

Pre-eltoo a penalty (or justice) transaction is stored for every commitment transaction in case a revoked commitment transaction is broadcast by the counterparty. If each commitment transaction required multiple (e.g. x) penalty transactions to sweep all the funds that would multiply the storage requirements by that factor of x and require multiple transactions to be confirmed on the blockchain in a timely fashion. It would be possible but far from ideal.

Post eltoo there are no penalty transactions, the latest commitment transaction can spend the outputs from the revoked commitment transaction so everything has to be a standalone commitment transaction.

> **Comments:**
> **username_0**: Having multiple penalty transactions doesn't really change the on-chain scaling behaviour much. For any meaningful number of HTLCs, the transaction overhead is already negligible compared to the combined witness size of spending all the HTLCs.  The per-transaction compute and storage requirements would indeed scale linearly with the number of penalty txs, but only affects the two channel partners - and can be a worthwhile trade-off for partners that prefer to have more HTLCs on their channel, e.g. in a semi-trusted relationship, I think?  

---

