Or just use BIPs instead of further fracturing...?
On Jun 30, 2021 10:10 AM, 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 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
