Author: Bastien TEINTURIER 2021-07-01 09:19:09
Published on: 2021-07-01T09:19:09+00:00
The Lightning Network community is considering using Bitcoin Improvement Proposals (BIPs) and Bolt Improvements Proposals (bLIPs) to promote loosely coupled evolution of the network. BIPs are for Bitcoin-wide changes, while bLIPs can be a descriptive home for optional standards, and BOLTs can be reserved for prescriptive measures. However, some concerns have been raised about the use of bLIPs, including fragmentation, maintenance costs, and backwards-compatibility issues. To prevent collisions on feature bits, tlv fields, and messages, bLIPs should be centralized, with a process to assign them and ensure they don't collide.There is also a discussion around the need for a clear process around bLIPs. Some members suggested that the current BOLTs could be rethought to make it more accessible for new ideas to find their way into the BOLTs rather than creating bLIPs. Recently, a discussion on the Lightning-dev mailing list highlighted the need to improve the BOLT process that handles features and best practices for the Lightning Network. The proposal is to add a BIP-style process known as bLIPs on top of the existing BOLTs. This would provide a place for app layer best practices to be succinctly described and organized, especially those that require coordination, which are currently being built outside of the BOLT process today. 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. Developers from various implementations and from the broader app layer ecosystem have been encouraged to volunteer as editors. The idea has been positively received by both app layer and protocol developers.However, some participants in the discussion expressed concerns about adding a new repository, stating that it may create more confusion. They suggested that all the points that are addressed could very well be formalized into BOLTs instead and the current process of the BOLTs should be rethought to make it more accessible for new ideas to find their way into the BOLTs. The recent discussion around zero-conf channels provides an opportunity to discuss how the BOLT process handles features and best practices that arise in the wild vs. originating within the process itself. Zero-conf channels are one of many Lightning Network innovations on the app layer that have struggled to make their way into the spec. In an ideal world, there would be a descriptive design document that the app layer implementers had collaborated on over the years that the spec group could then pick up and merge into the BOLTs now that the feature is deemed spec-worthy. Several companies have launched their own implementations of zero-conf channels, including John Carvalho and Bitrefill's Turbo channels and Breez's solution posted on the mailing list for feedback in August 2020.
Updated on: 2023-06-03T04:40:05.127988+00:00