Re: [Lightning-dev] bLIPs: A proposal for community-driven app layer and protocol extension standardization

2021-06-30 Thread Ariel Luaces
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 now more rigid. BOLTs must be followed
strictly to ensure a node is interoperable with the network. And BOLTs
should be rigid, as rigid as any widely used BIP like 32 for example.
Even though BOLTs were flexible when being drafted their purpose has
changed from descriptive to prescriptive.
Any alternatives, or optional features should be extracted out of
BOLTs, written as BIPs. The BIP should then reference the BOLT and the
required flags set, messages sent, or alterations made to signal that
the BIP's feature is enabled.

A BOLT may at some point organically change to reference a BIP. For
example if a BIP was drafted as an optional feature but then becomes
more widespread and then turns out to be crucial for the proper
operation of the network then a BOLT can be changed to just reference
the BIP as mandatory. There isn't anything wrong with this.

All of the above would work exactly the same if there was a bLIP
repository instead. I don't see the value in having both bLIPs and
BIPs since AFAICT they seem to be functionally equivalent and BIPs are
not restricted to exclude lightning, and never have been.

I believe the reason this move to BIPs hasn't happened organically is
because many still perceive the BOLTs available for editing, so
changes continue to be made. If instead BOLTs were perceived as more
"consensus critical", not subject to change, and more people were
strongly encouraged to write specs for new lightning features
elsewhere (like the BIP repo) then you would see this issue of growing
BOLTs resolved.

Cheers
Ariel Lorenzo-Luaces

On Wed, Jun 30, 2021 at 1:16 PM Olaoluwa Osuntokun  wrote:
>
> > 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 trying to solve here is promoting more loosely
> coupled evolution of the network. I think the BOLTs do a good job currently of
> specifying what _base_ functionality is required for a routing node in a
> prescriptive manner (you must forward an HTLC like this, etc). However there's
> a rather large gap in describing functionality that has emerged over time due
> to progressive evolution, and aren't absolutely necessary, but enhance
> node/wallet operation.
>
> Examples of  include things like: path finding heuristics (BOLTs just say you
> should get from Alice to Bob, but provides no recommendations w.r.t _how_ to 
> do
> so), fee bumping heuristics, breach retribution handling, channel management,
> rebalancing, custom records usage (like the podcast index meta-data, 
> messaging,
> etc), JIT channel opening, hosted channels, randomized channel IDs, fee
> optimization, initial channel boostrapping, etc.
>
> All these examples are effectively optional as they aren't required for base
> node operation, but they've organically evolved over time as node
> implementations and wallet seek to solve UX and operational problems for
> their users. bLIPs can be a _descriptive_ (this is how things can be done)
> home for these types of standards, while BOLTs can be reserved for
> _prescriptive_ measures (an HTLC looks like this, etc).
>
> The protocol as implemented today has a number of extensions (TLVs, message
> types, feature bits, etc) that allow implementations to spin out their own
> sub-protocols, many of which won't be considered absolutely necessary for node
> operation. IMO we should embrace more of a "bazaar" style of evolution, and
> acknowledge that loosely coupled evolution allows participants to more broadly
> explore the design space, without the constraints of "it isn't a thing until N
> of us start to do it".
>
> Historically, BOLTs have also had a rather monolithic structure. We've used
> the same 11 or so documents for the past few years with the size of the
> documents swelling over time with new exceptions, features, requirements,
> etc. If you were hired to work on a new codebase and saw that everything is
> defined in 11 "functions" that have been growing linearly over time, you'd
> probably declare the codebase as being unmaintainable. By having distinct
> documents for proposals/standards, bLIPs (author documents really), each new
> standard/proposal is able to be more effectively explained, motivated, 
> versionsed,
> etc.
>
> -- Laolu
>
>
> On Wed, Jun 30, 2021 at 7:35 AM René Pickhardt via Lightning-dev 
>  wrote:
>>
>> 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.: 
>> 

Re: [Lightning-dev] Turbo channels spec?

2021-06-30 Thread Bastien TEINTURIER
>
> - 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.

