Author: Michael Folkson 2021-07-02 08:48:20
Published on: 2021-07-02T08:48:20+00:00
The Lightning Network community is currently discussing the possibility of replacing BOLTs with bLIPs/BIPs. The main argument for this is that while BOLTs are good at specifying base functionality in a prescriptive manner, they fail to describe optional features that enhance node/wallet operation and have organically evolved over time due to progressive evolution. Examples of such optional features include path finding heuristics, fee bumping heuristics, channel management, rebalancing, custom records usage, JIT channel opening, hosted channels, randomized channel IDs, fee optimization, initial channel boostrapping, and more. These features are being built outside of the BOLT process today anyway, so ideally a bLIP process would bring them into the fold instead of leaving them buried in old mailing list posts or not documented at all.However, some members are concerned about adding more fragmentation to the network, which will add maintenance costs and backwards-compatibility issues. Additionally, many bLIPs may be sub-optimal solutions to the problem they try to solve and some may be insecure and put users' funds at risk. The interplay with BOLTs comes in as they are the global feature bit/tlv/message namespace. A bLIP might come with the amendment of BOLT 9 to define feature bits they used.To address this issue, bLIPs can be a descriptive home for these types of standards, while BOLTs can be reserved for prescriptive measures. The creation of a centralized bLIP repo could safely assign "final" values for types and feature bits that are used by each bLIP, and stronger guarantees that they will not conflict with another bLIP or BOLT. Finally, the details of where bLIPs live are yet to be decided, but they must be easy to find and browse, and it's easier for readers if they're inside the spec repository.A recent thread around zero-conf channels has prompted a discussion within the Lightning Network (LN) community about how the BOLT process handles LN innovations that arise in the wild as opposed to originating within the process itself. Zero-conf channels are one of many LN 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. Over the last few months, discussions have taken place regarding the idea of adding a Bitcoin Lightning Improvement Proposal (bLIP) style process on top of the BOLTs with various members of the community, which has received positive feedback from both app layer and protocol developers. 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. If the community is interested in moving forward, a branch has been started describing such a process, based on BIP-0002, so as not to try to reinvent any wheels. It would be great to have developers from various implementations and from the broader app layer ecosystem volunteer to be listed as editors (basically the same role as in the BIPs).One member of the community, Rene Pickhardt, suggested that all the points addressed in Ryan's mail could very well be formalized into BOLTs, but perhaps the current process of the BOLTs needs to be rethought to make it more accessible for new ideas to find their way into the BOLTs. One thing that could help is if the BOLTs were referenced on lightning.network web page and in the whitepaper as the place to go to learn about the Lightning Network.Michael Folkson, who shared the thread with the community, can be contacted through email at michaelfolkson@gmail.com, Keybase at michaelfolkson, or PGP at 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3.
Updated on: 2023-06-03T04:49:13.913837+00:00