This is done by adding a layer of in-direction with regards to how HTLCs are manifested within the commitment transactions. The technique involves adding a new 2-of-2 multi-sig output to the commitment transactions, called an HTLC indirect block, which is then spent by a new transaction that actually creates the HTLC outputs, called an HTLC block. With this change, the cost to have a commitment mined in the chain is now independent of the number of HTLCs in the channel. Different flavors of this technique are possible as well, allowing both sides to craft varying HTLC indirection trees which may factor in traits like HTLC expiration time.Jeremy Rubin, another contributor to the Lightning Protocol, weighed in on the issue of congestion control and suggested BIP-119 Congestion Control trees could help mitigate this issue. By bucketing a tree through a histogram of HTLC size, small HTLCs can live in a common CTV subtree and not interfere with higher value HTLCs. Additionally, sequencing can prevent long chains in the mempool until they're above a certain value.Antoine Riard, yet another contributor to the Lightning Protocol, discussed a vulnerability related to "Flood & Loot" attacks and the unbounded commitment transaction size inflation. He recommended capping commitment size to ensure competitive propagation/block selection and limiting HTLC exposure. Riard also discussed other potential solutions such as dynamic dust_limit based on HTLC economic value, feerate of its output, feerate of HTLC-transaction, feerate estimation of any CPFP to bump it, encoding all HTLC in some Taproot tree in the future, switching fee from pre-committed ones to a single-party dynamic one, and hinting in the readme file about where and how people can disclose attacks and vulnerabilities.Finally, there was some discussion about fee futures and how they could help with this issue. The conversation also touched on the need for a hint in the readme file about where and how people can disclose attacks and vulnerabilities.