pull down to refresh

Did not know until reading this that there is an upper-limit on the number of HTLC's per on-chain tx (483). Is there any mechanism in LN implementations that close channels once this number is hit? Or is that even necessary?
reply
Warning: this is mostly from memory and deduction than me referencing an implementation.
Closing channels shouldn't affect this number - these just apply to pending HTLCs afaik and a peer won't forward any more HTLCs once this number is hit (at least this is how I image an impl handles the condition). I might be mistaken but I think this limit relates to how many outputs you can fit into an on-chain tx. Once HTLCs settle, new commitment txs are formed between channel peers, ie theses HTLCs are integrated into their channel balance rather than being a separate output, so they can begin accepting more again.
reply
Is there an update that goes over how PTLCs will mitigate some of these issues
reply
afaik PTLCs primarily help with payment de-correlation along a route - all hops see a different preimage rather than share one like the current version. There might be further ramifications but it's mostly a privacy and security enhancement.
reply
damn so there is still no good alternative to the transaction bottleneck caused by HTLCs. this seems like the biggest threat to btc scaling.