📅 Original date posted:2021-06-30
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210630/ed2d0adc/attachment.html>;
Ryan Gentry [ARCHIVE] /
npub1jk…f6y7d
2023-06-09 13:02:48
in reply to nevent1q…w4jk
Author Public Key
npub1jk0t9q8dag7adpswdsgl6phy603shac5s2fp0lpxwwmpmatkzwas8f6y7dPublished at
2023-06-09 13:02:48Event JSON
{
"id": "d81b68e2d84d190fcbaad34ed290a10fe78707d0b023dac00d995ae84cfb10d3",
"pubkey": "959eb280edea3dd6860e6c11fd06e4d3e30bf714829217fc2673b61df57613bb",
"created_at": 1686315768,
"kind": 1,
"tags": [
[
"e",
"7adaf231e3b906002d245f2d03aa149c8260d706cf8060c949a0472f70e0ef51",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2021-06-30\n📝 Original message:\nHi all,\n\nThe recent thread around zero-conf channels [1] provides an opportunity to\ndiscuss how the BOLT process handles features and best practices that arise\nin the wild vs. originating within the process itself. Zero-conf channels\nare one of many LN innovations on the app layer that have struggled to make\ntheir way into the spec. John Carvalho and Bitrefill launched Turbo\nchannels in April 2019 [2], Breez posted their solution to the mailing list\nfor feedback in August 2020 [3], and we know at least ACINQ and Muun\n(amongst others) have their own implementations. In an ideal world there\nwould be a descriptive design document that the app layer implementers had\ncollaborated on over the years that the spec group could then pick up and\nmerge into the BOLTs now that the feature is deemed spec-worthy.\n\nOver the last couple of months, we have discussed the idea of adding a\nBIP-style process (bLIPs? SPARKs? [4]) on top of the BOLTs with various\nmembers of the community, and have received positive feedback from both app\nlayer and protocol devs. This would not affect the existing BOLT process at\nall, but simply add a place for app layer best practices to be succinctly\ndescribed and organized, especially those that require coordination. These\nfeatures are being built outside of the BOLT process today anyways, so\nideally a bLIP process would bring them into the fold instead of leaving\nthem buried in old ML posts or not documented at all.\n\nSome potential bLIP ideas that people have mentioned include: each lnurl\nvariant, on-the-fly channel opens, AMP, dynamic commitments, podcast\npayment metadata, p2p messaging formats, new pathfinding heuristics, remote\nnode connection standards, etc.\n\nIf the community is interested in moving forward, we've started a branch\n[5] describing such a process. It's based on BIP-0002, so not trying to\nreinvent any wheels. It would be great to have developers from various\nimplementations and from the broader app layer ecosystem volunteer to be\nlisted as editors (basically the same role as in the BIPs).\n\nLooking forward to hearing your thoughts!\n\nBest,\nRyan\n\n[1]\nhttps://lists.linuxfoundation.org/pipermail/lightning-dev/2021-June/003074.html\n\n[2]\nhttps://www.coindesk.com/bitrefills-thor-turbo-lets-you-get-started-with-bitcoins-lightning-faster\n\n[3]\nhttps://lists.linuxfoundation.org/pipermail/lightning-dev/2020-August/002780.html\n\n[4] bLIP = Bitcoin Lightning Improvement Proposal and SPARK =\nStandardization of Protocols at the Request of the Kommunity (h/t fiatjaf)\n\n[5]\nhttps://github.com/ryanthegentry/lightning-rfc/blob/blip-0001/blips/blip-0001.mediawiki\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210630/ed2d0adc/attachment.html\u003e",
"sig": "f101849b8b0a8533e2f553c68ac2c5441f77c23c08e9031be101d813df3c69b04012d0951b2b73e47a250fec9633dbc5277bffeb1a0e47ebc57eb3d2bd478d6c"
}