📅 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
>
fiatjaf [ARCHIVE] /
npub1v2…pmakl
2023-06-09 12:40:29
in reply to nevent1q…s807
Author Public Key
npub1v2xa40strmvauf2gr5gjj5c3yqlytar7p3v64nfg0ke6e0vkvvkqxpmaklPublished at
2023-06-09 12:40:29Event JSON
{
"id": "9a692e5f081e98689f64d68d374f56c2b8a5e8d51986c91a7d30ad768b2414a1",
"pubkey": "628ddabe0b1ed9de25481d11295311203e45f47e0c59aacd287db3acbd96632c",
"created_at": 1686314429,
"kind": 1,
"tags": [
[
"e",
"7978884316d2a2eea3e40b9cc9bbbd31e26017308c2be1dc1637e23b621c5a03",
"",
"root"
],
[
"e",
"691bd752f5062b6764a978e724500bdd4c24415469c90c11bc29c41932eb4247",
"",
"reply"
],
[
"p",
"d3574a24208f4e3d0821bb4a69a0c3ae842043d444fa5c4a8c49c369918a6fb2"
]
],
"content": "📅 Original date posted:2021-07-01\n📝 Original message:\nHere's another feature which just appeared and would benefit from a\nbLIP for compatibility:\nhttps://twitter.com/SimpleBtcWallet/status/1410506889545359365\n\nAtomic splitting of bills. A very small thing, but also very cool. I\ncan't imagine it fitting in the BOLTs at all.\n\n2021-06-30 09:10 (GMT-05:00), Ryan Gentry via Lightning-dev\n\u003clightning-dev at lists.linuxfoundation.org\u003e said:\n\u003e Hi all,\n\u003e The recent thread around zero-conf channels [1] provides an opportunity to\n\u003e discuss how the BOLT process handles features and best practices that arise in\n\u003e the wild vs. originating within the process itself. Zero-conf channels are one\n\u003e of many LN innovations on the app layer that have struggled to make their way\n\u003e into the spec. John Carvalho and Bitrefill launched Turbo channels in April\n\u003e 2019 [2], Breez posted their solution to the mailing list for feedback in\n\u003e August 2020 [3], and we know at least ACINQ and Muun (amongst others) have\n\u003e their own implementations. In an ideal world there would be a descriptive\n\u003e design document that the app layer implementers had collaborated on over the\n\u003e years that the spec group could then pick up and merge into the BOLTs now that\n\u003e the feature is deemed spec-worthy.\n\u003e Over the last couple of months, we have discussed the idea of adding a\n\u003e BIP-style process (bLIPs? SPARKs? [4]) on top of the BOLTs with various members\n\u003e of the community, and have received positive feedback from both app layer and\n\u003e protocol devs. This would not affect the existing BOLT process at all, but\n\u003e simply add a place for app layer best practices to be succinctly described and\n\u003e organized, especially those that require coordination. These features are being\n\u003e built outside of the BOLT process today anyways, so ideally a bLIP process\n\u003e would bring them into the fold instead of leaving them buried in old ML posts\n\u003e or not documented at all.\n\u003e Some potential bLIP ideas that people have mentioned include: each lnurl\n\u003e variant, on-the-fly channel opens, AMP, dynamic commitments, podcast payment\n\u003e metadata, p2p messaging formats, new pathfinding heuristics, remote node\n\u003e connection standards, etc.\n\u003e If the community is interested in moving forward, we've started a branch [5]\n\u003e describing such a process. It's based on BIP-0002, so not trying to reinvent\n\u003e any wheels. It would be great to have developers from various implementations\n\u003e and from the broader app layer ecosystem volunteer to be listed as editors\n\u003e (basically the same role as in the BIPs).\n\u003e Looking forward to hearing your thoughts!\n\u003e Best,\n\u003e Ryan\n\u003e [1]\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-June/003074.html\n\u003e [2]\n\u003e https://www.coindesk.com/bitrefills-thor-turbo-lets-you-get-started-with-bitcoins-lightning-faster\n\u003e [3]\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-August/002780.html\n\u003e [4] bLIP = Bitcoin Lightning Improvement Proposal and SPARK = Standardization\n\u003e of Protocols at the Request of the Kommunity (h/t fiatjaf)\n\u003e [5]\n\u003e https://github.com/ryanthegentry/lightning-rfc/blob/blip-0001/blips/blip-0001.mediawiki_______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e",
"sig": "85c47a80f9b8dfb7259572b38f808bd3cddc6ab95137563d2851be27581cb7f092bd84d9079781192d76aa455e7a5d700f4667cddc63d67a18c526427203738f"
}