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
Hi all,
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!).
If
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
> 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
> 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
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
Here's another feature which just appeared and would benefit from a
bLIP for compatibility:
https://twitter.com/SimpleBtcWallet/status/1410506889545359365
Atomic splitting of bills. A very small thing, but also very cool. I
can't imagine it fitting in the BOLTs at all.
2021-06-30 09:10
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
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
18 matches
Mail list logo
