fiatjaf [ARCHIVE] on Nostr: 📅 Original date posted:2021-07-02 📝 Original message: If the BIPs can allow ...

📅 Original date posted:2021-07-02
📝 Original message:
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 basis of the
lightning technology to support them. I hope the BOLT authors investigate
moving them there too so the other Lightning BIPs can add the BOLT BIPs as
"Required".

The only question to me is this: should each BOLT be a BIP? Or all BOLTs be
mashed together as a single BIP? Then what happens when Taproot-based
channels, PTLCs or Eltoo-based channels get implemented? They are added as
new BIPs that inherit and modify the previous?

I also went through
https://github.com/bitcoin/bips/wiki/BIP-Process-wishlist and to me they
seem to be all good proposals (specially the list of projects/services
implementing the BIP). Except BIP versioning. I like that BIPs have
meaningless numbers, just add another BIP and refer to it by a number. For
that reason I also don't like prepending an "L" to Lightning-related BIPs
(more so because some of these may be reused later in non-Lightning
contexts, who knows?). Anyway I'm fine with anything.

On Fri, Jul 2, 2021 at 4:32 PM Luke Dashjr <luke at dashjr.org> wrote:

> 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.
>
> https://github.com/bitcoin/bips/wiki/BIP-Process-wishlist
>
> The BIP 2xx range has been set aside for Lightning years ago, and we can
> do
> similar things to help keep things organized within BIPs. Kalle suggested
> maybe it'd be better to do BIP "L###" instead, and perhaps that would work
> better if there's likely to be several sub-namespaces.
>
> Luke
>
>
> On Friday 02 July 2021 12:02:28 Dan Gershony wrote:
> > 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 at lists.linuxfoundation.org> wrote:
> > > Michael Folkson <michaelfolkson at gmail.com> 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 BIPs would be nice but I'm
> > > >
> > > > pessimistic it will happen. Like legislation and regulation in the
> > > > legacy financial system alphabet soups only expand they never get
> > > > simplified. Let's at least resist alphabet soup expansion here.
> > >
> > > arent lightning improvements in the end bitcoin improvements too?
> > > i am thinking of bips like the rfcs of the internet
> > >
> > > --
> > > nathanael
> > > _______________________________________________
> > > Lightning-dev mailing list
> > > Lightning-dev at lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210702/abb5b479/attachment.html>;