fiatjaf [ARCHIVE] on Nostr: 📅 Original date posted:2021-07-01 📝 Original message: Here's another feature ...
📅 Original date posted:2021-07-01
📝 Original message:
Here's another feature which just appeared and would benefit from a
bLIP for compatibility:
https://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]
> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
📝 Original message:
Here's another feature which just appeared and would benefit from a
bLIP for compatibility:
https://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]
> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>