Author: Ariel Luaces 2021-07-02 05:39:44
Published on: 2021-07-02T05:39:44+00:00
The Lightning Network (LN) has been evolving rapidly, with new features and best practices being developed on the app layer. However, integrating these innovations into the BOLT process has been challenging. The BOLTs are essentially one big BIP that must be followed strictly to ensure a node is interoperable with the network. Any alternatives or optional features should be extracted out of BOLTs and written as BIPs. bLIPs promote more loosely coupled evolution of the network by providing a descriptive home for standards such as path finding heuristics, fee bumping heuristics, breach retribution handling, channel management, rebalancing, custom records usage, JIT channel opening, hosted channels, randomized channel IDs, fee optimization, initial channel boostrapping, etc.The bLIP process is different from BIPs in that it has a more widely distributed group of editors/maintainers. The automatic assignment of proposal numbers in bLIPs removes responsibility and power from the maintainers and reduces friction, eliminating a possible bikeshedding vector. While BOLTs can be reserved for prescriptive measures such as HTLCs. Historically, BOLTs have had a rather monolithic structure, with the same 11 documents being used for the past few years. By having distinct documents for proposals/standards, bLIPs allow each new standard/proposal to be more effectively explained, motivated, versioned, etc.However, there are barriers to participating in BOLTs, which could be perceived as more "consensus critical," not subject to change, and more people should be strongly encouraged to write specs for new lightning features elsewhere (like the BIP repo). Laolu believes that a new repo would create more confusion. Instead, he suggests rethinking the current process of the BOLTs to make it more accessible for new ideas to find their way into the BOLTs. This would resolve the issue of growing BOLTs.To address this issue, over the last couple of months, discussions have taken place regarding the idea of adding a Bitcoin Lightning Improvement Proposal-style (bLIP) process on top of the BOLTs with various members of the community. This would not affect the existing BOLT process at all but simply add a place for app layer best practices to be succinctly described and organized, especially those that require coordination. Some potential bLIP ideas that people have mentioned 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.The proposed bLIP process is based on BIP-0002 and is designed to bring features built outside of the BOLT process today into the fold, instead of leaving them buried in old ML posts or not documented at all. If the community is interested in moving forward, a branch has been started describing such a process. It would be great to have developers from various implementations and from the broader app layer ecosystem volunteer to be listed as editors. The Lightning-dev mailing list is where Ryan Gentry posted his message about the bLIP process, and this list can be used by anyone who wants to learn more about the Lightning Network and participate in its development.
Updated on: 2023-06-03T04:56:19.222728+00:00