📅 Original date posted:2021-06-30
📝 Original message:
Hi Rene,
Thank you for the feedback! Very interesting to look back at the same
proposal from 2018, we clearly could have done a better job researching
past attempts. I have two main comments:
1) not trying to introduce a new repo, the linked lightning-rfc branch [1]
simply adds a new bLIPs folder in the existing repo (like you suggested as
an option in 2018)
2) major difference between 2018 and now is one of scale (which is a great
problem to have!). In 2018 the LN dev ecosystem was mostly ACINQ,
Blockstream, and Lightning Labs and the minimalist BOLTs process worked
well. At this point the broader ecosystem is significantly bigger than
those three teams combined, and it seems the process should adjust to
reflect the new environment.
The main goal of the suggested change is simply to provide a home for
emerging "best practices", especially those that require coordination
amongst multiple groups. I think LNURL provides a good example of a "best
practice" that has been spec'd out [2], is completely extra protocol so
probably doesn't belong as a BOLT, but carries tension with it for new
developers since it's been widely adopted yet not "officially supported".
What do you think about that?
Best,
Ryan
[1]
https://github.com/ryanthegentry/lightning-rfc/blob/blip-0001/blips/blip-0001.mediawiki
[2] https://github.com/fiatjaf/lnurl-rfc
On Wed, Jun 30, 2021 at 9:35 AM René Pickhardt <r.pickhardt at googlemail.com>
wrote:
> Hey everyone,
>
> just for reference when I was new here (and did not understand the
> processes well enough) I proposed a similar idea (called LIP) in 2018 c.f.:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-July/001367.html
>
>
> I wonder what exactly has changed in the reasoning by roasbeef which I
> will repeat here:
>
> *> We already have the equiv of improvement proposals: BOLTs. Historically*
>
> >* new standardization documents are proposed initially as issues or PR's when *
>
> >* ultimately accepted. Why do we need another repo? *
>
>
> As far as I can tell there was always some form of (invisible?) barrier to
> participate in the BOLTs but there are also new BOLTs being offered:
> * BOLT 12: https://github.com/lightningnetwork/lightning-rfc/pull/798
> * BOLT 14: https://github.com/lightningnetwork/lightning-rfc/pull/780
> and topics to be included like:
> * dual funding
> * splicing
> * the examples given by Ryan
>
> I don't see how a new repo would reduce that barrier - Actually I think it
> would even create more confusion as I for example would not know where
> something belongs. That being said I think all the points that are
> addressed in Ryan's mail could very well be formalized into BOLTs but maybe
> we just need to rethink the current process of the BOLTs to make it more
> accessible for new ideas to find their way into the BOLTs? One thing that I
> can say from answering lightning-network questions on stackexchange is that
> it would certainly help if the BOLTs where referenced on lightning.network
> web page and in the whitepaper as the place to be if one wants to learn
> about the Lightning Network
>
> with kind regards Rene
>
> On Wed, Jun 30, 2021 at 4:10 PM Ryan Gentry via Lightning-dev <
> lightning-dev at 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
>
> --
> https://www.rene-pickhardt.de
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210630/9934ead9/attachment.html>;
Ryan Gentry [ARCHIVE] /
npub1jk…f6y7d
2023-06-09 13:02:49
in reply to nevent1q…vatv
Author Public Key
npub1jk0t9q8dag7adpswdsgl6phy603shac5s2fp0lpxwwmpmatkzwas8f6y7dPublished at
2023-06-09 13:02:49Event JSON
{
"id": "d18f04ddb64c7a88d2373f2de0a926f8baf08f48fd31370a7dee588c9a6df339",
"pubkey": "959eb280edea3dd6860e6c11fd06e4d3e30bf714829217fc2673b61df57613bb",
"created_at": 1686315769,
"kind": 1,
"tags": [
[
"e",
"7adaf231e3b906002d245f2d03aa149c8260d706cf8060c949a0472f70e0ef51",
"",
"root"
],
[
"e",
"e5f276508bbf0d3c7bcc05f5d56f6f7bfb76277786f142d3cf9139e99af1f50d",
"",
"reply"
],
[
"p",
"17ccd89be295c0ae65f1cd3740a9dad84ec8b6d7050712a7f04ae5284b2fab99"
]
],
"content": "📅 Original date posted:2021-06-30\n📝 Original message:\nHi Rene,\n\nThank you for the feedback! Very interesting to look back at the same\nproposal from 2018, we clearly could have done a better job researching\npast attempts. I have two main comments:\n\n1) not trying to introduce a new repo, the linked lightning-rfc branch [1]\nsimply adds a new bLIPs folder in the existing repo (like you suggested as\nan option in 2018)\n2) major difference between 2018 and now is one of scale (which is a great\nproblem to have!). In 2018 the LN dev ecosystem was mostly ACINQ,\nBlockstream, and Lightning Labs and the minimalist BOLTs process worked\nwell. At this point the broader ecosystem is significantly bigger than\nthose three teams combined, and it seems the process should adjust to\nreflect the new environment.\n\nThe main goal of the suggested change is simply to provide a home for\nemerging \"best practices\", especially those that require coordination\namongst multiple groups. I think LNURL provides a good example of a \"best\npractice\" that has been spec'd out [2], is completely extra protocol so\nprobably doesn't belong as a BOLT, but carries tension with it for new\ndevelopers since it's been widely adopted yet not \"officially supported\".\nWhat do you think about that?\n\nBest,\nRyan\n\n[1]\nhttps://github.com/ryanthegentry/lightning-rfc/blob/blip-0001/blips/blip-0001.mediawiki\n[2] https://github.com/fiatjaf/lnurl-rfc\n\nOn Wed, Jun 30, 2021 at 9:35 AM René Pickhardt \u003cr.pickhardt at googlemail.com\u003e\nwrote:\n\n\u003e Hey everyone,\n\u003e\n\u003e just for reference when I was new here (and did not understand the\n\u003e processes well enough) I proposed a similar idea (called LIP) in 2018 c.f.:\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-July/001367.html\n\u003e\n\u003e\n\u003e I wonder what exactly has changed in the reasoning by roasbeef which I\n\u003e will repeat here:\n\u003e\n\u003e *\u003e We already have the equiv of improvement proposals: BOLTs. Historically*\n\u003e\n\u003e \u003e* new standardization documents are proposed initially as issues or PR's when *\n\u003e\n\u003e \u003e* ultimately accepted. Why do we need another repo? *\n\u003e\n\u003e\n\u003e As far as I can tell there was always some form of (invisible?) barrier to\n\u003e participate in the BOLTs but there are also new BOLTs being offered:\n\u003e * BOLT 12: https://github.com/lightningnetwork/lightning-rfc/pull/798\n\u003e * BOLT 14: https://github.com/lightningnetwork/lightning-rfc/pull/780\n\u003e and topics to be included like:\n\u003e * dual funding\n\u003e * splicing\n\u003e * the examples given by Ryan\n\u003e\n\u003e I don't see how a new repo would reduce that barrier - Actually I think it\n\u003e would even create more confusion as I for example would not know where\n\u003e something belongs. That being said I think all the points that are\n\u003e addressed in Ryan's mail could very well be formalized into BOLTs but maybe\n\u003e we just need to rethink the current process of the BOLTs to make it more\n\u003e accessible for new ideas to find their way into the BOLTs? One thing that I\n\u003e can say from answering lightning-network questions on stackexchange is that\n\u003e it would certainly help if the BOLTs where referenced on lightning.network\n\u003e web page and in the whitepaper as the place to be if one wants to learn\n\u003e about the Lightning Network\n\u003e\n\u003e with kind regards Rene\n\u003e\n\u003e On Wed, Jun 30, 2021 at 4:10 PM Ryan Gentry via Lightning-dev \u003c\n\u003e lightning-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e Hi all,\n\u003e\u003e\n\u003e\u003e The recent thread around zero-conf channels [1] provides an opportunity\n\u003e\u003e to discuss how the BOLT process handles features and best practices that\n\u003e\u003e arise in the wild vs. originating within the process itself. Zero-conf\n\u003e\u003e channels are one of many LN innovations on the app layer that have\n\u003e\u003e struggled to make their way into the spec. John Carvalho and Bitrefill\n\u003e\u003e launched Turbo channels in April 2019 [2], Breez posted their solution to\n\u003e\u003e the mailing list for feedback in August 2020 [3], and we know at least\n\u003e\u003e ACINQ and Muun (amongst others) have their own implementations. In an ideal\n\u003e\u003e world there would be a descriptive design document that the app layer\n\u003e\u003e implementers had collaborated on over the years that the spec group could\n\u003e\u003e then pick up and merge into the BOLTs now that the feature is deemed\n\u003e\u003e spec-worthy.\n\u003e\u003e\n\u003e\u003e Over the last couple of months, we have discussed the idea of adding a\n\u003e\u003e BIP-style process (bLIPs? SPARKs? [4]) on top of the BOLTs with various\n\u003e\u003e members of the community, and have received positive feedback from both app\n\u003e\u003e layer and protocol devs. This would not affect the existing BOLT process at\n\u003e\u003e all, but simply add a place for app layer best practices to be succinctly\n\u003e\u003e described and organized, especially those that require coordination. These\n\u003e\u003e features are being built outside of the BOLT process today anyways, so\n\u003e\u003e ideally a bLIP process would bring them into the fold instead of leaving\n\u003e\u003e them buried in old ML posts or not documented at all.\n\u003e\u003e\n\u003e\u003e Some potential bLIP ideas that people have mentioned include: each lnurl\n\u003e\u003e variant, on-the-fly channel opens, AMP, dynamic commitments, podcast\n\u003e\u003e payment metadata, p2p messaging formats, new pathfinding heuristics, remote\n\u003e\u003e node connection standards, etc.\n\u003e\u003e\n\u003e\u003e If the community is interested in moving forward, we've started a branch\n\u003e\u003e [5] describing such a process. It's based on BIP-0002, so not trying to\n\u003e\u003e reinvent any wheels. It would be great to have developers from various\n\u003e\u003e implementations and from the broader app layer ecosystem volunteer to be\n\u003e\u003e listed as editors (basically the same role as in the BIPs).\n\u003e\u003e\n\u003e\u003e Looking forward to hearing your thoughts!\n\u003e\u003e\n\u003e\u003e Best,\n\u003e\u003e Ryan\n\u003e\u003e\n\u003e\u003e [1]\n\u003e\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-June/003074.html\n\u003e\u003e\n\u003e\u003e [2]\n\u003e\u003e https://www.coindesk.com/bitrefills-thor-turbo-lets-you-get-started-with-bitcoins-lightning-faster\n\u003e\u003e\n\u003e\u003e [3]\n\u003e\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-August/002780.html\n\u003e\u003e\n\u003e\u003e [4] bLIP = Bitcoin Lightning Improvement Proposal and SPARK =\n\u003e\u003e Standardization of Protocols at the Request of the Kommunity (h/t fiatjaf)\n\u003e\u003e\n\u003e\u003e [5]\n\u003e\u003e https://github.com/ryanthegentry/lightning-rfc/blob/blip-0001/blips/blip-0001.mediawiki\n\u003e\u003e _______________________________________________\n\u003e\u003e Lightning-dev mailing list\n\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\u003e\n\u003e\n\u003e\n\u003e --\n\u003e https://www.rene-pickhardt.de\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210630/9934ead9/attachment.html\u003e",
"sig": "0d30446e6d08b6dca46d4361306d212d0cd8c9ac906ce12082612933d781d9b09ec1da12f8d258ddba9c08350680bdf2aa44531d069d9c0bc013b0393f3ad845"
}