Olaoluwa Osuntokun [ARCHIVE] on Nostr: 📅 Original date posted:2021-06-30 📝 Original message: > That being said I think ...
📅 Original date posted:2021-06-30
📝 Original message:
> 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?
I think part of what bLIPs are trying to solve here is promoting more
loosely
coupled evolution of the network. I think the BOLTs do a good job currently
of
specifying what _base_ functionality is required for a routing node in a
prescriptive manner (you must forward an HTLC like this, etc). However
there's
a rather large gap in describing functionality that has emerged over time
due
to progressive evolution, and aren't absolutely necessary, but enhance
node/wallet operation.
Examples of include things like: path finding heuristics (BOLTs just say
you
should get from Alice to Bob, but provides no recommendations w.r.t _how_
to do
so), fee bumping heuristics, breach retribution handling, channel
management,
rebalancing, custom records usage (like the podcast index meta-data,
messaging,
etc), JIT channel opening, hosted channels, randomized channel IDs, fee
optimization, initial channel boostrapping, etc.
All these examples are effectively optional as they aren't required for base
node operation, but they've organically evolved over time as node
implementations and wallet seek to solve UX and operational problems for
their users. bLIPs can be a _descriptive_ (this is how things can be done)
home for these types of standards, while BOLTs can be reserved for
_prescriptive_ measures (an HTLC looks like this, etc).
The protocol as implemented today has a number of extensions (TLVs, message
types, feature bits, etc) that allow implementations to spin out their own
sub-protocols, many of which won't be considered absolutely necessary for
node
operation. IMO we should embrace more of a "bazaar" style of evolution, and
acknowledge that loosely coupled evolution allows participants to more
broadly
explore the design space, without the constraints of "it isn't a thing
until N
of us start to do it".
Historically, BOLTs have also had a rather monolithic structure. We've used
the same 11 or so documents for the past few years with the size of the
documents swelling over time with new exceptions, features, requirements,
etc. If you were hired to work on a new codebase and saw that everything is
defined in 11 "functions" that have been growing linearly over time, you'd
probably declare the codebase as being unmaintainable. By having distinct
documents for proposals/standards, bLIPs (author documents really), each new
standard/proposal is able to be more effectively explained, motivated,
versionsed,
etc.
-- Laolu
On Wed, Jun 30, 2021 at 7:35 AM René Pickhardt via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> 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
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210630/a9d3e7a4/attachment.html>;
📝 Original message:
> 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?
I think part of what bLIPs are trying to solve here is promoting more
loosely
coupled evolution of the network. I think the BOLTs do a good job currently
of
specifying what _base_ functionality is required for a routing node in a
prescriptive manner (you must forward an HTLC like this, etc). However
there's
a rather large gap in describing functionality that has emerged over time
due
to progressive evolution, and aren't absolutely necessary, but enhance
node/wallet operation.
Examples of include things like: path finding heuristics (BOLTs just say
you
should get from Alice to Bob, but provides no recommendations w.r.t _how_
to do
so), fee bumping heuristics, breach retribution handling, channel
management,
rebalancing, custom records usage (like the podcast index meta-data,
messaging,
etc), JIT channel opening, hosted channels, randomized channel IDs, fee
optimization, initial channel boostrapping, etc.
All these examples are effectively optional as they aren't required for base
node operation, but they've organically evolved over time as node
implementations and wallet seek to solve UX and operational problems for
their users. bLIPs can be a _descriptive_ (this is how things can be done)
home for these types of standards, while BOLTs can be reserved for
_prescriptive_ measures (an HTLC looks like this, etc).
The protocol as implemented today has a number of extensions (TLVs, message
types, feature bits, etc) that allow implementations to spin out their own
sub-protocols, many of which won't be considered absolutely necessary for
node
operation. IMO we should embrace more of a "bazaar" style of evolution, and
acknowledge that loosely coupled evolution allows participants to more
broadly
explore the design space, without the constraints of "it isn't a thing
until N
of us start to do it".
Historically, BOLTs have also had a rather monolithic structure. We've used
the same 11 or so documents for the past few years with the size of the
documents swelling over time with new exceptions, features, requirements,
etc. If you were hired to work on a new codebase and saw that everything is
defined in 11 "functions" that have been growing linearly over time, you'd
probably declare the codebase as being unmaintainable. By having distinct
documents for proposals/standards, bLIPs (author documents really), each new
standard/proposal is able to be more effectively explained, motivated,
versionsed,
etc.
-- Laolu
On Wed, Jun 30, 2021 at 7:35 AM René Pickhardt via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> 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
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210630/a9d3e7a4/attachment.html>;