bLIPs: A proposal for community-driven app layer and protocol extension standardization



Summary:

The Lightning Network community is reflecting on its specification process, specifically the limitations of the current BOLT process. While the success of BOLT in creating a distributed ecosystem of thousands of nodes worldwide is celebrated, recent IRC meetings have expressed frustrations with the process. As a solution, dynamic commitments are proposed as an idea that could make sense to be well-designed and well-supported by every implementation to deploy safer channel types. It is suggested that a new specification process does not completely share the same communication infrastructure as the BOLTs, like having them in the same repository, as it might spread the belief among public perception that those standards have been "blessed" in any way by LN devs and have been through the same thoroughness of design and review process.Additionally, the discussion amongst Lightning Network developers raised concerns regarding the implementation of Bitcoin Lightning Improvement Proposals (bLIPs). Some developers fear that the creation of bLIPs could lead to increased fragmentation in the network and deployment of sub-optimal solutions, although others believe that it would provide more freedom to experiment in the real world. Despite these concerns, some developers felt that bLIPs could address the need for implementers to specify optional features in their sub-protocols, which would benefit users who want support for a particular feature. However, it was acknowledged that bLIPs do not completely solve the issue of properly reviewing spec proposals, which remains an ongoing challenge for large open source projects.The Lightning Network community is discussing the benefits and drawbacks of introducing Bitcoin Lightning Improvement Proposals (bLIPs), which would provide a more flexible way to evolve the network by allowing for optional features to be added outside of the main specification. Some members have expressed support for bLIPs, noting that they could promote real-world experimentation and collaboration between network participants. However, others caution that implementing bLIPs could lead to fragmentation and security risks, and emphasize the importance of maintaining a clear process for assigning feature bits, inserting new tlv fields, and creating new messages to avoid network incompatibilities.Lastly, the Lightning Network community has discussed the potential addition of a BIP-style process (bLIPs or SPARKs) on top of the existing BOLT process. The proposed process would add a place for app layer best practices to be described and organized, especially those that require coordination. This would not affect the existing BOLT process but would bring features being built outside of it into the fold. Some potential bLIP ideas 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. Developers from various implementations and the broader app layer ecosystem are encouraged to volunteer as editors. Overall, the Lightning Network community is focused on improving its specification process to address current limitations and challenges. While there are differing opinions on the best way forward, concerns about fragmentation, security risks, and properly reviewing spec proposals are acknowledged and being addressed. The community is exploring options such as dynamic commitments and the potential addition of a BIP-style process to enhance flexibility and collaboration while maintaining standardization and avoiding fragmentation.


Updated on: 2023-06-03T04:35:25.189413+00:00