If the BIPs can allow very small standards related to a small niche of
Lightning usage, then I think they are the place for everything indeed. I'm
convinced.
Thinking about proposing the LNURL specs as BIPs now, but then I don't know
if it will be weird for them to exist alone there, without the
Yes, many systems doesn't really make sense. We can add editors and revise the
BIP process as needed (BOLTs might prefer to use markdown?). Even aside from
Lightning BIPs, there are several improvements that can be made, so it makes
sense to address everything at once.
Hi Ryan,
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
Hi,
There will be many layer 2 (and probably layer 3) protocols (BOLT, RGB,
Volts etc...) does it really make sense to merge them all into the BIPs
system?
On Fri, Jul 2, 2021 at 10:03 AM nathanael via Lightning-dev <
lightning-dev@lists.linuxfoundation.org> wrote:
> Michael Folkson wrote:
>
Michael Folkson wrote:
> > Adding a third BIP editor more involved with Lightning sounds like a good
> > idea.
>
> Or alternatively if BOLTs were subsumed into BIPs I think Bastien
> would be a great additional BIP editor to cover Lightning related BIPs
> :) I think BOLTs being subsumed into
> 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
("bLIPs") to
>
> 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
> any
> implementation to start to work on their own sub-protocols. This just gives
> them a new venue to at least _describe_ what they're
