📅 Original date posted:2021-07-01 📝 Original message: Here's another feature which just appeared and would benefit from a bLIP for compatibility: twitter.com/SimpleBtcWallet/status/1410506889545359365 Atomic splitting of bills. A very small thing, but also very cool. I can't imagine it fitting in the BOLTs at all. 2021-06-30 09:10 (GMT-05:00), Ryan Gentry via Lightning-dev <lightning-dev at lists.linuxfoundation.org> said: > 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] > lists.linuxfoundation.org/pipermail/lightning-dev/2021-June/003074.html > [2] > www.coindesk.com/bitrefills-thor-turbo-lets-you-get-started-with-bitcoins-lightning-faster > [3] > 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] > github.com/ryanthegentry/lightning-rfc/blob/blip-0001/blips/blip-0001.mediawiki_______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > lists.linuxfoundation.org/mailman/listinfo/lightning-dev >