📅 Original date posted:2021-07-01
📝 Original message:
Thanks for starting that discussion.
In my opinion, what we're really trying to address here are the two
following
points (at least from the point of view of someone who works on the spec and
an implementation):
- Implementers get frustrated when they've worked on something that they
think
is useful and they can't get it into the BOLTs (the spec PR isn't reviewed,
it progresses too slowly or there isn't enough agreement to merge it)
- Implementers expect other implementers to specify the optional features
they
ship: we don't want to have to reverse-engineer a sub-protocol when users
want our implementation to provide support for feature XXX
Note that these are two very different concerns.
bLIPs/SPARKS/BIPs clearly address the second point, which is good.
But they don't address the first point at all, they instead work around it.
To be fair, I don't think we can completely address that first point:
properly
reviewing spec proposals takes a lot of effort and accepting complex changes
to the BOLTs shouldn't be done lightly.
I am mostly in favor of this solution, but I want to highlight that it isn't
only rainbows and unicorns: it will add fragmentation to the network, it
will
add maintenance costs and backwards-compatibility issues, many bLIPs will be
sub-optimal solutions to the problem they try to solve and some bLIPs will
be
simply insecure and may put users' funds at risk (L2 protocols are hard and
have
subtle issues that can be easily missed). On the other hand, it allows for
real
world experimentation and iteration, and it's easier to amend a bLIP than
the
BOLTs.
On the nuts-and-bolts (see the pun?) side, bLIPs cannot embrace a fully
bazaar
style of evolution. Most of them will need:
- to assign feature bit(s)
- to insert new tlv fields in existing messages
- to create new messages
We can't have collisions on any of these three things. bLIP XXX cannot use
the
same tlv types as bLIP YYY otherwise we're creating network
incompatibilities.
So they really need to be centralized, and we need a process to assign these
and ensure they don't collide. It's not a hard problem, but we need to be
clear
about the process around those.
Regarding the details of where they live, I don't have a strong opinion,
but I
think they must be easy to find and browse, and I think it's easier for
readers
if they're inside the spec repository. We already have PRs that use a
dedicated
"proposals" folder (e.g. [1], [2]).
Cheers,
Bastien
[1] https://github.com/lightningnetwork/lightning-rfc/pull/829
[2] https://github.com/lightningnetwork/lightning-rfc/pull/854
Le jeu. 1 juil. 2021 à 02:31, Ariel Luaces <arielluaces at gmail.com> a écrit :
> 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/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
> >
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210701/db735010/attachment-0001.html>;
Bastien TEINTURIER [ARCHIVE] /
npub17f…ntr0s
2023-06-09 13:02:51
in reply to nevent1q…kqan
Author Public Key
npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0sPublished at
2023-06-09 13:02:51Event JSON
{
"id": "731227212ad842ed05af1b60c86a70b2b3c920b77d458e0828ab81808eb24001",
"pubkey": "f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb",
"created_at": 1686315771,
"kind": 1,
"tags": [
[
"e",
"c12a56d1a7e25337ae2ab2c653c3343c3f8b8001e48f95cd80b522438e1c618c",
"",
"root"
],
[
"e",
"2f43c7b2e74dac55e39b1b690ed76a8c9a0e85d778b60bcdb36b25dbaa8081da",
"",
"reply"
],
[
"p",
"ebed449fcaac35befed3b0f55f70eef25ed95542b26fd12595522daa62016304"
]
],
"content": "📅 Original date posted:2021-07-01\n📝 Original message:\nThanks for starting that discussion.\n\nIn my opinion, what we're really trying to address here are the two\nfollowing\npoints (at least from the point of view of someone who works on the spec and\nan implementation):\n\n- Implementers get frustrated when they've worked on something that they\nthink\nis useful and they can't get it into the BOLTs (the spec PR isn't reviewed,\nit progresses too slowly or there isn't enough agreement to merge it)\n- Implementers expect other implementers to specify the optional features\nthey\nship: we don't want to have to reverse-engineer a sub-protocol when users\nwant our implementation to provide support for feature XXX\n\nNote that these are two very different concerns.\n\nbLIPs/SPARKS/BIPs clearly address the second point, which is good.\nBut they don't address the first point at all, they instead work around it.\nTo be fair, I don't think we can completely address that first point:\nproperly\nreviewing spec proposals takes a lot of effort and accepting complex changes\nto the BOLTs shouldn't be done lightly.\n\nI am mostly in favor of this solution, but I want to highlight that it isn't\nonly rainbows and unicorns: it will add fragmentation to the network, it\nwill\nadd maintenance costs and backwards-compatibility issues, many bLIPs will be\nsub-optimal solutions to the problem they try to solve and some bLIPs will\nbe\nsimply insecure and may put users' funds at risk (L2 protocols are hard and\nhave\nsubtle issues that can be easily missed). On the other hand, it allows for\nreal\nworld experimentation and iteration, and it's easier to amend a bLIP than\nthe\nBOLTs.\n\nOn the nuts-and-bolts (see the pun?) side, bLIPs cannot embrace a fully\nbazaar\nstyle of evolution. Most of them will need:\n\n- to assign feature bit(s)\n- to insert new tlv fields in existing messages\n- to create new messages\n\nWe can't have collisions on any of these three things. bLIP XXX cannot use\nthe\nsame tlv types as bLIP YYY otherwise we're creating network\nincompatibilities.\nSo they really need to be centralized, and we need a process to assign these\nand ensure they don't collide. It's not a hard problem, but we need to be\nclear\nabout the process around those.\n\nRegarding the details of where they live, I don't have a strong opinion,\nbut I\nthink they must be easy to find and browse, and I think it's easier for\nreaders\nif they're inside the spec repository. We already have PRs that use a\ndedicated\n\"proposals\" folder (e.g. [1], [2]).\n\nCheers,\nBastien\n\n[1] https://github.com/lightningnetwork/lightning-rfc/pull/829\n[2] https://github.com/lightningnetwork/lightning-rfc/pull/854\n\nLe jeu. 1 juil. 2021 à 02:31, Ariel Luaces \u003carielluaces at gmail.com\u003e a écrit :\n\n\u003e BIPs are already the Bazaar style of evolution that simultaneously\n\u003e allows flexibility and coordination/interoperability (since anyone can\n\u003e create a BIP and they create an environment of discussion).\n\u003e\n\u003e BOLTs are essentially one big BIP in the sense that they started as a\n\u003e place for discussion but are now more rigid. BOLTs must be followed\n\u003e strictly to ensure a node is interoperable with the network. And BOLTs\n\u003e should be rigid, as rigid as any widely used BIP like 32 for example.\n\u003e Even though BOLTs were flexible when being drafted their purpose has\n\u003e changed from descriptive to prescriptive.\n\u003e Any alternatives, or optional features should be extracted out of\n\u003e BOLTs, written as BIPs. The BIP should then reference the BOLT and the\n\u003e required flags set, messages sent, or alterations made to signal that\n\u003e the BIP's feature is enabled.\n\u003e\n\u003e A BOLT may at some point organically change to reference a BIP. For\n\u003e example if a BIP was drafted as an optional feature but then becomes\n\u003e more widespread and then turns out to be crucial for the proper\n\u003e operation of the network then a BOLT can be changed to just reference\n\u003e the BIP as mandatory. There isn't anything wrong with this.\n\u003e\n\u003e All of the above would work exactly the same if there was a bLIP\n\u003e repository instead. I don't see the value in having both bLIPs and\n\u003e BIPs since AFAICT they seem to be functionally equivalent and BIPs are\n\u003e not restricted to exclude lightning, and never have been.\n\u003e\n\u003e I believe the reason this move to BIPs hasn't happened organically is\n\u003e because many still perceive the BOLTs available for editing, so\n\u003e changes continue to be made. If instead BOLTs were perceived as more\n\u003e \"consensus critical\", not subject to change, and more people were\n\u003e strongly encouraged to write specs for new lightning features\n\u003e elsewhere (like the BIP repo) then you would see this issue of growing\n\u003e BOLTs resolved.\n\u003e\n\u003e Cheers\n\u003e Ariel Lorenzo-Luaces\n\u003e\n\u003e On Wed, Jun 30, 2021 at 1:16 PM Olaoluwa Osuntokun \u003claolu32 at gmail.com\u003e\n\u003e wrote:\n\u003e \u003e\n\u003e \u003e \u003e That being said I think all the points that are addressed in Ryan's\n\u003e mail\n\u003e \u003e \u003e could very well be formalized into BOLTs but maybe we just need to\n\u003e rethink\n\u003e \u003e \u003e the current process of the BOLTs to make it more accessible for new\n\u003e ideas\n\u003e \u003e \u003e to find their way into the BOLTs?\n\u003e \u003e\n\u003e \u003e I think part of what bLIPs are trying to solve here is promoting more\n\u003e loosely\n\u003e \u003e coupled evolution of the network. I think the BOLTs do a good job\n\u003e currently of\n\u003e \u003e specifying what _base_ functionality is required for a routing node in a\n\u003e \u003e prescriptive manner (you must forward an HTLC like this, etc). However\n\u003e there's\n\u003e \u003e a rather large gap in describing functionality that has emerged over\n\u003e time due\n\u003e \u003e to progressive evolution, and aren't absolutely necessary, but enhance\n\u003e \u003e node/wallet operation.\n\u003e \u003e\n\u003e \u003e Examples of include things like: path finding heuristics (BOLTs just\n\u003e say you\n\u003e \u003e should get from Alice to Bob, but provides no recommendations w.r.t\n\u003e _how_ to do\n\u003e \u003e so), fee bumping heuristics, breach retribution handling, channel\n\u003e management,\n\u003e \u003e rebalancing, custom records usage (like the podcast index meta-data,\n\u003e messaging,\n\u003e \u003e etc), JIT channel opening, hosted channels, randomized channel IDs, fee\n\u003e \u003e optimization, initial channel boostrapping, etc.\n\u003e \u003e\n\u003e \u003e All these examples are effectively optional as they aren't required for\n\u003e base\n\u003e \u003e node operation, but they've organically evolved over time as node\n\u003e \u003e implementations and wallet seek to solve UX and operational problems for\n\u003e \u003e their users. bLIPs can be a _descriptive_ (this is how things can be\n\u003e done)\n\u003e \u003e home for these types of standards, while BOLTs can be reserved for\n\u003e \u003e _prescriptive_ measures (an HTLC looks like this, etc).\n\u003e \u003e\n\u003e \u003e The protocol as implemented today has a number of extensions (TLVs,\n\u003e message\n\u003e \u003e types, feature bits, etc) that allow implementations to spin out their\n\u003e own\n\u003e \u003e sub-protocols, many of which won't be considered absolutely necessary\n\u003e for node\n\u003e \u003e operation. IMO we should embrace more of a \"bazaar\" style of evolution,\n\u003e and\n\u003e \u003e acknowledge that loosely coupled evolution allows participants to more\n\u003e broadly\n\u003e \u003e explore the design space, without the constraints of \"it isn't a thing\n\u003e until N\n\u003e \u003e of us start to do it\".\n\u003e \u003e\n\u003e \u003e Historically, BOLTs have also had a rather monolithic structure. We've\n\u003e used\n\u003e \u003e the same 11 or so documents for the past few years with the size of the\n\u003e \u003e documents swelling over time with new exceptions, features, requirements,\n\u003e \u003e etc. If you were hired to work on a new codebase and saw that everything\n\u003e is\n\u003e \u003e defined in 11 \"functions\" that have been growing linearly over time,\n\u003e you'd\n\u003e \u003e probably declare the codebase as being unmaintainable. By having distinct\n\u003e \u003e documents for proposals/standards, bLIPs (author documents really), each\n\u003e new\n\u003e \u003e standard/proposal is able to be more effectively explained, motivated,\n\u003e versionsed,\n\u003e \u003e etc.\n\u003e \u003e\n\u003e \u003e -- Laolu\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e On Wed, Jun 30, 2021 at 7:35 AM René Pickhardt via Lightning-dev \u003c\n\u003e lightning-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e\u003e\n\u003e \u003e\u003e Hey everyone,\n\u003e \u003e\u003e\n\u003e \u003e\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 \u003e\u003e\n\u003e \u003e\u003e I wonder what exactly has changed in the reasoning by roasbeef which I\n\u003e will repeat here:\n\u003e \u003e\u003e\n\u003e \u003e\u003e \u003e We already have the equiv of improvement proposals: BOLTs.\n\u003e Historically\n\u003e \u003e\u003e\n\u003e \u003e\u003e \u003e new standardization documents are proposed initially as issues or\n\u003e PR's when\n\u003e \u003e\u003e\n\u003e \u003e\u003e \u003e ultimately accepted. Why do we need another repo?\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e As far as I can tell there was always some form of (invisible?) barrier\n\u003e to participate in the BOLTs but there are also new BOLTs being offered:\n\u003e \u003e\u003e * BOLT 12: https://github.com/lightningnetwork/lightning-rfc/pull/798\n\u003e \u003e\u003e * BOLT 14: https://github.com/lightningnetwork/lightning-rfc/pull/780\n\u003e \u003e\u003e and topics to be included like:\n\u003e \u003e\u003e * dual funding\n\u003e \u003e\u003e * splicing\n\u003e \u003e\u003e * the examples given by Ryan\n\u003e \u003e\u003e\n\u003e \u003e\u003e I don't see how a new repo would reduce that barrier - Actually I think\n\u003e it 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 \u003e\u003e\n\u003e \u003e\u003e with kind regards Rene\n\u003e \u003e\u003e\n\u003e \u003e\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 \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e Hi all,\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e The recent thread around zero-conf channels [1] provides an\n\u003e opportunity to discuss how the BOLT process handles features and best\n\u003e practices that arise in the wild vs. originating within the process itself.\n\u003e Zero-conf channels are one of many LN innovations on the app layer that\n\u003e have struggled to make their way into the spec. John Carvalho and Bitrefill\n\u003e launched Turbo channels in April 2019 [2], Breez posted their solution to\n\u003e the mailing list for feedback in August 2020 [3], and we know at least\n\u003e ACINQ and Muun (amongst others) have their own implementations. In an ideal\n\u003e world there would be a descriptive design document that the app layer\n\u003e implementers had collaborated on over the years that the spec group could\n\u003e then pick up and merge into the BOLTs now that the feature is deemed\n\u003e spec-worthy.\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\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\n\u003e members of the community, and have received positive feedback from both app\n\u003e layer and protocol devs. This would not affect the existing BOLT process at\n\u003e all, but simply add a place for app layer best practices to be succinctly\n\u003e described and organized, especially those that require coordination. These\n\u003e features are being built outside of the BOLT process today anyways, so\n\u003e ideally a bLIP process would bring them into the fold instead of leaving\n\u003e them buried in old ML posts or not documented at all.\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e Some potential bLIP ideas that people have mentioned include: each\n\u003e lnurl variant, on-the-fly channel opens, AMP, dynamic commitments, podcast\n\u003e payment metadata, p2p messaging formats, new pathfinding heuristics, remote\n\u003e node connection standards, etc.\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e If the community is interested in moving forward, we've started a\n\u003e branch [5] describing such a process. It's based on BIP-0002, so not trying\n\u003e to reinvent any wheels. It would be great to have developers from various\n\u003e implementations and from the broader app layer ecosystem volunteer to be\n\u003e listed as editors (basically the same role as in the BIPs).\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e Looking forward to hearing your thoughts!\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e Best,\n\u003e \u003e\u003e\u003e Ryan\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e [1]\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-June/003074.html\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e [2]\n\u003e https://www.coindesk.com/bitrefills-thor-turbo-lets-you-get-started-with-bitcoins-lightning-faster\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e [3]\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-August/002780.html\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e [4] bLIP = Bitcoin Lightning Improvement Proposal and SPARK =\n\u003e Standardization of Protocols at the Request of the Kommunity (h/t fiatjaf)\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e [5]\n\u003e https://github.com/ryanthegentry/lightning-rfc/blob/blip-0001/blips/blip-0001.mediawiki\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e _______________________________________________\n\u003e \u003e\u003e\u003e Lightning-dev mailing list\n\u003e \u003e\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e \u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e --\n\u003e \u003e\u003e https://www.rene-pickhardt.de\n\u003e \u003e\u003e _______________________________________________\n\u003e \u003e\u003e Lightning-dev mailing list\n\u003e \u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e \u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e \u003e\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 _______________________________________________\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\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210701/db735010/attachment-0001.html\u003e",
"sig": "8119ceeca833bc3449556db535551164359a72452ad61c6a35340e8d72010fbaefd1911274ba0ed83f026e7d33a793dd25768eac73b632c75369b5ca3ff0708c"
}