Luke Dashjr [ARCHIVE] on Nostr: 📅 Original date posted:2021-07-01 📝 Original message: BOLTs should be BIPs too. ...
📅 Original date posted:2021-07-01
📝 Original message:
BOLTs should be BIPs too. Ideally, the authors should be the ones to migrate
them, but mirroring is fine - just nobody's taken the time to do it yet.
Please stop promoting lies about the BIP repo. I did not "steelman" anything.
Adding a third BIP editor more involved with Lightning sounds like a good
idea.
On Thursday 01 July 2021 20:25:23 Olaoluwa Osuntokun wrote:
> > BIPs are already the Bazaar style of evolution that simultaneously
> > allows flexibility and coordination/interoperability (since anyone can
>
> create a
>
> > BIP and they create an environment of discussion).
>
> The answer to why not BIPs here applies to BOLTs as well, as bLIPs are
> intended to effectively be nested under the BOLT umbrella (same repo, etc).
> It's also the case that any document can be mirrored as a BIP, this has
> been suggested before, but the BIP editors have decided not to do so.
>
> bLIPs have a slightly different process than BIPs, as well as a different
> set
> of editors/maintainers (more widely distributed). As we saw with the Speedy
> Trial saga (fingers crossed), the sole (?) maintainer of the BIP process
> was able to effectively steelman the progression of an author document,
> with no sound technical objection (they had a competing proposal that
> could've been a distinct document). bLIPs sidestep shenanigans like this by
> having the primary maintainer/editors be more widely distributed and closer
> to the target domain (LN).
>
> The other thing bLIPs do is do away with the whole "human picks the number
> of documents", and "don't assign your own number, you must wait". Borrowing
> from EIPs, the number of a document is simply the number of the PR that
> proposes the document. This reduces friction, and eliminates a possible
> bikeshedding vector.
>
> -- Laolu
>
> On Wed, Jun 30, 2021 at 5:31 PM Ariel Luaces <arielluaces at gmail.com> wrote:
> > BIPs are already the Bazaar style of evolution that simultaneously
> > allows flexibility and coordination/interoperability (since anyone can
> > create a BIP and they create an environment of discussion).
> >
> > BOLTs are essentially one big BIP in the sense that they started as a
> > place for discussion but are now more rigid. BOLTs must be followed
> > strictly to ensure a node is interoperable with the network. And BOLTs
> > should be rigid, as rigid as any widely used BIP like 32 for example.
> > Even though BOLTs were flexible when being drafted their purpose has
> > changed from descriptive to prescriptive.
> > Any alternatives, or optional features should be extracted out of
> > BOLTs, written as BIPs. The BIP should then reference the BOLT and the
> > required flags set, messages sent, or alterations made to signal that
> > the BIP's feature is enabled.
> >
> > A BOLT may at some point organically change to reference a BIP. For
> > example if a BIP was drafted as an optional feature but then becomes
> > more widespread and then turns out to be crucial for the proper
> > operation of the network then a BOLT can be changed to just reference
> > the BIP as mandatory. There isn't anything wrong with this.
> >
> > All of the above would work exactly the same if there was a bLIP
> > repository instead. I don't see the value in having both bLIPs and
> > BIPs since AFAICT they seem to be functionally equivalent and BIPs are
> > not restricted to exclude lightning, and never have been.
> >
> > I believe the reason this move to BIPs hasn't happened organically is
> > because many still perceive the BOLTs available for editing, so
> > changes continue to be made. If instead BOLTs were perceived as more
> > "consensus critical", not subject to change, and more people were
> > strongly encouraged to write specs for new lightning features
> > elsewhere (like the BIP repo) then you would see this issue of growing
> > BOLTs resolved.
> >
> > Cheers
> > Ariel Lorenzo-Luaces
> >
> > On Wed, Jun 30, 2021 at 1:16 PM Olaoluwa Osuntokun <laolu32 at gmail.com>
> >
> > wrote:
> > > > 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/00136
> >7.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/00307
> >4.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/002
> >780.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
> > >
> > > _______________________________________________
> > > Lightning-dev mailing list
> > > Lightning-dev at lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
📝 Original message:
BOLTs should be BIPs too. Ideally, the authors should be the ones to migrate
them, but mirroring is fine - just nobody's taken the time to do it yet.
Please stop promoting lies about the BIP repo. I did not "steelman" anything.
Adding a third BIP editor more involved with Lightning sounds like a good
idea.
On Thursday 01 July 2021 20:25:23 Olaoluwa Osuntokun wrote:
> > BIPs are already the Bazaar style of evolution that simultaneously
> > allows flexibility and coordination/interoperability (since anyone can
>
> create a
>
> > BIP and they create an environment of discussion).
>
> The answer to why not BIPs here applies to BOLTs as well, as bLIPs are
> intended to effectively be nested under the BOLT umbrella (same repo, etc).
> It's also the case that any document can be mirrored as a BIP, this has
> been suggested before, but the BIP editors have decided not to do so.
>
> bLIPs have a slightly different process than BIPs, as well as a different
> set
> of editors/maintainers (more widely distributed). As we saw with the Speedy
> Trial saga (fingers crossed), the sole (?) maintainer of the BIP process
> was able to effectively steelman the progression of an author document,
> with no sound technical objection (they had a competing proposal that
> could've been a distinct document). bLIPs sidestep shenanigans like this by
> having the primary maintainer/editors be more widely distributed and closer
> to the target domain (LN).
>
> The other thing bLIPs do is do away with the whole "human picks the number
> of documents", and "don't assign your own number, you must wait". Borrowing
> from EIPs, the number of a document is simply the number of the PR that
> proposes the document. This reduces friction, and eliminates a possible
> bikeshedding vector.
>
> -- Laolu
>
> On Wed, Jun 30, 2021 at 5:31 PM Ariel Luaces <arielluaces at gmail.com> wrote:
> > BIPs are already the Bazaar style of evolution that simultaneously
> > allows flexibility and coordination/interoperability (since anyone can
> > create a BIP and they create an environment of discussion).
> >
> > BOLTs are essentially one big BIP in the sense that they started as a
> > place for discussion but are now more rigid. BOLTs must be followed
> > strictly to ensure a node is interoperable with the network. And BOLTs
> > should be rigid, as rigid as any widely used BIP like 32 for example.
> > Even though BOLTs were flexible when being drafted their purpose has
> > changed from descriptive to prescriptive.
> > Any alternatives, or optional features should be extracted out of
> > BOLTs, written as BIPs. The BIP should then reference the BOLT and the
> > required flags set, messages sent, or alterations made to signal that
> > the BIP's feature is enabled.
> >
> > A BOLT may at some point organically change to reference a BIP. For
> > example if a BIP was drafted as an optional feature but then becomes
> > more widespread and then turns out to be crucial for the proper
> > operation of the network then a BOLT can be changed to just reference
> > the BIP as mandatory. There isn't anything wrong with this.
> >
> > All of the above would work exactly the same if there was a bLIP
> > repository instead. I don't see the value in having both bLIPs and
> > BIPs since AFAICT they seem to be functionally equivalent and BIPs are
> > not restricted to exclude lightning, and never have been.
> >
> > I believe the reason this move to BIPs hasn't happened organically is
> > because many still perceive the BOLTs available for editing, so
> > changes continue to be made. If instead BOLTs were perceived as more
> > "consensus critical", not subject to change, and more people were
> > strongly encouraged to write specs for new lightning features
> > elsewhere (like the BIP repo) then you would see this issue of growing
> > BOLTs resolved.
> >
> > Cheers
> > Ariel Lorenzo-Luaces
> >
> > On Wed, Jun 30, 2021 at 1:16 PM Olaoluwa Osuntokun <laolu32 at gmail.com>
> >
> > wrote:
> > > > That being said I think all the points that are addressed in Ryan's
> >
> >
> > > > 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/00136
> >7.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/00307
> >4.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/002
> >780.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
> > >
> > > _______________________________________________
> > > Lightning-dev mailing list
> > > Lightning-dev at lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev