📅 Original date posted:2021-07-02
📝 Original message:
> 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 avoid us having to wait for things. I just think "bLIPs"
adds confusion e.g. should something be a bLIP or a BOLT? Does a bLIP
eventually become a BOLT when it is mature enough? This tendency to
fragment and introduce new acronyms and new processes should be
resisted imo. If a new process is introduced every time there is a
disagreement or perceived friction it just erodes the value of
existing processes and means they all get bypassed. Strengthen and
improve existing processes and only introduce a new one as an absolute
last resort.
Other than the minor frictions described above I don't see why "bLIPs"
can't just be draft BOLTs.
> 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.
On Fri, Jul 2, 2021 at 9:01 AM Bastien TEINTURIER <bastien at acinq.fr> wrote:
>>
>> 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 using.
>
>
> It's only my 2 cents, but I'm afraid it will indeed add more fragmentation, because
> the fact that there exists a bLIP for feature XXX will likely act as a green light to
> deploy it faster instead of spending more time talking about it with the community
> and thinking about potential issues, forward-compatibility, etc.
>
> But I agree with you that it also gives more freedom to experiment in the real world,
> which helps find issues and correct them, paving the way for better features for
> end users.
>
>> It's also likely the case that already implementations, or typically forks
>> of implementations are already using "undocumented" TLVs or feature bits in
>> the wild today.
>
>
> But today we're usually very careful when we do that, and use numbers in high ranges
> for these use-cases. In our case for example we use message type 35007 for our
> swap-in and we expect that to change once standardized, so we did extra work to
> ensure we wouldn't paint ourselves into a corner when switching to a standard version.
>
> I think that if we have a centralized bLIP repo, we can take this opportunity to safely
> assign "final" values for types and feature bits that are used by each bLIP, and stronger
> guarantees that they will not conflict with another bLIP or BOLT. Of course that doesn't
> stop anyone from deploying a conflict, but their use of the same bits won't be documented
> so it shouldn't be widely deployed, and browsing the BOLTs and bLIPs should let anyone
> see what the "correct" meaning of those bits should be.
>
> Cheers,
> Bastien
>
>
> Le jeu. 1 juil. 2021 à 22:43, Olaoluwa Osuntokun <laolu32 at gmail.com> a écrit :
>>
>> > 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 a fair characterization that I agree with. I also agree that
>> there isn't really a way to fundamentally address it. The issue of scarce
>> review resources is something just about any large open source project needs
>> to deal with: everyone wants to make a PR, but no one wants to review the
>> PRs of others, unless it scratches some tangential itch they may have. IMO
>> it's also the case that the problem/solution space of LN is so large, that
>> it's hard to expect every developer to review each new proposal that comes
>> in, as they themselves have their own set of priorities (product,
>> businesses, protocol, personal, etc).
>>
>> In the end though, I think when there've been critical items that affect all
>> implementations and/or the existence of the protocol itself, developers
>> typically band together to commit resources to help a proposal move forward.
>> One upcoming example of this will be the "base" taproot channel type (the
>> design space is pretty large in that it even permits a new type of symmetric
>> state revocation-based channel).
>>
>> > it will add fragmentation to the network, it will add maintenance costs
>> > and backwards-compatibility issues
>>
>> 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 using. As usual, it's
>> up to other implementations if they want to adopt it or not, or advise
>> against its use.
>>
>> > many bLIPs will be sub-optimal solutions to the problem they try to solve
>> > and some bLIPs will be simply insecure and may put users' funds at risk
>> > (L2 protocols are hard and have subtle issues that can be easily missed)
>>
>> This may be the case, but I guess at times it's hard to know if something is
>> objectively sub-optimal without further exploration of the design space,
>> which usually means either more people involved, or more time examining the
>> problem. Ultimately, different wallets/implementations may also be willing
>> to make different usability/security trade-offs. One example here is zero
>> conf channels: they assume a greater degree of trust with the party you're
>> _accepting_ the channel from, as if you receive funds over the channel, they
>> can be double spent away. However it's undeniable that they improve the UX
>> by reducing the amount of time a user needs to wait around before they can
>> actually jump in and use LN.
>>
>> In the end though, there's no grand global committee that prevents people
>> from deploying software they think is interesting or useful. In the long
>> run, I guess one simply needs to hope that bad ideas die out, or speak out
>> against them to the public. As LN sits a layer above the base protocol,
>> widespread global consensus isn't really required to make certain classes of
>> changes, and you can't stop people from experimenting on their own.
>>
>> > We can't have collisions on any of these three things.
>>
>> Yeah, collisions are def possible. IMO, this is where the interplay with
>> BOLTs comes in: BOLTs are the global feature bit/tlv/message namespace. A
>> bLIP might come with the amendment of BOLT 9 to define feature bits they
>> used. Of course, this should be done on a best effort basis, as even if you
>> assign a bit for your idea, someone can just go ahead and deploy something
>> else w/ that same bit, and they may never really intersect depending on the
>> nature or how widespread the new feature is.
>>
>> It's also likely the case that already implementations, or typically forks
>> of implementations are already using "undocumented" TLVs or feature bits in
>> the wild today. I don't know exactly which TLV type things like applications
>> that tunnel messages over the network use, but afaik so far there haven't
>> been any disastrous collisions in the wild.
>>
>> -- Laolu
>>
>> On Thu, Jul 1, 2021 at 2:19 AM Bastien TEINTURIER <bastien at acinq.fr> wrote:
>>>
>>> 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 useful and they can't get it into the BOLTs (the spec PR isn't reviewed,
>>> it progresses too slowly or there isn't enough agreement to merge it)
>>> - Implementers expect other implementers to specify the optional features they
>>> ship: we don't want to have to reverse-engineer a sub-protocol when users
>>> want our implementation to provide support for feature XXX
>>>
>>> Note that these are two very different concerns.
>>>
>>> bLIPs/SPARKS/BIPs clearly address the second point, which is good.
>>> 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 am mostly in favor of this solution, but I want to highlight that it isn't
>>> only rainbows and unicorns: it will add fragmentation to the network, it will
>>> add maintenance costs and backwards-compatibility issues, many bLIPs will be
>>> sub-optimal solutions to the problem they try to solve and some bLIPs will be
>>> simply insecure and may put users' funds at risk (L2 protocols are hard and have
>>> subtle issues that can be easily missed). On the other hand, it allows for real
>>> world experimentation and iteration, and it's easier to amend a bLIP than the
>>> BOLTs.
>>>
>>> On the nuts-and-bolts (see the pun?) side, bLIPs cannot embrace a fully bazaar
>>> style of evolution. Most of them will need:
>>>
>>> - to assign feature bit(s)
>>> - to insert new tlv fields in existing messages
>>> - to create new messages
>>>
>>> We can't have collisions on any of these three things. bLIP XXX cannot use the
>>> same tlv types as bLIP YYY otherwise we're creating network incompatibilities.
>>> So they really need to be centralized, and we need a process to assign these
>>> and ensure they don't collide. It's not a hard problem, but we need to be clear
>>> about the process around those.
>>>
>>> Regarding the details of where they live, I don't have a strong opinion, but I
>>> think they must be easy to find and browse, and I think it's easier for readers
>>> if they're inside the spec repository. We already have PRs that use a dedicated
>>> "proposals" folder (e.g. [1], [2]).
>>>
>>> Cheers,
>>> Bastien
>>>
>>> [1] https://github.com/lightningnetwork/lightning-rfc/pull/829
>>> [2] https://github.com/lightningnetwork/lightning-rfc/pull/854
>>>
>>> Le jeu. 1 juil. 2021 à 02:31, Ariel Luaces <arielluaces at gmail.com> a écrit :
>>>>
>>>> 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 <laolu32 at gmail.com> 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 <lightning-dev at 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 at 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 at lists.linuxfoundation.org
>>>> >>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>> >>
>>>> >>
>>>> >>
>>>> >> --
>>>> >> https://www.rene-pickhardt.de
>>>> >> _______________________________________________
>>>> >> 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
>>>> _______________________________________________
>>>> 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
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
--
Michael Folkson
Email: michaelfolkson at gmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
Michael Folkson [ARCHIVE] /
npub103…2kpam
2023-06-09 12:40:27
in reply to nevent1q…dgqx
Author Public Key
npub103ycruxnchhvja33mcnnkfdkgd0s7vlqlfkvufcdm5lnhpuh6f4q82kpamPublished at
2023-06-09 12:40:27Event JSON
{
"id": "9485c2d3661e878ef2b6499a3305b010788f51b10937f8fb7c0c42006a5a19c1",
"pubkey": "7c4981f0d3c5eec97631de273b25b6435f0f33e0fa6cce270ddd3f3b8797d26a",
"created_at": 1686314427,
"kind": 1,
"tags": [
[
"e",
"7978884316d2a2eea3e40b9cc9bbbd31e26017308c2be1dc1637e23b621c5a03",
"",
"root"
],
[
"e",
"74d256283b2ac6235cdd64de114eed467cff947bcbfca7ae1d6cbd83de8c2c4e",
"",
"reply"
],
[
"p",
"f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb"
]
],
"content": "📅 Original date posted:2021-07-02\n📝 Original message:\n\u003e 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\".\n\nSo TL;DR BIPs and BOLTs sometimes require waiting for things (like\nreview and consensus) and there should be a new acronym and process\n(\"bLIPs\") to avoid us having to wait for things. I just think \"bLIPs\"\nadds confusion e.g. should something be a bLIP or a BOLT? Does a bLIP\neventually become a BOLT when it is mature enough? This tendency to\nfragment and introduce new acronyms and new processes should be\nresisted imo. If a new process is introduced every time there is a\ndisagreement or perceived friction it just erodes the value of\nexisting processes and means they all get bypassed. Strengthen and\nimprove existing processes and only introduce a new one as an absolute\nlast resort.\n\nOther than the minor frictions described above I don't see why \"bLIPs\"\ncan't just be draft BOLTs.\n\n\u003e Adding a third BIP editor more involved with Lightning sounds like a good idea.\n\nOr alternatively if BOLTs were subsumed into BIPs I think Bastien\nwould be a great additional BIP editor to cover Lightning related BIPs\n:) I think BOLTs being subsumed into BIPs would be nice but I'm\npessimistic it will happen. Like legislation and regulation in the\nlegacy financial system alphabet soups only expand they never get\nsimplified. Let's at least resist alphabet soup expansion here.\n\nOn Fri, Jul 2, 2021 at 9:01 AM Bastien TEINTURIER \u003cbastien at acinq.fr\u003e wrote:\n\u003e\u003e\n\u003e\u003e Will it actually add any more fragmentation that already exists? Due to all\n\u003e\u003e the extensibility we've added in the protocol, it's already possible for any\n\u003e\u003e implementation to start to work on their own sub-protocols. This just gives\n\u003e\u003e them a new venue to at least _describe_ what they're using.\n\u003e\n\u003e\n\u003e It's only my 2 cents, but I'm afraid it will indeed add more fragmentation, because\n\u003e the fact that there exists a bLIP for feature XXX will likely act as a green light to\n\u003e deploy it faster instead of spending more time talking about it with the community\n\u003e and thinking about potential issues, forward-compatibility, etc.\n\u003e\n\u003e But I agree with you that it also gives more freedom to experiment in the real world,\n\u003e which helps find issues and correct them, paving the way for better features for\n\u003e end users.\n\u003e\n\u003e\u003e It's also likely the case that already implementations, or typically forks\n\u003e\u003e of implementations are already using \"undocumented\" TLVs or feature bits in\n\u003e\u003e the wild today.\n\u003e\n\u003e\n\u003e But today we're usually very careful when we do that, and use numbers in high ranges\n\u003e for these use-cases. In our case for example we use message type 35007 for our\n\u003e swap-in and we expect that to change once standardized, so we did extra work to\n\u003e ensure we wouldn't paint ourselves into a corner when switching to a standard version.\n\u003e\n\u003e I think that if we have a centralized bLIP repo, we can take this opportunity to safely\n\u003e assign \"final\" values for types and feature bits that are used by each bLIP, and stronger\n\u003e guarantees that they will not conflict with another bLIP or BOLT. Of course that doesn't\n\u003e stop anyone from deploying a conflict, but their use of the same bits won't be documented\n\u003e so it shouldn't be widely deployed, and browsing the BOLTs and bLIPs should let anyone\n\u003e see what the \"correct\" meaning of those bits should be.\n\u003e\n\u003e Cheers,\n\u003e Bastien\n\u003e\n\u003e\n\u003e Le jeu. 1 juil. 2021 à 22:43, Olaoluwa Osuntokun \u003claolu32 at gmail.com\u003e a écrit :\n\u003e\u003e\n\u003e\u003e \u003e But they don't address the first point at all, they instead work around\n\u003e\u003e \u003e it. To be fair, I don't think we can completely address that first point:\n\u003e\u003e \u003e properly reviewing spec proposals takes a lot of effort and accepting\n\u003e\u003e \u003e complex changes to the BOLTs shouldn't be done lightly.\n\u003e\u003e\n\u003e\u003e I think this is a fair characterization that I agree with. I also agree that\n\u003e\u003e there isn't really a way to fundamentally address it. The issue of scarce\n\u003e\u003e review resources is something just about any large open source project needs\n\u003e\u003e to deal with: everyone wants to make a PR, but no one wants to review the\n\u003e\u003e PRs of others, unless it scratches some tangential itch they may have. IMO\n\u003e\u003e it's also the case that the problem/solution space of LN is so large, that\n\u003e\u003e it's hard to expect every developer to review each new proposal that comes\n\u003e\u003e in, as they themselves have their own set of priorities (product,\n\u003e\u003e businesses, protocol, personal, etc).\n\u003e\u003e\n\u003e\u003e In the end though, I think when there've been critical items that affect all\n\u003e\u003e implementations and/or the existence of the protocol itself, developers\n\u003e\u003e typically band together to commit resources to help a proposal move forward.\n\u003e\u003e One upcoming example of this will be the \"base\" taproot channel type (the\n\u003e\u003e design space is pretty large in that it even permits a new type of symmetric\n\u003e\u003e state revocation-based channel).\n\u003e\u003e\n\u003e\u003e \u003e it will add fragmentation to the network, it will add maintenance costs\n\u003e\u003e \u003e and backwards-compatibility issues\n\u003e\u003e\n\u003e\u003e Will it actually add any more fragmentation that already exists? Due to all\n\u003e\u003e the extensibility we've added in the protocol, it's already possible for any\n\u003e\u003e implementation to start to work on their own sub-protocols. This just gives\n\u003e\u003e them a new venue to at least _describe_ what they're using. As usual, it's\n\u003e\u003e up to other implementations if they want to adopt it or not, or advise\n\u003e\u003e against its use.\n\u003e\u003e\n\u003e\u003e \u003e many bLIPs will be sub-optimal solutions to the problem they try to solve\n\u003e\u003e \u003e and some bLIPs will be simply insecure and may put users' funds at risk\n\u003e\u003e \u003e (L2 protocols are hard and have subtle issues that can be easily missed)\n\u003e\u003e\n\u003e\u003e This may be the case, but I guess at times it's hard to know if something is\n\u003e\u003e objectively sub-optimal without further exploration of the design space,\n\u003e\u003e which usually means either more people involved, or more time examining the\n\u003e\u003e problem. Ultimately, different wallets/implementations may also be willing\n\u003e\u003e to make different usability/security trade-offs. One example here is zero\n\u003e\u003e conf channels: they assume a greater degree of trust with the party you're\n\u003e\u003e _accepting_ the channel from, as if you receive funds over the channel, they\n\u003e\u003e can be double spent away. However it's undeniable that they improve the UX\n\u003e\u003e by reducing the amount of time a user needs to wait around before they can\n\u003e\u003e actually jump in and use LN.\n\u003e\u003e\n\u003e\u003e In the end though, there's no grand global committee that prevents people\n\u003e\u003e from deploying software they think is interesting or useful. In the long\n\u003e\u003e run, I guess one simply needs to hope that bad ideas die out, or speak out\n\u003e\u003e against them to the public. As LN sits a layer above the base protocol,\n\u003e\u003e widespread global consensus isn't really required to make certain classes of\n\u003e\u003e changes, and you can't stop people from experimenting on their own.\n\u003e\u003e\n\u003e\u003e \u003e We can't have collisions on any of these three things.\n\u003e\u003e\n\u003e\u003e Yeah, collisions are def possible. IMO, this is where the interplay with\n\u003e\u003e BOLTs comes in: BOLTs are the global feature bit/tlv/message namespace. A\n\u003e\u003e bLIP might come with the amendment of BOLT 9 to define feature bits they\n\u003e\u003e used. Of course, this should be done on a best effort basis, as even if you\n\u003e\u003e assign a bit for your idea, someone can just go ahead and deploy something\n\u003e\u003e else w/ that same bit, and they may never really intersect depending on the\n\u003e\u003e nature or how widespread the new feature is.\n\u003e\u003e\n\u003e\u003e It's also likely the case that already implementations, or typically forks\n\u003e\u003e of implementations are already using \"undocumented\" TLVs or feature bits in\n\u003e\u003e the wild today. I don't know exactly which TLV type things like applications\n\u003e\u003e that tunnel messages over the network use, but afaik so far there haven't\n\u003e\u003e been any disastrous collisions in the wild.\n\u003e\u003e\n\u003e\u003e -- Laolu\n\u003e\u003e\n\u003e\u003e On Thu, Jul 1, 2021 at 2:19 AM Bastien TEINTURIER \u003cbastien at acinq.fr\u003e wrote:\n\u003e\u003e\u003e\n\u003e\u003e\u003e Thanks for starting that discussion.\n\u003e\u003e\u003e\n\u003e\u003e\u003e In my opinion, what we're really trying to address here are the two following\n\u003e\u003e\u003e points (at least from the point of view of someone who works on the spec and\n\u003e\u003e\u003e an implementation):\n\u003e\u003e\u003e\n\u003e\u003e\u003e - Implementers get frustrated when they've worked on something that they think\n\u003e\u003e\u003e is useful and they can't get it into the BOLTs (the spec PR isn't reviewed,\n\u003e\u003e\u003e it progresses too slowly or there isn't enough agreement to merge it)\n\u003e\u003e\u003e - Implementers expect other implementers to specify the optional features they\n\u003e\u003e\u003e ship: we don't want to have to reverse-engineer a sub-protocol when users\n\u003e\u003e\u003e want our implementation to provide support for feature XXX\n\u003e\u003e\u003e\n\u003e\u003e\u003e Note that these are two very different concerns.\n\u003e\u003e\u003e\n\u003e\u003e\u003e bLIPs/SPARKS/BIPs clearly address the second point, which is good.\n\u003e\u003e\u003e But they don't address the first point at all, they instead work around it.\n\u003e\u003e\u003e To be fair, I don't think we can completely address that first point: properly\n\u003e\u003e\u003e reviewing spec proposals takes a lot of effort and accepting complex changes\n\u003e\u003e\u003e to the BOLTs shouldn't be done lightly.\n\u003e\u003e\u003e\n\u003e\u003e\u003e I am mostly in favor of this solution, but I want to highlight that it isn't\n\u003e\u003e\u003e only rainbows and unicorns: it will add fragmentation to the network, it will\n\u003e\u003e\u003e add maintenance costs and backwards-compatibility issues, many bLIPs will be\n\u003e\u003e\u003e sub-optimal solutions to the problem they try to solve and some bLIPs will be\n\u003e\u003e\u003e simply insecure and may put users' funds at risk (L2 protocols are hard and have\n\u003e\u003e\u003e subtle issues that can be easily missed). On the other hand, it allows for real\n\u003e\u003e\u003e world experimentation and iteration, and it's easier to amend a bLIP than the\n\u003e\u003e\u003e BOLTs.\n\u003e\u003e\u003e\n\u003e\u003e\u003e On the nuts-and-bolts (see the pun?) side, bLIPs cannot embrace a fully bazaar\n\u003e\u003e\u003e style of evolution. Most of them will need:\n\u003e\u003e\u003e\n\u003e\u003e\u003e - to assign feature bit(s)\n\u003e\u003e\u003e - to insert new tlv fields in existing messages\n\u003e\u003e\u003e - to create new messages\n\u003e\u003e\u003e\n\u003e\u003e\u003e We can't have collisions on any of these three things. bLIP XXX cannot use the\n\u003e\u003e\u003e same tlv types as bLIP YYY otherwise we're creating network incompatibilities.\n\u003e\u003e\u003e So they really need to be centralized, and we need a process to assign these\n\u003e\u003e\u003e and ensure they don't collide. It's not a hard problem, but we need to be clear\n\u003e\u003e\u003e about the process around those.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Regarding the details of where they live, I don't have a strong opinion, but I\n\u003e\u003e\u003e think they must be easy to find and browse, and I think it's easier for readers\n\u003e\u003e\u003e if they're inside the spec repository. We already have PRs that use a dedicated\n\u003e\u003e\u003e \"proposals\" folder (e.g. [1], [2]).\n\u003e\u003e\u003e\n\u003e\u003e\u003e Cheers,\n\u003e\u003e\u003e Bastien\n\u003e\u003e\u003e\n\u003e\u003e\u003e [1] https://github.com/lightningnetwork/lightning-rfc/pull/829\n\u003e\u003e\u003e [2] https://github.com/lightningnetwork/lightning-rfc/pull/854\n\u003e\u003e\u003e\n\u003e\u003e\u003e Le jeu. 1 juil. 2021 à 02:31, Ariel Luaces \u003carielluaces at gmail.com\u003e a écrit :\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e BIPs are already the Bazaar style of evolution that simultaneously\n\u003e\u003e\u003e\u003e allows flexibility and coordination/interoperability (since anyone can\n\u003e\u003e\u003e\u003e create a BIP and they create an environment of discussion).\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e BOLTs are essentially one big BIP in the sense that they started as a\n\u003e\u003e\u003e\u003e place for discussion but are now more rigid. BOLTs must be followed\n\u003e\u003e\u003e\u003e strictly to ensure a node is interoperable with the network. And BOLTs\n\u003e\u003e\u003e\u003e should be rigid, as rigid as any widely used BIP like 32 for example.\n\u003e\u003e\u003e\u003e Even though BOLTs were flexible when being drafted their purpose has\n\u003e\u003e\u003e\u003e changed from descriptive to prescriptive.\n\u003e\u003e\u003e\u003e Any alternatives, or optional features should be extracted out of\n\u003e\u003e\u003e\u003e BOLTs, written as BIPs. The BIP should then reference the BOLT and the\n\u003e\u003e\u003e\u003e required flags set, messages sent, or alterations made to signal that\n\u003e\u003e\u003e\u003e the BIP's feature is enabled.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e A BOLT may at some point organically change to reference a BIP. For\n\u003e\u003e\u003e\u003e example if a BIP was drafted as an optional feature but then becomes\n\u003e\u003e\u003e\u003e more widespread and then turns out to be crucial for the proper\n\u003e\u003e\u003e\u003e operation of the network then a BOLT can be changed to just reference\n\u003e\u003e\u003e\u003e the BIP as mandatory. There isn't anything wrong with this.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e All of the above would work exactly the same if there was a bLIP\n\u003e\u003e\u003e\u003e repository instead. I don't see the value in having both bLIPs and\n\u003e\u003e\u003e\u003e BIPs since AFAICT they seem to be functionally equivalent and BIPs are\n\u003e\u003e\u003e\u003e not restricted to exclude lightning, and never have been.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e I believe the reason this move to BIPs hasn't happened organically is\n\u003e\u003e\u003e\u003e because many still perceive the BOLTs available for editing, so\n\u003e\u003e\u003e\u003e changes continue to be made. If instead BOLTs were perceived as more\n\u003e\u003e\u003e\u003e \"consensus critical\", not subject to change, and more people were\n\u003e\u003e\u003e\u003e strongly encouraged to write specs for new lightning features\n\u003e\u003e\u003e\u003e elsewhere (like the BIP repo) then you would see this issue of growing\n\u003e\u003e\u003e\u003e BOLTs resolved.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e Cheers\n\u003e\u003e\u003e\u003e Ariel Lorenzo-Luaces\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e On Wed, Jun 30, 2021 at 1:16 PM Olaoluwa Osuntokun \u003claolu32 at gmail.com\u003e wrote:\n\u003e\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e\u003e \u003e \u003e That being said I think all the points that are addressed in Ryan's mail\n\u003e\u003e\u003e\u003e \u003e \u003e could very well be formalized into BOLTs but maybe we just need to rethink\n\u003e\u003e\u003e\u003e \u003e \u003e the current process of the BOLTs to make it more accessible for new ideas\n\u003e\u003e\u003e\u003e \u003e \u003e to find their way into the BOLTs?\n\u003e\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e\u003e \u003e I think part of what bLIPs are trying to solve here is promoting more loosely\n\u003e\u003e\u003e\u003e \u003e coupled evolution of the network. I think the BOLTs do a good job currently of\n\u003e\u003e\u003e\u003e \u003e specifying what _base_ functionality is required for a routing node in a\n\u003e\u003e\u003e\u003e \u003e prescriptive manner (you must forward an HTLC like this, etc). However there's\n\u003e\u003e\u003e\u003e \u003e a rather large gap in describing functionality that has emerged over time due\n\u003e\u003e\u003e\u003e \u003e to progressive evolution, and aren't absolutely necessary, but enhance\n\u003e\u003e\u003e\u003e \u003e node/wallet operation.\n\u003e\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e\u003e \u003e Examples of include things like: path finding heuristics (BOLTs just say you\n\u003e\u003e\u003e\u003e \u003e should get from Alice to Bob, but provides no recommendations w.r.t _how_ to do\n\u003e\u003e\u003e\u003e \u003e so), fee bumping heuristics, breach retribution handling, channel management,\n\u003e\u003e\u003e\u003e \u003e rebalancing, custom records usage (like the podcast index meta-data, messaging,\n\u003e\u003e\u003e\u003e \u003e etc), JIT channel opening, hosted channels, randomized channel IDs, fee\n\u003e\u003e\u003e\u003e \u003e optimization, initial channel boostrapping, etc.\n\u003e\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e\u003e \u003e All these examples are effectively optional as they aren't required for base\n\u003e\u003e\u003e\u003e \u003e node operation, but they've organically evolved over time as node\n\u003e\u003e\u003e\u003e \u003e implementations and wallet seek to solve UX and operational problems for\n\u003e\u003e\u003e\u003e \u003e their users. bLIPs can be a _descriptive_ (this is how things can be done)\n\u003e\u003e\u003e\u003e \u003e home for these types of standards, while BOLTs can be reserved for\n\u003e\u003e\u003e\u003e \u003e _prescriptive_ measures (an HTLC looks like this, etc).\n\u003e\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e\u003e \u003e The protocol as implemented today has a number of extensions (TLVs, message\n\u003e\u003e\u003e\u003e \u003e types, feature bits, etc) that allow implementations to spin out their own\n\u003e\u003e\u003e\u003e \u003e sub-protocols, many of which won't be considered absolutely necessary for node\n\u003e\u003e\u003e\u003e \u003e operation. IMO we should embrace more of a \"bazaar\" style of evolution, and\n\u003e\u003e\u003e\u003e \u003e acknowledge that loosely coupled evolution allows participants to more broadly\n\u003e\u003e\u003e\u003e \u003e explore the design space, without the constraints of \"it isn't a thing until N\n\u003e\u003e\u003e\u003e \u003e of us start to do it\".\n\u003e\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e\u003e \u003e Historically, BOLTs have also had a rather monolithic structure. We've used\n\u003e\u003e\u003e\u003e \u003e the same 11 or so documents for the past few years with the size of the\n\u003e\u003e\u003e\u003e \u003e documents swelling over time with new exceptions, features, requirements,\n\u003e\u003e\u003e\u003e \u003e etc. If you were hired to work on a new codebase and saw that everything is\n\u003e\u003e\u003e\u003e \u003e defined in 11 \"functions\" that have been growing linearly over time, you'd\n\u003e\u003e\u003e\u003e \u003e probably declare the codebase as being unmaintainable. By having distinct\n\u003e\u003e\u003e\u003e \u003e documents for proposals/standards, bLIPs (author documents really), each new\n\u003e\u003e\u003e\u003e \u003e standard/proposal is able to be more effectively explained, motivated, versionsed,\n\u003e\u003e\u003e\u003e \u003e etc.\n\u003e\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e\u003e \u003e -- Laolu\n\u003e\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e\u003e \u003e On Wed, Jun 30, 2021 at 7:35 AM René Pickhardt via Lightning-dev \u003clightning-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e\u003e \u003e\u003e\n\u003e\u003e\u003e\u003e \u003e\u003e Hey everyone,\n\u003e\u003e\u003e\u003e \u003e\u003e\n\u003e\u003e\u003e\u003e \u003e\u003e 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\n\u003e\u003e\u003e\u003e \u003e\u003e\n\u003e\u003e\u003e\u003e \u003e\u003e I wonder what exactly has changed in the reasoning by roasbeef which I will repeat here:\n\u003e\u003e\u003e\u003e \u003e\u003e\n\u003e\u003e\u003e\u003e \u003e\u003e \u003e We already have the equiv of improvement proposals: BOLTs. Historically\n\u003e\u003e\u003e\u003e \u003e\u003e\n\u003e\u003e\u003e\u003e \u003e\u003e \u003e new standardization documents are proposed initially as issues or PR's when\n\u003e\u003e\u003e\u003e \u003e\u003e\n\u003e\u003e\u003e\u003e \u003e\u003e \u003e ultimately accepted. Why do we need another repo?\n\u003e\u003e\u003e\u003e \u003e\u003e\n\u003e\u003e\u003e\u003e \u003e\u003e\n\u003e\u003e\u003e\u003e \u003e\u003e 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:\n\u003e\u003e\u003e\u003e \u003e\u003e * BOLT 12: https://github.com/lightningnetwork/lightning-rfc/pull/798\n\u003e\u003e\u003e\u003e \u003e\u003e * BOLT 14: https://github.com/lightningnetwork/lightning-rfc/pull/780\n\u003e\u003e\u003e\u003e \u003e\u003e and topics to be included like:\n\u003e\u003e\u003e\u003e \u003e\u003e * dual funding\n\u003e\u003e\u003e\u003e \u003e\u003e * splicing\n\u003e\u003e\u003e\u003e \u003e\u003e * the examples given by Ryan\n\u003e\u003e\u003e\u003e \u003e\u003e\n\u003e\u003e\u003e\u003e \u003e\u003e 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\n\u003e\u003e\u003e\u003e \u003e\u003e\n\u003e\u003e\u003e\u003e \u003e\u003e with kind regards Rene\n\u003e\u003e\u003e\u003e \u003e\u003e\n\u003e\u003e\u003e\u003e \u003e\u003e On Wed, Jun 30, 2021 at 4:10 PM Ryan Gentry via Lightning-dev \u003clightning-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e\u003e \u003e\u003e\u003e Hi all,\n\u003e\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e\u003e \u003e\u003e\u003e 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.\n\u003e\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e\u003e \u003e\u003e\u003e 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.\n\u003e\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e\u003e \u003e\u003e\u003e 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.\n\u003e\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e\u003e \u003e\u003e\u003e 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).\n\u003e\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e\u003e \u003e\u003e\u003e Looking forward to hearing your thoughts!\n\u003e\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e\u003e \u003e\u003e\u003e Best,\n\u003e\u003e\u003e\u003e \u003e\u003e\u003e Ryan\n\u003e\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e\u003e \u003e\u003e\u003e [1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-June/003074.html\n\u003e\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e\u003e \u003e\u003e\u003e [2] https://www.coindesk.com/bitrefills-thor-turbo-lets-you-get-started-with-bitcoins-lightning-faster\n\u003e\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e\u003e \u003e\u003e\u003e [3] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-August/002780.html\n\u003e\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e\u003e \u003e\u003e\u003e [4] bLIP = Bitcoin Lightning Improvement Proposal and SPARK = Standardization of Protocols at the Request of the Kommunity (h/t fiatjaf)\n\u003e\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e\u003e \u003e\u003e\u003e [5] https://github.com/ryanthegentry/lightning-rfc/blob/blip-0001/blips/blip-0001.mediawiki\n\u003e\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e\u003e \u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e\u003e \u003e\u003e\u003e Lightning-dev mailing list\n\u003e\u003e\u003e\u003e \u003e\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e\u003e \u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\u003e\u003e\u003e \u003e\u003e\n\u003e\u003e\u003e\u003e \u003e\u003e\n\u003e\u003e\u003e\u003e \u003e\u003e\n\u003e\u003e\u003e\u003e \u003e\u003e --\n\u003e\u003e\u003e\u003e \u003e\u003e https://www.rene-pickhardt.de\n\u003e\u003e\u003e\u003e \u003e\u003e _______________________________________________\n\u003e\u003e\u003e\u003e \u003e\u003e Lightning-dev mailing list\n\u003e\u003e\u003e\u003e \u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e\u003e \u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e\u003e \u003e _______________________________________________\n\u003e\u003e\u003e\u003e \u003e Lightning-dev mailing list\n\u003e\u003e\u003e\u003e \u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e\u003e Lightning-dev mailing list\n\u003e\u003e\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\u003e\u003e\n\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e Lightning-dev mailing list\n\u003e\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\n\n\n-- \nMichael Folkson\nEmail: michaelfolkson at gmail.com\nKeybase: michaelfolkson\nPGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3",
"sig": "dc9bcd73d1bcaf20c569d1f838b60009270dc9fb4a4166a5e132f5a61e074978c793bd73ac0ab9b6537efb3fb589ee4a4934b2cd77d6fa7be7296634265de063"
}