[Lightning-dev] bLIPs are Open for Business!
Hi all, Earlier this year, I emailed this mailing list about bitcoin Lightning Improvement Proposals (bLIPs) [1] as a way to help standardize community-driven app layer and protocol extension development. Today, I am excited to let you know that the first two bLIPs specifying the process have been merged [2] and that we are ready to start receiving proposals! Here are few example proposals I have my eyes on: Val's Keysend bLIP [3], the Sphinx team's LUMO messaging format [4], Satoshi's Stream's TLV registry [5], Lightning Node Connect [6], niftynei's accounting standardization work, some of Impervious's LN-native communications work, LND's Static Channel Backup system... and I am sure there are many more! Please don't hesitate to reach out if you're interested in writing a bLIP and want help. We're excited about getting this process going! As a reminder, a bLIP is a design document providing information to the Lightning community, or describing a new feature for the Lightning Network, and should provide a concise technical specification of the feature and a rationale for the feature. Importantly, if a feature is intended to become universal or near universal, it must be a BOLT [7]. Because of this distinction, the bLIP editors do not pass judgment on bLIPs, but only monitor bLIP changes, and update bLIP headers as appropriate. So long as you check the mailing list to ensure nobody has made a similar proposal before, fill out the required sections specified in bLIP-0001, and reserve the required feature bit, message type, or TLV in the bLIP-0002 registry, we are more than happy to merge proposals into the repo. Best, Ryan [1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-June/003086.html [2] https://github.com/lightning/blips [3] https://github.com/lightning/blips/pull/5 [4] https://github.com/stakwork/lumo-spec [5] https://github.com/satoshisstream/satoshis.stream/blob/main/TLV_registry.md [6] https://lightning.engineering/posts/2021-11-30-lightning-node-connect-deep-dive/ [7] https://github.com/lightning/bolts ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] bLIPs: A proposal for community-driven app layer and protocol extension standardization
escriptive to prescriptive. >> >>>> Any alternatives, or optional features should be extracted out of >> >>>> BOLTs, written as BIPs. The BIP should then reference the BOLT and >> the >> >>>> required flags set, messages sent, or alterations made to signal that >> >>>> the BIP's feature is enabled. >> >>>> >> >>>> A BOLT may at some point organically change to reference a BIP. For >> >>>> example if a BIP was drafted as an optional feature but then becomes >> >>>> more widespread and then turns out to be crucial for the proper >> >>>> operation of the network then a BOLT can be changed to just reference >> >>>> the BIP as mandatory. There isn't anything wrong with this. >> >>>> >> >>>> All of the above would work exactly the same if there was a bLIP >> >>>> repository instead. I don't see the value in having both bLIPs and >> >>>> BIPs since AFAICT they seem to be functionally equivalent and BIPs >> are >> >>>> not restricted to exclude lightning, and never have been. >> >>>> >> >>>> I believe the reason this move to BIPs hasn't happened organically is >> >>>> because many still perceive the BOLTs available for editing, so >> >>>> changes continue to be made. If instead BOLTs were perceived as more >> >>>> "consensus critical", not subject to change, and more people were >> >>>> strongly encouraged to write specs for new lightning features >> >>>> elsewhere (like the BIP repo) then you would see this issue of >> growing >> >>>> BOLTs resolved. >> >>>> >> >>>> Cheers >> >>>> Ariel Lorenzo-Luaces >> >>>> >> >>>> On Wed, Jun 30, 2021 at 1:16 PM Olaoluwa Osuntokun < >> laol...@gmail.com> wrote: >> >>>> > >> >>>> > > That being said I think all the points that are addressed in >> Ryan's mail >> >>>> > > could very well be formalized into BOLTs but maybe we just need >> to rethink >> >>>> > > the current process of the BOLTs to make it more accessible for >> new ideas >> >>>> > > to find their way into the BOLTs? >> >>>> > >> >>>> > I think part of what bLIPs are trying to solve here is promoting >> more loosely >> >>>> > coupled evolution of the network. I think the BOLTs do a good job >> currently of >> >>>> > specifying what _base_ functionality is required for a routing >> node in a >> >>>> > prescriptive manner (you must forward an HTLC like this, etc). >> However there's >> >>>> > a rather large gap in describing functionality that has emerged >> over time due >> >>>> > to progressive evolution, and aren't absolutely necessary, but >> enhance >> >>>> > node/wallet operation. >> >>>> > >> >>>> > Examples of include things like: path finding heuristics (BOLTs >> just say you >> >>>> > should get from Alice to Bob, but provides no recommendations >> w.r.t _how_ to do >> >>>> > so), fee bumping heuristics, breach retribution handling, channel >> management, >> >>>> > rebalancing, custom records usage (like the podcast index >> meta-data, messaging, >> >>>> > etc), JIT channel opening, hosted channels, randomized channel >> IDs, fee >> >>>> > optimization, initial channel boostrapping, etc. >> >>>> > >> >>>> > All these examples are effectively optional as they aren't >> required for base >> >>>> > node operation, but they've organically evolved over time as node >> >>>> > implementations and wallet seek to solve UX and operational >> problems for >> >>>> > their users. bLIPs can be a _descriptive_ (this is how things can >> be done) >> >>>> > home for these types of standards, while BOLTs can be reserved for >> >>>> > _prescriptive_ measures (an HTLC looks like this, etc). >> >>>> > >> >>>> > The protocol as implemented today has a number of extensions >> (TLVs, message >> >>>> > types, feature bits, etc) that allow implementations to spin out >>
Re: [Lightning-dev] bLIPs: A proposal for community-driven app layer and protocol extension standardization
Hi Rene, Thank you for the feedback! Very interesting to look back at the same proposal from 2018, we clearly could have done a better job researching past attempts. I have two main comments: 1) not trying to introduce a new repo, the linked lightning-rfc branch [1] simply adds a new bLIPs folder in the existing repo (like you suggested as an option in 2018) 2) major difference between 2018 and now is one of scale (which is a great problem to have!). In 2018 the LN dev ecosystem was mostly ACINQ, Blockstream, and Lightning Labs and the minimalist BOLTs process worked well. At this point the broader ecosystem is significantly bigger than those three teams combined, and it seems the process should adjust to reflect the new environment. The main goal of the suggested change is simply to provide a home for emerging "best practices", especially those that require coordination amongst multiple groups. I think LNURL provides a good example of a "best practice" that has been spec'd out [2], is completely extra protocol so probably doesn't belong as a BOLT, but carries tension with it for new developers since it's been widely adopted yet not "officially supported". What do you think about that? Best, Ryan [1] https://github.com/ryanthegentry/lightning-rfc/blob/blip-0001/blips/blip-0001.mediawiki [2] https://github.com/fiatjaf/lnurl-rfc On Wed, Jun 30, 2021 at 9:35 AM René Pickhardt wrote: > Hey everyone, > > just for reference when I was new here (and did not understand the > processes well enough) I proposed a similar idea (called LIP) in 2018 c.f.: > https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-July/001367.html > > > I wonder what exactly has changed in the reasoning by roasbeef which I > will repeat here: > > *> We already have the equiv of improvement proposals: BOLTs. Historically* > > >* new standardization documents are proposed initially as issues or PR's > >when * > > >* ultimately accepted. Why do we need another repo? * > > > As far as I can tell there was always some form of (invisible?) barrier to > participate in the BOLTs but there are also new BOLTs being offered: > * BOLT 12: https://github.com/lightningnetwork/lightning-rfc/pull/798 > * BOLT 14: https://github.com/lightningnetwork/lightning-rfc/pull/780 > and topics to be included like: > * dual funding > * splicing > * the examples given by Ryan > > I don't see how a new repo would reduce that barrier - Actually I think it > would even create more confusion as I for example would not know where > something belongs. That being said I think all the points that are > addressed in Ryan's mail could very well be formalized into BOLTs but maybe > we just need to rethink the current process of the BOLTs to make it more > accessible for new ideas to find their way into the BOLTs? One thing that I > can say from answering lightning-network questions on stackexchange is that > it would certainly help if the BOLTs where referenced on lightning.network > web page and in the whitepaper as the place to be if one wants to learn > about the Lightning Network > > with kind regards Rene > > On Wed, Jun 30, 2021 at 4:10 PM Ryan Gentry via Lightning-dev < > lightning-dev@lists.linuxfoundation.org> wrote: > >> Hi all, >> >> The recent thread around zero-conf channels [1] 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 LN innovations on the app layer that have >> struggled to make their way into the spec. John Carvalho and Bitrefill >> launched Turbo channels in April 2019 [2], Breez posted their solution to >> the mailing list for feedback in August 2020 [3], and we know at least >> ACINQ and Muun (amongst others) have their own implementations. 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 couple of months, we have discussed the idea of adding a >> BIP-style process (bLIPs? SPARKs? [4]) on top of the BOLTs with various >> members of the community, and have received positive feedback from both app >> layer and protocol devs. 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. These >> features are being built outside of the BOLT process today anyways, so >> ideally a bLIP process would bring them into the fol
[Lightning-dev] bLIPs: A proposal for community-driven app layer and protocol extension standardization
Hi all, The recent thread around zero-conf channels [1] 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 LN innovations on the app layer that have struggled to make their way into the spec. John Carvalho and Bitrefill launched Turbo channels in April 2019 [2], Breez posted their solution to the mailing list for feedback in August 2020 [3], and we know at least ACINQ and Muun (amongst others) have their own implementations. 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 couple of months, we have discussed the idea of adding a BIP-style process (bLIPs? SPARKs? [4]) on top of the BOLTs with various members of the community, and have received positive feedback from both app layer and protocol devs. 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. These features are being built outside of the BOLT process today anyways, so ideally a bLIP process would bring them into the fold instead of leaving them buried in old ML posts or not documented at all. 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. If the community is interested in moving forward, we've started a branch [5] describing such a process. It's based on BIP-0002, so not trying 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). Looking forward to hearing your thoughts! Best, Ryan [1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-June/003074.html [2] https://www.coindesk.com/bitrefills-thor-turbo-lets-you-get-started-with-bitcoins-lightning-faster [3] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-August/002780.html [4] bLIP = Bitcoin Lightning Improvement Proposal and SPARK = Standardization of Protocols at the Request of the Kommunity (h/t fiatjaf) [5] https://github.com/ryanthegentry/lightning-rfc/blob/blip-0001/blips/blip-0001.mediawiki ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
