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

Reply via email to