Here's another feature which just appeared and would benefit from a
bLIP for compatibility:

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
<> 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]
> [2]
> [3]
> [4] bLIP = Bitcoin Lightning Improvement Proposal and SPARK = Standardization
> of Protocols at the Request of the Kommunity (h/t fiatjaf)
> [5]
> Lightning-dev mailing list
Lightning-dev mailing list

Reply via email to