From fiatjaf at gmail.com Fri Jul 2 20:11:46 2021 From: fiatjaf at gmail.com (fiatjaf) Date: Fri, 2 Jul 2021 17:11:46 -0300 Subject: [Lightning-dev] bLIPs: A proposal for community-driven app layer and protocol extension stand In-Reply-To: <202107021931.59781.luke@dashjr.org> References: <2Q0B97XGHB0JK.26NR7TWXZV5BD@dalliard.ch> <202107021931.59781.luke@dashjr.org> Message-ID: 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 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 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: