Author: Ryan Gentry 2021-07-07 21:28:45
Published on: 2021-07-07T21:28:45+00:00
In a recent discussion on the lightning-dev and bitcoin-dev mailing lists, developers discussed the potential introduction of bLIPs (Bitcoin Lightning Improvement Proposals) as a new process to avoid waiting for review and consensus when proposing changes to the BIPs (Bitcoin Improvement Proposals) and BOLTs (Basis of Lightning Technology). Some developers expressed concern that adding more acronyms and processes could fragment the network and erode the value of existing processes. However, others argued that bLIPs could provide more freedom to experiment with new features in the real world, while centralizing them in a repo could prevent conflicts with other BOLTs or bLIPs.The email chain discusses the nuts-and-bolts side of implementing bLIPs, including the need to assign feature bits, insert new TLV fields in existing messages, and create new messages without causing collisions. To achieve this, bLIPs must be centralized, and a clear process must be established to assign and ensure they do not collide. The details of where bLIPs should live are up for debate, but they must be easy to find, browse, and preferably inside the spec repository.While BOLTs are currently prescriptive and specify what base functionality is required for a routing node, there is a gap in describing functionality that has emerged over time due to progressive evolution and enhances node/wallet operation. Examples include 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 bootstrapping, and more. The discussion suggests that using bLIPs to address these optional features could promote more loosely coupled evolution of the network.The Lightning Network Protocol has evolved over time with the implementation of extensions such as TLVs, message types, and feature bits that allow implementations to create sub-protocols. While these extensions are not required for node operation, they have been developed to solve user experience and operational problems. To address this evolution, Laolu proposes using bLIPs as descriptive documents for these types of standards while BOLTs can be reserved for prescriptive measures.Ryan Gentry suggests adding a Bitcoin Lightning Improvement Proposal (bLIP) process on top of the BOLTs to succinctly describe and organize app layer best practices that require coordination. This would not affect the existing BOLT process, but rather add a place for app layer innovations to be brought into the fold. Potential bLIP ideas include on-the-fly channel opens, podcast payment metadata, p2p messaging formats, and remote node connection standards. The proposed bLIP process is based on BIP-0002 and aims to bring in developers from various implementations and the broader app layer ecosystem to volunteer as editors.René Pickhardt notes that there has always been some form of invisible barrier to participate in the BOLTs. However, he believes that all points addressed in Ryan's email could very well be formalized into BOLTs, and the current process of the BOLTs should be rethought to make it more accessible for new ideas. Additionally, Rene suggests referencing the BOLTs on the Lightning Network website and in the whitepaper as the place to learn about the Lightning Network.In a recent discussion, members of the Lightning development community have agreed that the current BOLT process has reached its limits. While there is general agreement that adding a simple home for descriptive design documents focusing on new LN features would be a good thing and augment the prescriptive BOLTs, there are concerns about how this interacts with the existing BIP system, as well as how the BOLTs interact with the BIP system. Some believe that BOLTs and bLIPs should be BIPs, but others feel that this introduces large scope creep over what was originally a pretty simple proposal.Ultimately, it does not matter where these design documents exist, only that there is a standard format and that LN developers and users feel empowered to create them and share them with the broader ecosystem. While some believe that a breeding process on top of Lightning sounds like a good way forward, others think it might be better to take time to operate the disentanglement nicely. One possible solution proposed is dynamic commitments, which could make a lot of sense to be well-designed and well-supported by every implementation. Another orthogonal point to consider is the existence of already higher-layer protocol specifications such as the dlcspecs. Even if the ecosystem is still in the bootstrap phase for now, we already have a discussion to split between a "consensus" track and more optional features. The BOLT Process Wishlist sounds great and can be addressed independently. If recruits for merging the BOLTs can be found, the mechanics of a merge can be tackled then. The question remains about how to draw both communication and software interfaces in-between.
Updated on: 2023-06-03T04:53:17.317931+00:00