delvingbitcoin
Combined summary - Pluggable Channel Factories
The discussion highlights the integration and potential challenges of implementing channel factories within the Lightning Network, emphasizing the necessity for plugins to monitor unilateral exits from these factories.
It acknowledges that while the base node software will continue to monitor the blockchain for channels, the closure of a factory layer does not necessarily impede the operation of its hosted channels, which can still function directly onchain. However, the complexity arises when a factory's closure also leads to the termination of its channels, particularly in edge cases such as timeouts or forced shutdowns, necessitating a mechanism for the plugin to communicate with the base node software to disregard an in-factory channel.
The conversation further explores the concept of generalizing gossip in the Lightning Network, proposing a method where nodes demonstrate shared control over onchain funds to validate their capability to host channels. This approach stems from the need to limit the size of the network's public channel announcements, ensuring they are backed by unspent transaction outputs (UTXOs) to prevent spamming. The proposal suggests prioritizing this change in gossip protocol to facilitate the inclusion of channels within factories, though it is currently deemed out of scope in favor of focusing on the foundational protocol for channel factories.
An alternative to traditional channel factories, termed "sidepools," is introduced, aiming to blend the benefits of onchain N=2 mechanisms with offchain N>2 mechanisms. This innovation allows for efficient liquidity management through "just-in-time" rebalancing, leveraging the reliability of public forwarding nodes and existing pathfinding algorithms without necessitating changes to the current gossip protocol.
The email also reflects on the technical intricacies of developing "pluggable channel factories," which would allow for the seamless integration of offchain-hosted channels into the Lightning Network's existing node software. This includes addressing the complexities of managing channel states amidst the operational dynamics of channel factories, drawing parallels to the process of channel splicing. The proposed solution advocates for adapting splicing techniques, such as quiescing channels and transitioning between old and new factory states using modified commitment messages, to ensure the stability and functionality of channels within these factories.