I'm wondering if `option_zeroconf` implies that we should set `min_depth =
0` in
`accept_channel`, since that's the number of confirmations before we can
send
`funding_locked`.

We need a signal that this channel uses zero-conf, and the two obvious
choices are:

   - set `min_depth = 0`
   - use a `channel_type` that sets `option_zeroconf`

I think the second option is better, this way we can keep a "normal"
`min_depth` set
and when we send `funding_locked`, we know that the channel is now
perfectly safe
to use (out of the zero-conf zone).

Cheers,
Bastien



Le mer. 30 juin 2021 à 02:09, Rusty Russell  a
écrit :

> Bastien TEINTURIER  writes:
> > Hi Rusty,
> >
> > On the eclair side, we instead send `funding_locked` as soon as we
> > see the funding tx in the mempool.
> >
> > But I think your proposal would work as well.
>
> This would be backward compatible, I think.  Eclair would send
> `funding_locked`, which is perfectly legal, but a normal peer would
> still wait for confirms before also sending `funding_locked`; it's
> just that option_zeroconf_channels would mean it doesn't have to
> wait for that before sending HTLCs?
>
> > We may want to defer sending `announcement_signatures` until
> > after the funding tx has been confirmed? What `min_depth` should
> > we use here? Should we keep a non-zero value in `accept_channel`
> > or should it be zero?
>
> You can't send it before you know the channel_id, so it has to be at
> least 1.  Spec says:
>
>   - 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?
>
> Cheers,
> Rusty.
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


Re: [Lightning-dev] bLIPs: A proposal for community-driven app layer and protocol extension standardization

2021-06-30 Thread René Pickhardt via Lightning-dev
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 roasbeef which I will
repeat here:

*> We already have the equiv of improvement proposals: BOLTs. Historically*

>* new standardization documents are proposed initially as issues or PR's when *

>* ultimately accepted. Why do we need another repo? *


As far as I can tell there was always some form of (invisible?) barrier to
participate in the BOLTs but there are also new BOLTs being offered:
* BOLT 12: https://github.com/lightningnetwork/lightning-rfc/pull/798
* BOLT 14: https://github.com/lightningnetwork/lightning-rfc/pull/780
and topics to be included like:
* dual funding
* splicing
* the examples given by Ryan

I don't see how a new repo would reduce that barrier - Actually I think it
would even create more confusion as I for example would not know where
something belongs. 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? One thing that I
can say from answering lightning-network questions on stackexchange is that
it would certainly help if the BOLTs where referenced  on lightning.network
web page and in the whitepaper as the place to be if one wants to learn
about the Lightning Network

with kind regards Rene

On Wed, Jun 30, 2021 at 4:10 PM Ryan Gentry via Lightning-dev <
lightning-dev@lists.linuxfoundation.org> 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 wild vs. originating within the process itself. Zero-conf channels
> are one of many LN innovations on the app layer that have struggled to make
> their way into the spec. John Carvalho and Bitrefill launched Turbo
> channels in April 2019 [2], Breez posted their solution to the mailing list
> for feedback in August 2020 [3], and we know at least ACINQ and Muun
> (amongst others) have their own implementations. In an ideal world there
> would be a descriptive design document that the app layer implementers had
> collaborated on over the years that the spec group could then pick up and
> merge into the BOLTs now that the feature is deemed spec-worthy.
>
> Over the last couple of months, we have discussed the idea of adding a
> BIP-style process (bLIPs? SPARKs? [4]) on top of the BOLTs with various
> members of the community, and have received positive feedback from both app
> layer and protocol devs. This would not affect the existing BOLT process at
> all, but simply add a place for app layer best practices to be succinctly
> described and organized, especially those that require coordination. These
> features are being built outside of the BOLT process today anyways, so
> ideally a bLIP process would bring them into the fold instead of leaving
> them buried in old ML posts or not documented at all.
>
> Some potential bLIP ideas that people have mentioned include: each lnurl
> variant, on-the-fly channel opens, AMP, dynamic commitments, podcast
> payment metadata, p2p messaging formats, new pathfinding heuristics, remote
> node connection standards, etc.
>
> If the community is interested in moving forward, we've started a branch
> [5] describing such a process. It's based on BIP-0002, so not trying to
> reinvent any wheels. It would be great to have developers from various
> implementations and from the broader app layer ecosystem volunteer to be
> listed as editors (basically the same role as in the BIPs).
>
> Looking forward to hearing your thoughts!
>
> Best,
> Ryan
>
> [1]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-June/003074.html
>
> [2]
> https://www.coindesk.com/bitrefills-thor-turbo-lets-you-get-started-with-bitcoins-lightning-faster
>
> [3]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-August/002780.html
>
> [4] bLIP = Bitcoin Lightning Improvement Proposal and SPARK =
> Standardization of Protocols at the Request of the Kommunity (h/t fiatjaf)
>
> [5]
> https://github.com/ryanthegentry/lightning-rfc/blob/blip-0001/blips/blip-0001.mediawiki
> ___
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>


-- 
https://www.rene-pickhardt.de
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


Re: [Lightning-dev] bLIPs: A proposal for community-driven app layer and protocol extension standardization

2021-06-30 Thread Ryan Gentry via Lightning-dev
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 folder in the existing repo (like you suggested as
an option in 2018)
2) major difference between 2018 and now is one of scale (which is a great
problem to have!). In 2018 the LN dev ecosystem was mostly ACINQ,
Blockstream, and Lightning Labs and the minimalist BOLTs process worked
well. At this point the broader ecosystem is significantly bigger than
those three teams combined, and it seems the process should adjust to
reflect the new environment.

The main goal of the suggested change is simply to provide a home for
emerging "best practices", especially those that require coordination
amongst multiple groups. I think LNURL provides a good example of a "best
practice" that has been spec'd out [2], is completely extra protocol so
probably doesn't belong as a BOLT, but carries tension with it for new
developers since it's been widely adopted yet not "officially supported".
What do you think about that?

Best,
Ryan

[1]
https://github.com/ryanthegentry/lightning-rfc/blob/blip-0001/blips/blip-0001.mediawiki
[2] https://github.com/fiatjaf/lnurl-rfc

On Wed, Jun 30, 2021 at 9:35 AM René Pickhardt 
wrote:

> 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 roasbeef which I
> will repeat here:
>
> *> We already have the equiv of improvement proposals: BOLTs. Historically*
>
> >* new standardization documents are proposed initially as issues or PR's 
> >when *
>
> >* ultimately accepted. Why do we need another repo? *
>
>
> As far as I can tell there was always some form of (invisible?) barrier to
> participate in the BOLTs but there are also new BOLTs being offered:
> * BOLT 12: https://github.com/lightningnetwork/lightning-rfc/pull/798
> * BOLT 14: https://github.com/lightningnetwork/lightning-rfc/pull/780
> and topics to be included like:
> * dual funding
> * splicing
> * the examples given by Ryan
>
> I don't see how a new repo would reduce that barrier - Actually I think it
> would even create more confusion as I for example would not know where
> something belongs. 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? One thing that I
> can say from answering lightning-network questions on stackexchange is that
> it would certainly help if the BOLTs where referenced  on lightning.network
> web page and in the whitepaper as the place to be if one wants to learn
> about the Lightning Network
>
> with kind regards Rene
>
> On Wed, Jun 30, 2021 at 4:10 PM Ryan Gentry via Lightning-dev <
> lightning-dev@lists.linuxfoundation.org> 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 wild vs. originating within the process itself. Zero-conf
>> channels are one of many LN innovations on the app layer that have
>> struggled to make their way into the spec. John Carvalho and Bitrefill
>> launched Turbo channels in April 2019 [2], Breez posted their solution to
>> the mailing list for feedback in August 2020 [3], and we know at least
>> ACINQ and Muun (amongst others) have their own implementations. In an ideal
>> world there would be a descriptive design document that the app layer
>> implementers had collaborated on over the years that the spec group could
>> then pick up and merge into the BOLTs now that the feature is deemed
>> spec-worthy.
>>
>> Over the last couple of months, we have discussed the idea of adding a
>> BIP-style process (bLIPs? SPARKs? [4]) on top of the BOLTs with various
>> members of the community, and have received positive feedback from both app
>> layer and protocol devs. This would not affect the existing BOLT process at
>> all, but simply add a place for app layer best practices to be succinctly
>> described and organized, especially those that require coordination. These
>> features are being built outside of the BOLT process today anyways, so
>> ideally a bLIP process would bring them into the fold instead of leaving
>> them buried in old ML posts or not documented at all.
>>
>> Some potential bLIP ideas that people have mentioned include: each lnurl
>> variant, on-the-fly channel opens, AMP, dynamic commitments, podcast
>> payment metadata, p2p messaging formats, new pathfinding heuristics, remote
>> node 

Re: [Lightning-dev] bLIPs: A proposal for community-driven app layer and protocol extension standardization

2021-06-30 Thread Luke Dashjr
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 wild vs. originating within the process itself. Zero-conf channels are 
> one of many LN innovations on the app layer that have struggled to make their 
> way into the spec. John Carvalho and Bitrefill launched Turbo channels in 
> April 2019 [2], Breez posted their solution to the mailing list for feedback 
> in August 2020 [3], and we know at least ACINQ and Muun (amongst others) have 
> their own implementations. In an ideal world there would be a descriptive 
> design document that the app layer implementers had collaborated on over the 
> years that the spec group could then pick up and merge into the BOLTs now 
> that the feature is deemed spec-worthy.
>
>
> Over the last couple of months, we have discussed the idea of adding a 
> BIP-style process (bLIPs? SPARKs? [4]) on top of the BOLTs with various 
> members of the community, and have received positive feedback from both app 
> layer and protocol devs. This would not affect the existing BOLT process at 
> all, but simply add a place for app layer best practices to be succinctly 
> described and organized, especially those that require coordination. These 
> features are being built outside of the BOLT process today anyways, so 
> ideally a bLIP process would bring them into the fold instead of leaving them 
> buried in old ML posts or not documented at all.
>
>
> Some potential bLIP ideas that people have mentioned include: each lnurl 
> variant, on-the-fly channel opens, AMP, dynamic commitments, podcast payment 
> metadata, p2p messaging formats, new pathfinding heuristics, remote node 
> connection standards, etc.
>
>
> If the community is interested in moving forward, we've started a branch [5] 
> describing such a process. It's based on BIP-0002, so not trying to reinvent 
> any wheels. It would be great to have developers from various implementations 
> and from the broader app layer ecosystem volunteer to be listed as editors 
> (basically the same role as in the BIPs). 
>
>
> Looking forward to hearing your thoughts!
>
>
> Best,
> Ryan
>
>
> [1] 
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-June/003074.html
>
> [2] 
> https://www.coindesk.com/bitrefills-thor-turbo-lets-you-get-started-with-bitcoins-lightning-faster
>
> [3] 
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-August/002780.html
>
> [4] bLIP = Bitcoin Lightning Improvement Proposal and SPARK = Standardization 
> of Protocols at the Request of the Kommunity (h/t fiatjaf)
>
> [5] 
> https://github.com/ryanthegentry/lightning-rfc/blob/blip-0001/blips/blip-0001.mediawiki
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


[Lightning-dev] bLIPs: A proposal for community-driven app layer and protocol extension standardization

2021-06-30 Thread Ryan Gentry via Lightning-dev
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 struggled to make
their way into the spec. John Carvalho and Bitrefill launched Turbo
channels in April 2019 [2], Breez posted their solution to the mailing list
for feedback in August 2020 [3], and we know at least ACINQ and Muun
(amongst others) have their own implementations. In an ideal world there
would be a descriptive design document that the app layer implementers had
collaborated on over the years that the spec group could then pick up and
merge into the BOLTs now that the feature is deemed spec-worthy.

Over the last couple of months, we have discussed the idea of adding a
BIP-style process (bLIPs? SPARKs? [4]) on top of the BOLTs with various
members of the community, and have received positive feedback from both app
layer and protocol devs. This would not affect the existing BOLT process at
all, but simply add a place for app layer best practices to be succinctly
described and organized, especially those that require coordination. These
features are being built outside of the BOLT process today anyways, so
ideally a bLIP process would bring them into the fold instead of leaving
them buried in old ML posts or not documented at all.

Some potential bLIP ideas that people have mentioned include: each lnurl
variant, on-the-fly channel opens, AMP, dynamic commitments, podcast
payment metadata, p2p messaging formats, new pathfinding heuristics, remote
node connection standards, etc.

If the community is interested in moving forward, we've started a branch
[5] describing such a process. It's based on BIP-0002, so not trying to
reinvent any wheels. It would be great to have developers from various
implementations and from the broader app layer ecosystem volunteer to be
listed as editors (basically the same role as in the BIPs).

Looking forward to hearing your thoughts!

Best,
Ryan

[1]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-June/003074.html

[2]
https://www.coindesk.com/bitrefills-thor-turbo-lets-you-get-started-with-bitcoins-lightning-faster

[3]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-August/002780.html

[4] bLIP = Bitcoin Lightning Improvement Proposal and SPARK =
Standardization of Protocols at the Request of the Kommunity (h/t fiatjaf)

[5]
https://github.com/ryanthegentry/lightning-rfc/blob/blip-0001/blips/blip-0001.mediawiki
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


Re: [Lightning-dev] bLIPs: A proposal for community-driven app layer and protocol extension standardization

2021-06-30 Thread fiatjaf
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 and open a channel, then define what an HTLC is
and the basic payment flow.

All the rest is optional. The BOLTs themselves encourage
experimentation by having TLVs, rules for optional and experimental
message type numbers and so on.

And then it doesn't make sense to put optional things in the BOLTs
otherwise no one will be spec-compliant anymore and it will cause
confusion.

Some things, like splicing and dual-funded channels could be created
as blips and after everybody had implemented them moved to the BOLTs,
other things, like the podcast tipping protocol, cannot.

Still, it is better to have a spec for the podcast tipping protocol
than to not have, or to have it hidden somewhere. It makes it more
open and easier for everyone.

Ultimately I think dual-funded channels, trampoline routing and other
lower level things should still be kept out of the BOLTs as long as
they are optional. While things like splicing and blinded paths seem
to be more like things that should enforced. This is my opinion, but I
think it's good to have this clear distinction.

Finally, a list of other things that deserve a spec so they are made
standard and interoperable across wallets and services:

1. keysend
2. AMP
3. hosted channels
4. trampoline routing v1
5. trampoline routing v2
6. turbo channels
7. podcast tipping protocol
8. dual-funding
9. on-demand channels
10. sphinx chat messaging thing
11. private routing as done by immortan
12. alternative graph for unannounced channels as done by immortan
13. lnurl-withdraw
14. lnurl-pay
15. lnurl-channel
16. bitcoin-liquid lightning bridge
17. I thought I had more but apparently I forgot

So we have to hunt these people down and make them submit specs.

---
fiatjaf

2021-06-30 16:35 (GMT+02:00), "René Pickhardt via Lightning-dev"
 said:
> 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 roasbeef which I will
> repeat here:
> We already have the equiv of improvement proposals: BOLTs. Historically  new
> standardization documents are proposed initially as issues or PR's when
> ultimately accepted. Why do we need another repo?
> As far as I can tell there was always some form of (invisible?) barrier to
> participate in the BOLTs but there are also new BOLTs being offered:
> * BOLT 12: https://github.com/lightningnetwork/lightning-rfc/pull/798
> * BOLT 14: https://github.com/lightningnetwork/lightning-rfc/pull/780
> and topics to be included like:
> * dual funding
> * splicing
> * the examples given by Ryan
> I don't see how a new repo would reduce that barrier - Actually I think it
> would even create more confusion as I for example would not know where
> something belongs. 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? One thing that I can say from 
> answering
> lightning-network questions on stackexchange is that it would certainly help 
> if
> the BOLTs where referenced on lightning.network web page and in the whitepaper
> as the place to be if one wants to learn about the Lightning Network
> with kind regards Rene
> On Wed, Jun 30, 2021 at 4:10 PM 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 wild vs. originating within the process itself. Zero-conf
> channels are one of many LN innovations on the app layer that have
> struggled to make their way into the spec. John Carvalho and Bitrefill
> launched Turbo channels in April 2019 [2], Breez posted their solution to
> the mailing list for feedback in August 2020 [3], and we know at least
> ACINQ and Muun (amongst others) have their own implementations. In an
> ideal world there would be a descriptive design document that the app
> layer implementers had collaborated on over the years that the spec group
> could then pick up and merge into the BOLTs now that the feature is deemed
> spec-worthy.
>
>
>
>
> Over the last couple of months, we have discussed the idea of adding a
> BIP-style process (bLIPs? SPARKs? [4]) on top of the BOLTs with various
> members of the community, and have received positive feedback from both
> app layer and protocol devs. This would not affect the existing BOLT
> process at 

Re: [Lightning-dev] bLIPs: A proposal for community-driven app layer and protocol extension standardization

2021-06-30 Thread Olaoluwa Osuntokun
> 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 trying to solve here is promoting more
loosely
coupled evolution of the network. I think the BOLTs do a good job currently
of
specifying what _base_ functionality is required for a routing node in a
prescriptive manner (you must forward an HTLC like this, etc). However
there's
a rather large gap in describing functionality that has emerged over time
due
to progressive evolution, and aren't absolutely necessary, but enhance
node/wallet operation.

Examples of  include things like: path finding heuristics (BOLTs just say
you
should get from Alice to Bob, but provides no recommendations w.r.t _how_
to do
so), fee bumping heuristics, breach retribution handling, channel
management,
rebalancing, custom records usage (like the podcast index meta-data,
messaging,
etc), JIT channel opening, hosted channels, randomized channel IDs, fee
optimization, initial channel boostrapping, etc.

All these examples are effectively optional as they aren't required for base
node operation, but they've organically evolved over time as node
implementations and wallet seek to solve UX and operational problems for
their users. bLIPs can be a _descriptive_ (this is how things can be done)
home for these types of standards, while BOLTs can be reserved for
_prescriptive_ measures (an HTLC looks like this, etc).

The protocol as implemented today has a number of extensions (TLVs, message
types, feature bits, etc) that allow implementations to spin out their own
sub-protocols, many of which won't be considered absolutely necessary for
node
operation. IMO we should embrace more of a "bazaar" style of evolution, and
acknowledge that loosely coupled evolution allows participants to more
broadly
explore the design space, without the constraints of "it isn't a thing
until N
of us start to do it".

Historically, BOLTs have also had a rather monolithic structure. We've used
the same 11 or so documents for the past few years with the size of the
documents swelling over time with new exceptions, features, requirements,
etc. If you were hired to work on a new codebase and saw that everything is
defined in 11 "functions" that have been growing linearly over time, you'd
probably declare the codebase as being unmaintainable. By having distinct
documents for proposals/standards, bLIPs (author documents really), each new
standard/proposal is able to be more effectively explained, motivated,
versionsed,
etc.

-- Laolu


On Wed, Jun 30, 2021 at 7:35 AM René Pickhardt via Lightning-dev <
lightning-dev@lists.linuxfoundation.org> wrote:

> 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 roasbeef which I
> will repeat here:
>
> *> We already have the equiv of improvement proposals: BOLTs. Historically*
>
> >* new standardization documents are proposed initially as issues or PR's 
> >when *
>
> >* ultimately accepted. Why do we need another repo? *
>
>
> As far as I can tell there was always some form of (invisible?) barrier to
> participate in the BOLTs but there are also new BOLTs being offered:
> * BOLT 12: https://github.com/lightningnetwork/lightning-rfc/pull/798
> * BOLT 14: https://github.com/lightningnetwork/lightning-rfc/pull/780
> and topics to be included like:
> * dual funding
> * splicing
> * the examples given by Ryan
>
> I don't see how a new repo would reduce that barrier - Actually I think it
> would even create more confusion as I for example would not know where
> something belongs. 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? One thing that I
> can say from answering lightning-network questions on stackexchange is that
> it would certainly help if the BOLTs where referenced  on lightning.network
> web page and in the whitepaper as the place to be if one wants to learn
> about the Lightning Network
>
> with kind regards Rene
>
> On Wed, Jun 30, 2021 at 4:10 PM Ryan Gentry via Lightning-dev <
> lightning-dev@lists.linuxfoundation.org> 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 wild vs. originating within the process itself. Zero-conf
>> channels are one of many LN innovations on the app layer that have
>> struggled to make their way into the