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 <ariellua...@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 <laol...@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@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@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@lists.linuxfoundation.org > > >>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > >> > > >> -- > > >> https://www.rene-pickhardt.de > > >> _______________________________________________ > > >> Lightning-dev mailing list > > >> Lightning-dev@lists.linuxfoundation.org > > >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > > > > > _______________________________________________ > > > Lightning-dev mailing list > > > Lightning-dev@lists.linuxfoundation.org > > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
