On Fri, Jul 02, 2021 at 02:20:51PM -0400, Antoine Riard wrote:
> More personally, I feel it would be better if such a new specification
> process doesn't completely share the same communication infrastructure as
> the BOLTs, like [avoiding] having them in the same repository.
In addition to
Thanks so much for the great feedback over the last week. Seems like
general agreement that adding a simple home for descriptive design
documents focusing on new LN features would be a good thing, and augment
the prescriptive BOLTs (which have done a great job getting us this far!).
Thanks for starting this discussion, I agree it's a good time for the
Lightning development community to start this self-introspection on its own
specification process :)
First and foremost, maybe we could take a minute off to celebrate the
success of the BOLT process and the road
> 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".
So TL;DR BIPs and BOLTs sometimes require waiting for things (like
review and consensus) and there should be a new acronym and process
> Will it actually add any more fragmentation that already exists? Due to all
> the extensibility we've added in the protocol, it's already possible for
> implementation to start to work on their own sub-protocols. This just gives
> them a new venue to at least _describe_ what they're
> 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
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
> 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 think this is
> BIPs are already the Bazaar style of evolution that simultaneously
> allows flexibility and coordination/interoperability (since anyone can
> BIP and they create an environment of discussion).
The answer to why not BIPs here applies to BOLTs as well, as bLIPs are
Here's another feature which just appeared and would benefit from a
bLIP for compatibility:
Atomic splitting of bills. A very small thing, but also very cool. I
can't imagine it fitting in the BOLTs at all.
Thanks for starting that discussion.
In my opinion, what we're really trying to address here are the two
points (at least from the point of view of someone who works on the spec and
- Implementers get frustrated when they've worked on something that they
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
> 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
I think the idea of having separate standards is good because we can
keep the core spec mandatory and other things optional.
Since the core spec, defined by the BOLTs, is mandatory, it's better
if it's as small as possible, basically barely enough to allow peers
to talk to each other
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 
simply adds a new bLIPs
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.:
I wonder what exactly has changed in the reasoning by
Or just use BIPs instead of further fracturing...?
On Jun 30, 2021 10:10 AM, Ryan Gentry via Lightning-dev
> Hi all,
> The recent thread around zero-conf channels  provides an opportunity to
> discuss how the BOLT process handles features and best practices that arise
> in the
The recent thread around zero-conf channels  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
Mail list logo