process: bLIP 0001 #884
process: bLIP 0001 #884
Conversation
|
I think a first step could be to have message type/feature bits/TLV types pinned in BOLT annexes with a formalized process to solve collisions in case of 2 applications experimenting with the same bit and both pretending to anteriority of art. And then call for applications/protocols already consuming ones to declare them. IIRC we're using some on the dlcspecs side without having announced them in #716 or #605 Do we have other LN namespaces beyond those ones ? |
|
That's a nice idea @ariard (though I did need to Google "anteriority" 🤓 ). Combining your feedback with @TheBlueMatt's, I'm leaning towards narrowing the scope of this doc by:
In lieu of such an annex being pinned directly within the BOLTs, maybe this doc could point to the Waiting Room issues you linked to? Is there such a Waiting Room issue for TLV assignments as well? Can't find one if so... maybe they should be bLIPs? |
There was a problem hiding this comment.
I think this introductory bLIP should detail how we deal with conflicts on scarce resources:
- feature bits used by a bLIP
- new tlv fields added by a bLIP to BOLT p2p messages
- new p2p messages introduced by a bLIP
We basically just need a big centralized list for these to avoid clashes (and we need BOLT maintainers to verify there is no clash with official BOLT values).
It could either be right here inside bLIP-0001, or we could have a bLIP dedicated to that (e.g. bLIP-0002), or this could be in the BOLTs (in bolt 9 or in a new one).
In lieu of such an annex being pinned directly within the BOLTs, maybe this doc could point to the Waiting Room issues you linked to? Is there such a Waiting Room issue for TLV assignments as well? Can't find one if so... maybe they should be bLIPs?
I think this shouldn't be in an issue, but rather in a file in this repository, to make it trivial to search for it and verify that there are no clashes.
…re Bit/Message Type/TLV to Rationale, added Status diagram.
…re Bit/Message Type/TLV to Rationale, added Status diagram.
|
Thanks all for the notes above. Apologies for not getting around to this until Friday, but just pushed an updated bLIP-0001 with the following changes:
Looking forward to discussing in #893! |
There was a problem hiding this comment.
As I express the opinion on the mailing list, I think it would be better to have the blip process in its own github org/repository and that way minimize the public perception that a given blips is "blessed" by Lightning developers. It would avoid also frustration when blips aren't merged because BOLT editors are running after time, or whatever reason!
Though overall I'm supportive of this new specification process and agree with the rational :)
|
Why don't you add a reference to this on |
Would be yet another repo to bootstrap, and manage permissions/privileges, etc for, also yet another repo to need to monitor for PRs. The whole point of bLIPs is that there isn't any perception of something needing to be blessed by the developers: developers simply write up their schemes for documentation for them to live under a single home. |
BOLT 9 seems like the ideal location for this? Each bLIP would modify the BOLT and conflicts would arise naturally in git where they'd need to be addressed before merging. |
I'm not sure, as the bulk of it would not be feature bits but rather tlv fields, new messages, etc. |
And that means if you're only interested by the BOLT/"universal Lightning implementation" stuff, now you have to sort through the bLIPs issues ? And if you do expect this effort specification to be successful that will be a lot of issues. W.r.t to the blessing perception, if we do at least a janitorial work of monitoring that no basic crap is committed to the repo, in a really minimal way we're blessing them :/
I think it should be a new BOLT, as ultimately the "scarce resources" management should be done by the BOLT process and not the bLIPs one ? Like you have specification effort interested to rely on the BOLT namespaces (e.g dlcspecs). |
That would work as well for me, as long as it's a separate, new document that lives inside the BOLT repo and is easy to check against the rest of the BOLTs! |
|
I don't feel strongly one way or another on these, let's do some pros and cons:
Anything I'm missing or am assessing incorrectly? After writing this out, I am leaning towards bLIPs in the lightning-rfc repo + resource assignments in a new BOLT (pending answers re: BOLT 9 confusion). Seems like minimal overhead with good direction on what's mandatory vs. what's optional. |
I would add:
It's easy: bLIPs never edit BOLT 9, they only edit the new BOLT. BOLT 9 stays for official BOLT features only, which is cleaner. My preference currently goes to:
It's not a strong preference for the first point, I don't mind that much if blips stay inside the BOLT repo (we can always migrate them outside later if it proves to be an issue). I do feel strongly about the second point though, I really don't think blips should update the BOLTs on a regular basis. |
|
Hmm ok what do you think @ariard @TheBlueMatt? For initial starting point can we compromise on blips staying inside the BOLT repo, but adding a new BOLT to this PR (lucky number 13?) for resource assignments (blipped feature bits, message types, and TLVs to start with)? New BOLT would be modeled on BOLT 9, but with a clear delineation that these assignments are for descriptive, not-intended-to-be-universal features. I will put that together this week if we think that's a good path forward. |
|
I'm confused - i thought the bLIP spec here was going to include a discussion of what is and what isn't appropriate as a bLIP (specifically, a few meetings ago we'd discussed and seemed to have some agreement around "if its intended to become universal or near universal, it must be a bolt"). I think, concretely, we should require that each bLIP have a discussion section specifically around why the spec here is not intended to become universal and why its a good idea as a non-universal protocol. As for the question about external repo, I don't really care. I'd ideally prefer it be in the same repo just so that everyone is aware of what's going on in it, but if people feel strongly, I don't think "where does it live" should block moving forward. |
|
I think I'm aligned with t-bast on preference:
First position is motivated by making it obvious that bLIPs aren't binding and not blessed by Lightning devs "at-your-own-risk". Even if we start blips inside the BOLT repo with agreement to move them in their own in the future, I'm worried we'll never do it because of the migration cost. Second position to avoid blips editing BOLT9 on a regular basis with a clear delineation. Make it easy also for DLC devs to re-use this new BOLT without being that much involved with the BOLT process. |
|
What do we add other than more friction by having a standalone repo? Re-using this one simplifies things significantly (same set of maintainers), and also allows us to easy "upgrade" something from a bLIP to a BOLT addition in a single commit. I don't think we need to sweat the "if it's intended to become universal thing" that much. As written, it's a very loose heuristic that gives the author of w/e spec proposal a lot of freedom w.r.t what type of proposal they want to make. The answer to the question in many cases may simply be: "maybe it'll be universal later, after the experimentation phase". Let's not over design this thing.
What's the advantage of this over just re-using BOLT 9 with a new table section that delineates things beyond that "official" type numbering (as the keysend BIP does)? Why force people to look in two different places rather than have a single place where you can get an overview of the entire allocated namespace? Don't really see anything here that's critically blocking to be able to move forward with this IMO. |
I'm confused, in the meeting a few weeks ago you explicitly agreed that the suggested text there would make since in the bLIP definition :). More generally, I strongly disagree that we should just ignore it. One issue that a number of people (including myself) have noted with bLIPs is concern over over-fragmentation of implemented lightning features - its already an issue and formalizing it could make it worse. Forcing someone to write down why they think its OK for their bLIP to never target being "universally implemented" I think is important. I strongly disagree that "maybe it'll be universal later, but want to deploy it now" is sufficient justification for a bLIP - that's how we ended up with keysend being a de-facto requirement in the spec with near-universal agreement that its a bad idea. |
Doesn't address the "blips-are-blessed-by-LN-devs" perception point ? Also minimizing the cognitive overload for bolts contributors not interested to be involved in the blips process on a regular basis. |
No where did I say we should ignore it. Instead I mean that it's a very rough heuristic, people will attempt to interpret it as they wish, and we'll learn from the first few iterations, possibly causing us to tighten the wording a bit. "Universal" itself is very open to interpretation.
Not sure this this really avoidable. Lightning has a pretty massive design space, and the best way to approach it imo is to encourage innovation at the edges, which is already happening as is, with very little written down. I'm not sure that the functionality of all implementations will very converge to 100% adherence like we had in the past, and that's ok: we put in all the extension mechanisms (TLV, feature bits, even/odd) in order to allow such loosely coupled evolution in the first place. IMO it's difficult for developers to keep up with and review every new proposed BOLT addition (with varying sizing). We end up artificially "blocking" (not really blocking, but say withholding "blessing") cool things from being deployed. This isn't the base Bitcoin blockchain that requires 100% agreement for new deployments. The bLIP can be a fast path for people to write down their idea then experiment w/ it in the wild before choosing to attempt to participate in the greater BOLT process.
You'll only create barriers to entry with an attitude like that. Keysend started out as a "hey let's just try this thing out, developers seem excited about the concept, it'll hold us over until AMP". Of course, AMP took a lot longer thatn we expected, but by having a optimistic attitude, we were able to deploy something that developers loved, and eventually become a widely adopted feature. Critically, given that it was an end to end feature, only the endpoints needed to actually upgrade in order to use it. Process for the sake of process will just drive developers to do their own thing (like the LN-URL suite, Simple Bitcoin Wallet, etc, etc). |
is explicitly included in the Abstract. Can discuss in an hour if we want to add a per-bLIP section detailing this as well, but does seem overly burdensome. Who decides if the rationale isn't good enough? The whole point of bLIPs is to lower the burden on developers specifying new application-level features so that they actually specify them. Seems like a likely outcome would be debate over whether a given feature could unintentionally become universal so therefore it shouldn't be blipped, which would nullify the decreased burden goal. Seems like @t-bast and @ariard both want a new BOLT to formalize the registries currently held in #605 and #716 (plus one for TLVs), instead of amending BOLT 9. I don't feel strongly where this lives but think said registry formalization is a good idea and am trying to optimize for as light a change as possible. My gut says a new BOLT is a bigger change than amending an existing one, but if we get agreement in #916 that a new BOLT is the way I can draw one up (modeled on BOLT 9 ofc). |
Yep, we all agreed its very rough, and that that's ok, as you note we'll learn :). You did say this, though, which I read as "we dont need to bother even mentioning it in this doc, ignore it":
Yep, I think we're all for people experimenting, and bLIPs being a good way to write up things that you're deploying that can provide users with cool new features that aren't 'standardized'. That said, there's a tradeoff here, and we need to be careful.
Sheesh, lets leave "attitude" out of arguments, it tends to not be productive. There's a tradeoff here that is, I thought, readily acknowledged - we should be willing to experiment with things and build cool stuff, but getting to the point where users rely on/expect "nonstandard" things to be a part of every lightning wallet has created a really painful UX for a lot of lightning users today. I'm noting that we should be aware of that tradeoff and not go full-throttle in one (or the other) direction. We can (and have been, over the past month or two) improving BOLT spec velocity, and continued investment by each major lightning implementation in implementing shared, standardized, new features is the only way we keep lightning's UX cohesive, whether those things are in BOLTs, bLIPs, or on scratched on the back of a napkin. |
I didn't say anything about whether a section being "not good enough" implies something doesn't become a bLIP, my current read of the spec seems to imply that there is no mechanism for that. However, making someone write that section out still has value. We should expect people to write their reasoning as a mechanism to ensure people are cognizant of the tradeoffs being made when we deploy things that aren't broadly supported, as that has a real UX cost that users complain about regularly today. |
|
And on new BOLT vs. amending BOLT 9? |
I think we can't ignore the spotlight boost offered by the BOLT process for new proposals of standards. Therefore, any piece of information which gets dubbed as a BOLT is likely to get a faster adoption, which sounds to me a double-edge. It's a faster way to get wide deployment of cool things. Though at the same time if those ones are unsafe or rough, they present higher risks to compromise the safety or confidentiality of far more users funds. Should we "bless" more the adoption of blips features in the Lightning ecosystem, when we sound to all agree that we're a bit short to keep up with the current BOLT review pace ? IMHO, the blips offers a new interesting process, more sandbox-like, where a feature can get short feedback-cycle and iterate fast while still letting stakeholders to get involved, beyond the bounds of a specific implementation. And when a feature is mature it should be free to get upgraded as a BOLT, if we expect this one to be part of the standard lightning UX. Where I agree, it's about the low-relevant "Universal" criteria. Ultimately, what becomes an universal Lightning feature will be a result of the evolutionary process at the ecosystem-level. |
I'd really like a separate BOLT, for a clean separation of concerns. Bolt 9 is for official Bolt features, I'd like to avoid muddying the distinction between blips and bolts just because we want to avoid creating a new file (which takes only a few minutes worth of additional work). Also, this new Bolt doesn't only contain features (which is what Bolt 9 does), but a lot of other scarce resources, so it doesn't fit much in Bolt 9 anyway (imho). |
|
Opened up a PR in the new blips repo and added @t-bast and @TheBlueMatt as reviewers. Will close this PR once that one is merged 👍. |
|
Closing this PR, as it has moved to the https://github.com/lightning/blips repository. |
This PR creates a new bLIPs (Bitcoin Lightning Improvement Proposals) folder in the lightning-rfc repository, and adds bLIP-0001 to describe the bLIP process. As mentioned on the mailing list, bLIPs are intended to be descriptive design documents for best practices occurring in the Lightning ecosystem. bLIPs should complement the prescriptive BOLTs.
Happy to adjust title, formatting (markdown preferred?), and/or content as requested. Additionally, I would love help with three things in particular: