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
hello René,
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
Hi Rene,
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 [1]
simply adds a new bLIPs
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
Or just use BIPs instead of further fracturing...?
On Jun 30, 2021 10:10 AM, Ryan Gentry via Lightning-dev
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
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
>
> - MUST NOT send `announcement_signatures` messages until `funding_locked`
> has been sent and received AND the funding transaction has at least
> six confirmations.
>
> So still compliant there?
>
Great, I hadn't spotted that one, so we're good on the
`announcement_signatures` side.
