Author: Bastien TEINTURIER 2021-07-02 08:00:32
Published on: 2021-07-02T08:00:32+00:00
The Lightning Network community is discussing the possibility of adding a Bitcoin Lightning Improvement Proposal (bLIP) process on top of the existing BOLT process. The aim of this new process would be to provide a place for app layer best practices to be described and organized, especially those that require coordination. The proposed bLIP process will not affect the existing BOLT process but rather add a way to bring features being built outside of the BOLT process into the fold.The Lightning Network protocol already has extensions such as TLVs, message types, feature bits, etc., that allow implementations to spin out their own sub-protocols. However, there is discussion on whether to centralize these extensions and assign them to prevent collisions. In order to address this, BIPs, SPARKS, and bLIPs have been proposed, with bLIPs serving as a descriptive home for optional functionality that has organically evolved over time. Bastien agrees that these solutions add more freedom to experiment in the real world, which helps find issues and correct them. He also notes that some bLIPs may be sub-optimal solutions to the problems they try to solve and may put users' funds at risk.Some believe the centralized extensions should be inside the spec repository, while others see value in having a separate bLIP repository. Some argue that all the points addressed in this discussion could very well be formalized into BOLTs, and the current process needs to be made more accessible for new ideas to find their way into the BOLTs. Ultimately, the Lightning Network community seeks to promote more loosely coupled evolution of the network.As bLIPs and BOLTs continue to evolve and change, they may organically reference each other or change mandates from optional to mandatory. By having distinct documents for proposals/standards, bLIPs and BOLTs can be more effectively explained, motivated, versioned, and maintained over time. The Lightning Network community encourages developers from various implementations and from the broader app layer ecosystem to volunteer to be editors in the proposed bLIP process. Some potential bLIP ideas include each lnurl variant, on-the-fly channel opens, AMP, dynamic commitments, podcast payment metadata, p2p messaging formats, new pathfinding heuristics, remote node connection standards, etc.However, there are concerns about collisions on assigning feature bits, inserting new TLV fields in existing messages, or creating new messages. It is expected that bLIPs adopt the amendment of BOLT 9 to define feature bits they use. Already, forks of implementations are using "undocumented" TLVs or feature bits, and there have been no disastrous collisions in the wild. Bastien is mostly in favor of bLIPs but highlights that it will add fragmentation to the network, maintenance costs, and backwards-compatibility issues.
Updated on: 2023-06-03T04:46:33.249017+00:00