From f1658f4adc6af7b2e927193693b653b471c5faa0 Mon Sep 17 00:00:00 2001 From: Ryan Gentry Date: Wed, 23 Jun 2021 11:50:51 -0500 Subject: [PATCH 01/16] Created blip-0001 --- blips/blip-0001.mediawiki | 239 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 239 insertions(+) create mode 100644 blips/blip-0001.mediawiki diff --git a/blips/blip-0001.mediawiki b/blips/blip-0001.mediawiki new file mode 100644 index 000000000..a9239b2d5 --- /dev/null +++ b/blips/blip-0001.mediawiki @@ -0,0 +1,239 @@ +
+bLIP: 1
+Title: bLIP process
+Status: Active
+Type: Process
+Author: Ryan Gentry , *ideally plus one person from each client team*
+Created: 2021-05-21
+License: BSD-2-Clause, OPL
+
+ +==Abstract== + +bLIP stands for Bitcoin Lightning Improvement Proposal. A bLIP is a design document providing information to the Lightning community, or describing a new feature for the Lightning Network or its processes or environment. The bLIP should provide a concise technical specification of the feature and a rationale for the feature. The bLIP author is responsible for building consensus within the community and documenting dissenting opinions. + +==Copyright== + +This bLIP is dual-licensed under the Open Publication License and BSD 2-clause license. + +==Rationale== + +As the Lightning community has grown, new features, standards, and protocols have been developed outside of the BOLT specification process: particularly at the application, forwarding, and routing level that isn’t described within the core BOLT documents. This is great! But in the spirit of interoperability, documenting features, standards, and protocols in a single location with a standard format will make it easy on future adopters. + +bLIPs will serve as the primary mechanism for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into the Lightning Network. Hopefully, they will provide an avenue for developers to quickly get feedback on their ideas outside of the main BOLT process. Because the bLIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal. + +For Lightning developers, bLIPs are a convenient way to track the progress of their implementation. Ideally, each implementation editor would list the bLIPs they have implemented. This will give end users a convenient way to know the current status of a given implementation or library. + +==bLIP Types== + +There are three kinds of bLIP: + +* A **Standards Track bLIP** describes any change that affects most or all Lightning implementations, such as—a change to the network protocol, a change in HTLC types or funding transaction rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Lightning. Standards Track bLIPs consist of three parts—a design document, an implementation, and (if warranted) an update to the Basics of Lightning Technology (BOLT) specification. Furthermore, Standards Track bLIPs can be broken down into the following categories: + * Core: improvements requiring changes to the BOLTs, as well as changes that are not necessarily critical but may be relevant to “protocol dev” discussions, and routing node strategy changes. + * Routing/Pathfinding: includes improvements around the routing protocol, as well as proposed improvements to the onion routing protocol specification ([BOLT #4](https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md)). + * Networking: includes improvements around the gossip protocol, as well as proposed improvements to network protocol specifications ([BOLT #7](https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md)). + * Lightning Request for Comments (LRC): application-level standards and conventions. +* A **Process bLIP** describes a process surrounding Lightning, or proposes a change to (or an event in) a process. Process bLIPs are like Standards Track bLIPs but apply to areas other than the Lightning protocol itself. They may propose an implementation, but not to the BOLT specification; they often require community consensus; unlike Informational bLIPs, they are more than recommendations, and users are strongly encouraged to adopt them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Lightning development. Any meta-bLIP is also considered a Process bLIP. +* An **Informational bLIP** describes a Lightning design issue, or provides general guidelines or information to the Lightning community, but does not propose a new feature. Informational bLIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementers are free to ignore Informational bLIPs or follow their advice. + +It is highly recommended that a single bLIP contain a single key proposal or new idea. More focused bLIPs will tend to be more successful. If in doubt, a bLIP should be split into several well-focused ones. + +A change that affects multiple clients, or defines a standard for multiple apps to use, requires a bLIP, but a change to one client does not. + +==bLIP Workflow== + +The bLIP process begins with a new idea for Lightning. Each potential bLIP must have a champion -- someone who writes the bLIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The bLIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is bLIP-able. The first step should be to search past discussions to see if an idea has been considered before, and if so, what issues arose in its progression. Such discussion generally happens on the [Lightning development mailing list](https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev), or in the ##lightning-dev IRC channel. + +Once the champion has asked the Lightning community as to whether an idea has any chance of acceptance, a draft bLIP should be presented to the [Lightning development mailing list](https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev). This gives the author a chance to flesh out the draft bLIP to make it properly formatted, of high quality, and to address additional concerns about the proposal. Following a discussion, the proposal should be submitted to the [bLIP folder of the lightning-rfc git repository](https://github.com/lightningnetwork/lightning-rfc) as a pull request. This draft must be written in bLIP style as described below, and its bLIP number will be the PR number automatically assigned by Github (or, if preferred by the author, the Issue # if there was discussion in the Issues section of this repository about this bLIP). + +When the bLIP draft is complete, the lightning-rfc editors will label it as Standards Track, Informational, or Process, and merge the pull request into the proposals folder in the lightning-rfc repository. The editors will not unreasonably reject a bLIP. Reasons for rejecting bLIPs include duplication of effort, disregard for formatting rules, being too unfocused or too broad, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Bitcoin and Lightning Network philosophy. For a bLIP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly. + +The bLIP author may update the draft as necessary in the git repository. Updates to drafts should also be submitted by the author as pull requests. + +==What belongs in a successful bLIP?== + +bLIPs should be written in mediawiki format. + +Each bLIP should have the following parts: + +* Preamble -- Headers containing metadata about the bLIP (see below). +* Abstract -- A short (~200 word) description of the technical issue being addressed. +* Copyright -- The bLIP must be explicitly licensed under acceptable copyright terms (see below). +Specification -- The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Lightning implementations. +* Motivation -- The motivation is critical for bLIPs that want to change the Lightning protocol. It should clearly explain why the existing protocol is inadequate to address the problem that the bLIP solves. +* Rationale -- The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work. The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion. +* Backwards compatibility -- All bLIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The bLIP must explain how the author proposes to deal with these incompatibilities. +* Reference implementation -- The reference implementation must be completed before any bLIP is given status "Final", but it need not be completed before the bLIP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code. The final implementation must include test code and documentation appropriate for the Lightning protocol. + +==bLIP Header Preamble== + +Each bLIP must begin with an RFC 822 style header preamble. The headers must appear in the following order. Headers marked with "*" are optional and are described below. All other headers are required. + +
+bLIP: bLIP number, this is determined by the bLIP editor
+Title: bLIP title
+Author: list of the author's or authors' name(s) and/or username(s), or name(s) and email(s). Details are below.
+* Discussions-To: a url pointing to the official discussions thread
+Status: Draft, Active, Proposed, Deferred, Rejected, Withdrawn, Final, Replaced, Obsolete
+Type: Standards Track, Informational, Process
+Category: Core, Networking, Routing, Interface, or LRC (fill out for Standards Track bLIPs only)
+Created: date created on, in ISO 8601 (yyyy-mm-dd) format
+* Post-History: dates of postings to lightning-dev mailing list, or link to thread in mailing list archive
+  License: abbreviation for approved license(s)
+* License-Code: abbreviation for code under different approved license(s)
+* Requires: bLIP number(s)
+* Replaces: bLIP number
+* Superseded-By: bLIP number
+
+ +The Category header (only for Standards Track bLIPs) documents which aspect of Lightning the bLIP applies to. + +The Author header lists the names and email addresses of all the authors/owners of the bLIP. The format of the Author header value must be: + + Random J. User + +If there are multiple authors, each should be on a separate line following RFC 2822 continuation line conventions. + +While a bLIP is in private discussions (usually during the initial Draft phase), a Discussions-To header will indicate the mailing list or URL where the bLIP is being discussed. No Discussions-To header is necessary if the bLIP is being discussed privately with the author, or on the bitcoin email mailing lists. + +The Type header specifies the type of bLIP: Standards Track, Informational, or Process. + +The Created header records the date that the bLIP was assigned a number, while Post-History is used to record when new versions of the bLIP are posted to bitcoin mailing lists. Dates should be in yyyy-mm-dd format, e.g. 2001-08-14. Post-History is permitted to be a link to a specific thread in a mailing list archive. + +bLIPs may have a Requires header, indicating the bLIP numbers that this bLIP depends on. + +bLIPs may also have a Superseded-By header indicating that a bLIP has been rendered obsolete by a later document; the value is the number of the bLIP that replaces the current document. The newer bLIP must have a Replaces header containing the number of the bLIP that it rendered obsolete. + +==bLIP status field== + +The typical paths of the status of bLIPs are as follows: + +flowchart.img + +**Draft** - The first formally tracked stage of a bLIP in development. A bLIP is merged by a bLIP Editor into the proposals folder of the lightning-rfc repository when properly formatted. + +**Deferred** - The bLIP editor may also change the status to Deferred when no progress is being made on the bLIP. + +**Withdrawn** - Champions of a bLIP may decide on their own to change the status between Draft, Deferred, or Withdrawn. + +**Rejected** - bLIPs should be changed from Draft status to Rejected status, upon request by any person, if they have not made progress in three years. Such a bLIP may be changed to Draft status if the champion provides revisions that meaningfully address public criticism of the proposal, or to Proposed status if it meets the criteria required as described in the previous paragraph. + +**Proposed** - a bLIP may only change status from Draft (or Rejected) to Proposed, when the author deems it is complete, has a working implementation (where applicable), and has community plans to progress it to the Final status. + +**Final / Active** - a Proposed bLIP may progress to Final only when specific criteria reflecting real-world adoption has occurred. This is different for each bLIP depending on the nature of its proposed changes, which will be expanded on below. Evaluation of this status change should be objectively verifiable, and/or be discussed on the development mailing list. A process bLIP may change status from Draft to Active when it achieves rough consensus on the mailing list. Such a proposal is said to have rough consensus if it has been open to discussion on the development mailing list for at least one month, and no person maintains any unaddressed substantiated objections to it. Addressed or obstructive objections may be ignored/overruled by general agreement that they have been sufficiently addressed, but clear reasoning must be given in such circumstances. + +**Replaced or Obsolete** - when a Final bLIP is no longer relevant, its status may be changed to Replaced or Obsolete (which is equivalent to Replaced). This change must also be objectively verifiable and/or discussed. + +==Auxiliary Files== + +bLIPs may include auxiliary files such as diagrams. Auxiliary files should be included in a subdirectory for that bLIP, or must be named bLIP-XXXX-Y.ext, where "XXXX" is the bLIP number, "Y" is a serial number (starting at 1), and "ext" is replaced by the actual file extension (e.g. "png"). + +==Transferring bLIP Ownership== + +It occasionally becomes necessary to transfer ownership of bLIPs to a new champion. In general, we'd like to retain the original author as a co-author of the transferred bLIP, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the bLIP process, or has fallen off the face of the 'net (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the bLIP. We try to build consensus around a bLIP, but if that's not possible, you can always submit a competing bLIP. + +If you are interested in assuming ownership of a bLIP, send a message asking to take over, addressed to both the original author and the bLIP editor. If the original author doesn't respond to email in a timely manner, the bLIP editor will make a unilateral decision (it's not like such decisions can't be reversed). + +==bLIP Editors== + +The current bLIP editors are: + +* Bastien Teinturier (@t-bast) +* Laolu Osuntokun (@roasbeef) +* Lisa Neigut (@niftynei) +* Matt Corrallo (@TheBlueMatt) + +==bLIP Editor Responsibilities & Workflow== + +For each new bLIP submission, the editors do the following: + +* Read the bLIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to get to final status. +* The title should accurately describe the content. +* The bLIP draft must have been sent to the lightning-dev mailing list for discussion. +* Motivation and backward compatibility (when applicable) must be addressed. +* Licensing terms must be acceptable for bLIPs. + +If the bLIP isn't ready, the editor will send it back to the author for revision, with specific instructions. + +Once the bLIP is ready for the repository, the bLIP editor will: + +* Assign a bLIP number (generally the PR number or, if preferred by the author, the Issue # if there was discussion in the Issues section of this repository about this bLIP) +* Merge the corresponding pull request +* Send a message back to the bLIP author with the next steps. + +The bLIP editors are intended to fulfill administrative and editorial responsibilities. They do not pass judgement on bLIPs. The bLIP editors monitor bLIP changes, and update bLIP headers as appropriate. + +==Licensing== + +New bLIPs may be accepted with the following licenses. Each new bLIP must identify at least one acceptable license in its preamble. The License header in the preamble must be placed after the Created header. Each license must be referenced by their respective abbreviation given below. + +For example, a preamble might include the following License header: + License: BSD-2-Clause + GNU-All-Permissive + +In this case, the bLIP text is fully licensed under both the OSI-approved BSD 2-clause license as well as the GNU All-Permissive License, and anyone may modify and redistribute the text provided they comply with the terms of *either* license. In other words, the license list is an "OR choice", not an "AND also" requirement. + +It is also possible to license source code differently from the bLIP text. An optional License-Code header is placed after the License header. Again, each license must be referenced by their respective abbreviation given below. + +For example, a preamble specifying the optional License-Code header might look like: + License: BSD-2-Clause + GNU-All-Permissive + License-Code: GPL-2.0+ + +In this case, the code in the bLIP is not available under the BSD or All-Permissive licenses, but only under the terms of the GNU General Public License (GPL), version 2 or newer. If the code were to be available under *only* version 2 exactly, the "+" symbol should be removed from the license abbreviation. For a later version (eg, GPL 3.0), you would increase the version number (and retain or remove the "+" depending on intent). + + License-Code: GPL-2.0 # This refers to GPL v2.0 *only*, no later license versions are acceptable. + License-Code: GPL-2.0+ # This refers to GPL v2.0 *or later*. + License-Code: GPL-3.0 # This refers to GPL v3.0 *only*, no later license versions are acceptable. + License-Code: GPL-3.0+ # This refers to GPL v3.0 *or later*. + +In the event that the licensing for the text or code is too complicated to express with a simple list of alternatives, the list should instead be replaced with the single term "Complex". In all cases, details of the licensing terms must be provided in the Copyright section of the bLIP. + +bLIPs are not required to be *exclusively* licensed under approved terms, and may also be licensed under unacceptable licenses *in addition to* at least one acceptable license. In this case, only the acceptable license(s) should be listed in the License and License-Code headers. + +====Recommended licenses==== + +* BSD-2-Clause: [https://opensource.org/licenses/BSD-2-Clause OSI-approved BSD 2-clause license] +* BSD-3-Clause: [https://opensource.org/licenses/BSD-3-Clause OSI-approved BSD 3-clause license] +* CC0-1.0: [https://creativecommons.org/publicdomain/zero/1.0/ Creative Commons CC0 1.0 Universal] +* GNU-All-Permissive: [http://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html GNU All-Permissive License] + +In addition, it is recommended that literal code included in the bLIP be dual-licensed under the same license terms as the project it modifies. For example, literal code intended for a Lightning client would ideally be dual-licensed under the MIT license terms as well as one of the above with the rest of the bLIP text. + +====Not recommended, but acceptable licenses==== + +* Apache-2.0: [http://www.apache.org/licenses/LICENSE-2.0 Apache License, version 2.0] +* BSL-1.0: [http://www.boost.org/LICENSE_1_0.txt Boost Software License, version 1.0] +* CC-BY-4.0: [https://creativecommons.org/licenses/by/4.0/ Creative Commons Attribution 4.0 International] +* CC-BY-SA-4.0: [https://creativecommons.org/licenses/by-sa/4.0/ Creative Commons Attribution-ShareAlike 4.0 International] +* MIT: [https://opensource.org/licenses/MIT Expat/MIT/X11 license] +* AGPL-3.0+: [http://www.gnu.org/licenses/agpl-3.0.en.html GNU Affero General Public License (AGPL), version 3 or newer] +* FDL-1.3: [http://www.gnu.org/licenses/fdl-1.3.en.html GNU Free Documentation License, version 1.3] +* GPL-2.0+: [http://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html GNU General Public License (GPL), version 2 or newer] +* LGPL-2.1+: [http://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html GNU Lesser General Public License (LGPL), version 2.1 or newer] + +====Not acceptable licenses==== + +All licenses not explicitly included in the above lists are not acceptable terms for a Bitcoin Lightning Improvement Proposal unless a later bLIP extends this one to add them. However, bLIPs predating the acceptance of this bLIP were allowed under other terms, and should use these abbreviation when no other license is granted: + +* OPL: [http://opencontent.org/openpub/ Open Publication License, version 1.0] +* PD: Released into the public domain + +====Rationale==== + +Why is OPL insufficient? +* The OPL is generally regarded as obsolete, and not a license suitable for new publications. +Many are unfamiliar with the OPL terms, and may just prefer to use the public domain rather than license under uncertain terms. +* The OPL license terms allowed for the author to prevent publication and derived works, which was widely considered inappropriate for Bitcoin standards. +* Public domain is not universally recognised as a legitimate action, thus it is inadvisable. + +Why are there software licenses included? +* Some bLIPs may include literal code in the bLIP itself which may not be available under the exact license terms of the bLIP. +* Despite this, not all software licenses would be acceptable for content included in bLIPs. + +Why is Public Domain no longer acceptable for new bLIPs? +* In some jurisdictions, public domain is not recognised as a legitimate legal action, leaving the bLIP simply copyrighted with no redistribution or modification allowed at all. + +==History== + +This document was derived heavily from [Bitcoin's BIP-0002](https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki) written by Luke Jr. which in turn was derived from [Python's PEP-0001](https://www.python.org/dev/peps/). In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Bitcoin Lightning Improvement Process, and should not be bothered with technical questions specific to the Lightning Network or the bLIP. Please direct all comments to the bLIP editors. From 285e643a9038687bfc445c95e55e17a12f20adb3 Mon Sep 17 00:00:00 2001 From: Ryan Gentry Date: Wed, 23 Jun 2021 12:07:19 -0500 Subject: [PATCH 02/16] formatting --- blips/blip-0001.mediawiki | 40 ++++++++++++++++++++------------------- 1 file changed, 21 insertions(+), 19 deletions(-) diff --git a/blips/blip-0001.mediawiki b/blips/blip-0001.mediawiki index a9239b2d5..7b86738fd 100644 --- a/blips/blip-0001.mediawiki +++ b/blips/blip-0001.mediawiki @@ -26,15 +26,15 @@ For Lightning developers, bLIPs are a convenient way to track the progress of th ==bLIP Types== -There are three kinds of bLIP: +There are three kinds of bLIPs: -* A **Standards Track bLIP** describes any change that affects most or all Lightning implementations, such as—a change to the network protocol, a change in HTLC types or funding transaction rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Lightning. Standards Track bLIPs consist of three parts—a design document, an implementation, and (if warranted) an update to the Basics of Lightning Technology (BOLT) specification. Furthermore, Standards Track bLIPs can be broken down into the following categories: - * Core: improvements requiring changes to the BOLTs, as well as changes that are not necessarily critical but may be relevant to “protocol dev” discussions, and routing node strategy changes. - * Routing/Pathfinding: includes improvements around the routing protocol, as well as proposed improvements to the onion routing protocol specification ([BOLT #4](https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md)). - * Networking: includes improvements around the gossip protocol, as well as proposed improvements to network protocol specifications ([BOLT #7](https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md)). - * Lightning Request for Comments (LRC): application-level standards and conventions. -* A **Process bLIP** describes a process surrounding Lightning, or proposes a change to (or an event in) a process. Process bLIPs are like Standards Track bLIPs but apply to areas other than the Lightning protocol itself. They may propose an implementation, but not to the BOLT specification; they often require community consensus; unlike Informational bLIPs, they are more than recommendations, and users are strongly encouraged to adopt them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Lightning development. Any meta-bLIP is also considered a Process bLIP. -* An **Informational bLIP** describes a Lightning design issue, or provides general guidelines or information to the Lightning community, but does not propose a new feature. Informational bLIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementers are free to ignore Informational bLIPs or follow their advice. +* A Standards Track bLIP describes any change that affects most or all Lightning implementations, such as—a change to the network protocol, a change in HTLC types or funding transaction rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Lightning. Standards Track bLIPs consist of three parts—a design document, an implementation, and (if warranted) an update to the Basics of Lightning Technology (BOLT) specification. Furthermore, Standards Track bLIPs can be broken down into the following categories: +** Core: improvements requiring changes to the BOLTs, as well as changes that are not necessarily critical but may be relevant to “protocol dev” discussions, and routing node strategy changes. +** Routing/Pathfinding: includes improvements around the routing protocol, as well as proposed improvements to the onion routing protocol specification ([https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md BOLT #4]). +** Networking: includes improvements around the gossip protocol, as well as proposed improvements to network protocol specifications ([https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md BOLT #7]). +** Lightning Request for Comments (LRC): application-level standards and conventions. +* A Process bLIP describes a process surrounding Lightning, or proposes a change to (or an event in) a process. Process bLIPs are like Standards Track bLIPs but apply to areas other than the Lightning protocol itself. They may propose an implementation, but not to the BOLT specification; they often require community consensus; unlike Informational bLIPs, they are more than recommendations, and users are strongly encouraged to adopt them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Lightning development. Any meta-bLIP is also considered a Process bLIP. +* An Informational bLIP describes a Lightning design issue, or provides general guidelines or information to the Lightning community, but does not propose a new feature. Informational bLIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementers are free to ignore Informational bLIPs or follow their advice. It is highly recommended that a single bLIP contain a single key proposal or new idea. More focused bLIPs will tend to be more successful. If in doubt, a bLIP should be split into several well-focused ones. @@ -42,9 +42,9 @@ A change that affects multiple clients, or defines a standard for multiple apps ==bLIP Workflow== -The bLIP process begins with a new idea for Lightning. Each potential bLIP must have a champion -- someone who writes the bLIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The bLIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is bLIP-able. The first step should be to search past discussions to see if an idea has been considered before, and if so, what issues arose in its progression. Such discussion generally happens on the [Lightning development mailing list](https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev), or in the ##lightning-dev IRC channel. +The bLIP process begins with a new idea for Lightning. Each potential bLIP must have a champion -- someone who writes the bLIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The bLIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is bLIP-able. The first step should be to search past discussions to see if an idea has been considered before, and if so, what issues arose in its progression. Such discussion generally happens on the [https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev Lightning development mailing list], or in the ##lightning-dev IRC channel. -Once the champion has asked the Lightning community as to whether an idea has any chance of acceptance, a draft bLIP should be presented to the [Lightning development mailing list](https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev). This gives the author a chance to flesh out the draft bLIP to make it properly formatted, of high quality, and to address additional concerns about the proposal. Following a discussion, the proposal should be submitted to the [bLIP folder of the lightning-rfc git repository](https://github.com/lightningnetwork/lightning-rfc) as a pull request. This draft must be written in bLIP style as described below, and its bLIP number will be the PR number automatically assigned by Github (or, if preferred by the author, the Issue # if there was discussion in the Issues section of this repository about this bLIP). +Once the champion has asked the Lightning community as to whether an idea has any chance of acceptance, a draft bLIP should be presented to the [https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev Lightning development mailing list]. This gives the author a chance to flesh out the draft bLIP to make it properly formatted, of high quality, and to address additional concerns about the proposal. Following a discussion, the proposal should be submitted to the [https://github.com/lightningnetwork/lightning-rfc bLIP folder of the lightning-rfc repository] as a pull request. This draft must be written in bLIP style as described below, and its bLIP number will be the PR number automatically assigned by Github (or, if preferred by the author, the Issue # if there was discussion in the Issues section of this repository about this bLIP). When the bLIP draft is complete, the lightning-rfc editors will label it as Standards Track, Informational, or Process, and merge the pull request into the proposals folder in the lightning-rfc repository. The editors will not unreasonably reject a bLIP. Reasons for rejecting bLIPs include duplication of effort, disregard for formatting rules, being too unfocused or too broad, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Bitcoin and Lightning Network philosophy. For a bLIP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly. @@ -59,7 +59,7 @@ Each bLIP should have the following parts: * Preamble -- Headers containing metadata about the bLIP (see below). * Abstract -- A short (~200 word) description of the technical issue being addressed. * Copyright -- The bLIP must be explicitly licensed under acceptable copyright terms (see below). -Specification -- The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Lightning implementations. +* Specification -- The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Lightning implementations. * Motivation -- The motivation is critical for bLIPs that want to change the Lightning protocol. It should clearly explain why the existing protocol is inadequate to address the problem that the bLIP solves. * Rationale -- The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work. The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion. * Backwards compatibility -- All bLIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The bLIP must explain how the author proposes to deal with these incompatibilities. @@ -90,7 +90,7 @@ The Category header (only for Standards Track bLIPs) documents which aspect of L The Author header lists the names and email addresses of all the authors/owners of the bLIP. The format of the Author header value must be: - Random J. User + Random J. User If there are multiple authors, each should be on a separate line following RFC 2822 continuation line conventions. @@ -110,19 +110,19 @@ The typical paths of the status of bLIPs are as follows: flowchart.img -**Draft** - The first formally tracked stage of a bLIP in development. A bLIP is merged by a bLIP Editor into the proposals folder of the lightning-rfc repository when properly formatted. +* Draft - The first formally tracked stage of a bLIP in development. A bLIP is merged by a bLIP Editor into the proposals folder of the lightning-rfc repository when properly formatted. -**Deferred** - The bLIP editor may also change the status to Deferred when no progress is being made on the bLIP. +* Deferred - The bLIP editor may also change the status to Deferred when no progress is being made on the bLIP. -**Withdrawn** - Champions of a bLIP may decide on their own to change the status between Draft, Deferred, or Withdrawn. +* Withdrawn - Champions of a bLIP may decide on their own to change the status between Draft, Deferred, or Withdrawn. -**Rejected** - bLIPs should be changed from Draft status to Rejected status, upon request by any person, if they have not made progress in three years. Such a bLIP may be changed to Draft status if the champion provides revisions that meaningfully address public criticism of the proposal, or to Proposed status if it meets the criteria required as described in the previous paragraph. +* Rejected - bLIPs should be changed from Draft status to Rejected status, upon request by any person, if they have not made progress in three years. Such a bLIP may be changed to Draft status if the champion provides revisions that meaningfully address public criticism of the proposal, or to Proposed status if it meets the criteria required as described in the previous paragraph. -**Proposed** - a bLIP may only change status from Draft (or Rejected) to Proposed, when the author deems it is complete, has a working implementation (where applicable), and has community plans to progress it to the Final status. +* Proposed - a bLIP may only change status from Draft (or Rejected) to Proposed, when the author deems it is complete, has a working implementation (where applicable), and has community plans to progress it to the Final status. -**Final / Active** - a Proposed bLIP may progress to Final only when specific criteria reflecting real-world adoption has occurred. This is different for each bLIP depending on the nature of its proposed changes, which will be expanded on below. Evaluation of this status change should be objectively verifiable, and/or be discussed on the development mailing list. A process bLIP may change status from Draft to Active when it achieves rough consensus on the mailing list. Such a proposal is said to have rough consensus if it has been open to discussion on the development mailing list for at least one month, and no person maintains any unaddressed substantiated objections to it. Addressed or obstructive objections may be ignored/overruled by general agreement that they have been sufficiently addressed, but clear reasoning must be given in such circumstances. +* Final / Active - a Proposed bLIP may progress to Final only when specific criteria reflecting real-world adoption has occurred. This is different for each bLIP depending on the nature of its proposed changes, which will be expanded on below. Evaluation of this status change should be objectively verifiable, and/or be discussed on the development mailing list. A process bLIP may change status from Draft to Active when it achieves rough consensus on the mailing list. Such a proposal is said to have rough consensus if it has been open to discussion on the development mailing list for at least one month, and no person maintains any unaddressed substantiated objections to it. Addressed or obstructive objections may be ignored/overruled by general agreement that they have been sufficiently addressed, but clear reasoning must be given in such circumstances. -**Replaced or Obsolete** - when a Final bLIP is no longer relevant, its status may be changed to Replaced or Obsolete (which is equivalent to Replaced). This change must also be objectively verifiable and/or discussed. +* Replaced or Obsolete - when a Final bLIP is no longer relevant, its status may be changed to Replaced or Obsolete (which is equivalent to Replaced). This change must also be objectively verifiable and/or discussed. ==Auxiliary Files== @@ -168,6 +168,7 @@ The bLIP editors are intended to fulfill administrative and editorial responsibi New bLIPs may be accepted with the following licenses. Each new bLIP must identify at least one acceptable license in its preamble. The License header in the preamble must be placed after the Created header. Each license must be referenced by their respective abbreviation given below. For example, a preamble might include the following License header: + License: BSD-2-Clause GNU-All-Permissive @@ -176,6 +177,7 @@ In this case, the bLIP text is fully licensed under both the OSI-approved BSD 2- It is also possible to license source code differently from the bLIP text. An optional License-Code header is placed after the License header. Again, each license must be referenced by their respective abbreviation given below. For example, a preamble specifying the optional License-Code header might look like: + License: BSD-2-Clause GNU-All-Permissive License-Code: GPL-2.0+ From 12f7b11d2f45189558bc1057a03871e4870160d5 Mon Sep 17 00:00:00 2001 From: Ryan Gentry Date: Wed, 23 Jun 2021 12:10:55 -0500 Subject: [PATCH 03/16] formatting --- blips/blip-0001.mediawiki | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/blips/blip-0001.mediawiki b/blips/blip-0001.mediawiki index 7b86738fd..cf2334c8f 100644 --- a/blips/blip-0001.mediawiki +++ b/blips/blip-0001.mediawiki @@ -90,7 +90,9 @@ The Category header (only for Standards Track bLIPs) documents which aspect of L The Author header lists the names and email addresses of all the authors/owners of the bLIP. The format of the Author header value must be: +
   Random J. User 
+
If there are multiple authors, each should be on a separate line following RFC 2822 continuation line conventions. @@ -169,8 +171,10 @@ New bLIPs may be accepted with the following licenses. Each new bLIP must identi For example, a preamble might include the following License header: +
    License: BSD-2-Clause
              GNU-All-Permissive
+
In this case, the bLIP text is fully licensed under both the OSI-approved BSD 2-clause license as well as the GNU All-Permissive License, and anyone may modify and redistribute the text provided they comply with the terms of *either* license. In other words, the license list is an "OR choice", not an "AND also" requirement. @@ -178,17 +182,21 @@ It is also possible to license source code differently from the bLIP text. An op For example, a preamble specifying the optional License-Code header might look like: +
    License: BSD-2-Clause
              GNU-All-Permissive
-    License-Code: GPL-2.0+
+   License-Code: GPL-2.0+
+
In this case, the code in the bLIP is not available under the BSD or All-Permissive licenses, but only under the terms of the GNU General Public License (GPL), version 2 or newer. If the code were to be available under *only* version 2 exactly, the "+" symbol should be removed from the license abbreviation. For a later version (eg, GPL 3.0), you would increase the version number (and retain or remove the "+" depending on intent). +
    License-Code: GPL-2.0   # This refers to GPL v2.0 *only*, no later license versions are acceptable.
-    License-Code: GPL-2.0+  # This refers to GPL v2.0 *or later*.
-    License-Code: GPL-3.0   # This refers to GPL v3.0 *only*, no later license versions are acceptable.
-    License-Code: GPL-3.0+  # This refers to GPL v3.0 *or later*.
- 
+   License-Code: GPL-2.0+  # This refers to GPL v2.0 *or later*.
+   License-Code: GPL-3.0   # This refers to GPL v3.0 *only*, no later license versions are acceptable.
+   License-Code: GPL-3.0+  # This refers to GPL v3.0 *or later*.
+
+ In the event that the licensing for the text or code is too complicated to express with a simple list of alternatives, the list should instead be replaced with the single term "Complex". In all cases, details of the licensing terms must be provided in the Copyright section of the bLIP. bLIPs are not required to be *exclusively* licensed under approved terms, and may also be licensed under unacceptable licenses *in addition to* at least one acceptable license. In this case, only the acceptable license(s) should be listed in the License and License-Code headers. @@ -238,4 +246,4 @@ Why is Public Domain no longer acceptable for new bLIPs? ==History== -This document was derived heavily from [Bitcoin's BIP-0002](https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki) written by Luke Jr. which in turn was derived from [Python's PEP-0001](https://www.python.org/dev/peps/). In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Bitcoin Lightning Improvement Process, and should not be bothered with technical questions specific to the Lightning Network or the bLIP. Please direct all comments to the bLIP editors. +This document was derived heavily from [https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki Bitcoin's BIP-0002] written by Luke Jr. which in turn was derived from [https://www.python.org/dev/peps/ Python's PEP-0001]. In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Bitcoin Lightning Improvement Process, and should not be bothered with technical questions specific to the Lightning Network or the bLIP. Please direct all comments to the bLIP editors. From 2b463c32747a62f8ccfd14b6ee86045660b4e545 Mon Sep 17 00:00:00 2001 From: Ryan Gentry Date: Wed, 23 Jun 2021 12:22:13 -0500 Subject: [PATCH 04/16] formatting --- blips/blip-0001.mediawiki | 77 ++++++++++++++++++++------------------- 1 file changed, 39 insertions(+), 38 deletions(-) diff --git a/blips/blip-0001.mediawiki b/blips/blip-0001.mediawiki index cf2334c8f..cccd826ea 100644 --- a/blips/blip-0001.mediawiki +++ b/blips/blip-0001.mediawiki @@ -50,6 +50,42 @@ When the bLIP draft is complete, the lightning-rfc editors will label it as Stan The bLIP author may update the draft as necessary in the git repository. Updates to drafts should also be submitted by the author as pull requests. +====Transferring bLIP Ownership==== + +It occasionally becomes necessary to transfer ownership of bLIPs to a new champion. In general, we'd like to retain the original author as a co-author of the transferred bLIP, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the bLIP process, or has fallen off the face of the 'net (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the bLIP. We try to build consensus around a bLIP, but if that's not possible, you can always submit a competing bLIP. + +If you are interested in assuming ownership of a bLIP, send a message asking to take over, addressed to both the original author and the bLIP editor. If the original author doesn't respond to email in a timely manner, the bLIP editor will make a unilateral decision (it's not like such decisions can't be reversed). + +====bLIP Editors==== + +The current bLIP editors are: + +* Bastien Teinturier (@t-bast) +* Laolu Osuntokun (@roasbeef) +* Lisa Neigut (@niftynei) +* Matt Corrallo (@TheBlueMatt) +* *ideally plus some app layer volunteers* + +====bLIP Editor Responsibilities & Workflow==== + +For each new bLIP submission, the editors do the following: + +* Read the bLIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to get to final status. +* The title should accurately describe the content. +* The bLIP draft must have been sent to the lightning-dev mailing list for discussion. +* Motivation and backward compatibility (when applicable) must be addressed. +* Licensing terms must be acceptable for bLIPs. + +If the bLIP isn't ready, the editor will send it back to the author for revision, with specific instructions. + +Once the bLIP is ready for the repository, the bLIP editor will: + +* Assign a bLIP number (generally the PR number or, if preferred by the author, the Issue # if there was discussion in the Issues section of this repository about this bLIP) +* Merge the corresponding pull request +* Send a message back to the bLIP author with the next steps. + +The bLIP editors are intended to fulfill administrative and editorial responsibilities. They do not pass judgement on bLIPs. The bLIP editors monitor bLIP changes, and update bLIP headers as appropriate. + ==What belongs in a successful bLIP?== bLIPs should be written in mediawiki format. @@ -65,7 +101,7 @@ Each bLIP should have the following parts: * Backwards compatibility -- All bLIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The bLIP must explain how the author proposes to deal with these incompatibilities. * Reference implementation -- The reference implementation must be completed before any bLIP is given status "Final", but it need not be completed before the bLIP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code. The final implementation must include test code and documentation appropriate for the Lightning protocol. -==bLIP Header Preamble== +====bLIP Header Preamble==== Each bLIP must begin with an RFC 822 style header preamble. The headers must appear in the following order. Headers marked with "*" are optional and are described below. All other headers are required. @@ -106,7 +142,7 @@ bLIPs may have a Requires header, indicating the bLIP numbers that this bLIP dep bLIPs may also have a Superseded-By header indicating that a bLIP has been rendered obsolete by a later document; the value is the number of the bLIP that replaces the current document. The newer bLIP must have a Replaces header containing the number of the bLIP that it rendered obsolete. -==bLIP status field== +====bLIP status field==== The typical paths of the status of bLIPs are as follows: @@ -126,45 +162,10 @@ flowchart.img * Replaced or Obsolete - when a Final bLIP is no longer relevant, its status may be changed to Replaced or Obsolete (which is equivalent to Replaced). This change must also be objectively verifiable and/or discussed. -==Auxiliary Files== +====Auxiliary Files==== bLIPs may include auxiliary files such as diagrams. Auxiliary files should be included in a subdirectory for that bLIP, or must be named bLIP-XXXX-Y.ext, where "XXXX" is the bLIP number, "Y" is a serial number (starting at 1), and "ext" is replaced by the actual file extension (e.g. "png"). -==Transferring bLIP Ownership== - -It occasionally becomes necessary to transfer ownership of bLIPs to a new champion. In general, we'd like to retain the original author as a co-author of the transferred bLIP, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the bLIP process, or has fallen off the face of the 'net (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the bLIP. We try to build consensus around a bLIP, but if that's not possible, you can always submit a competing bLIP. - -If you are interested in assuming ownership of a bLIP, send a message asking to take over, addressed to both the original author and the bLIP editor. If the original author doesn't respond to email in a timely manner, the bLIP editor will make a unilateral decision (it's not like such decisions can't be reversed). - -==bLIP Editors== - -The current bLIP editors are: - -* Bastien Teinturier (@t-bast) -* Laolu Osuntokun (@roasbeef) -* Lisa Neigut (@niftynei) -* Matt Corrallo (@TheBlueMatt) - -==bLIP Editor Responsibilities & Workflow== - -For each new bLIP submission, the editors do the following: - -* Read the bLIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to get to final status. -* The title should accurately describe the content. -* The bLIP draft must have been sent to the lightning-dev mailing list for discussion. -* Motivation and backward compatibility (when applicable) must be addressed. -* Licensing terms must be acceptable for bLIPs. - -If the bLIP isn't ready, the editor will send it back to the author for revision, with specific instructions. - -Once the bLIP is ready for the repository, the bLIP editor will: - -* Assign a bLIP number (generally the PR number or, if preferred by the author, the Issue # if there was discussion in the Issues section of this repository about this bLIP) -* Merge the corresponding pull request -* Send a message back to the bLIP author with the next steps. - -The bLIP editors are intended to fulfill administrative and editorial responsibilities. They do not pass judgement on bLIPs. The bLIP editors monitor bLIP changes, and update bLIP headers as appropriate. - ==Licensing== New bLIPs may be accepted with the following licenses. Each new bLIP must identify at least one acceptable license in its preamble. The License header in the preamble must be placed after the Created header. Each license must be referenced by their respective abbreviation given below. From efb3b8dbd18a652d4553fefb8abbae5662048ded Mon Sep 17 00:00:00 2001 From: Ryan Gentry Date: Wed, 23 Jun 2021 12:23:32 -0500 Subject: [PATCH 05/16] formatting --- blips/blip-0001.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/blips/blip-0001.mediawiki b/blips/blip-0001.mediawiki index cccd826ea..eb0176db0 100644 --- a/blips/blip-0001.mediawiki +++ b/blips/blip-0001.mediawiki @@ -127,7 +127,7 @@ The Category header (only for Standards Track bLIPs) documents which aspect of L The Author header lists the names and email addresses of all the authors/owners of the bLIP. The format of the Author header value must be: 
-  Random J. User 
+Random J. User
If there are multiple authors, each should be on a separate line following RFC 2822 continuation line conventions. From 59587eea7ef5451578fa1ae8b4d3ba422d27f7e2 Mon Sep 17 00:00:00 2001 From: Ryan Gentry Date: Wed, 23 Jun 2021 12:26:44 -0500 Subject: [PATCH 06/16] formatting --- blips/blip-0001.mediawiki | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/blips/blip-0001.mediawiki b/blips/blip-0001.mediawiki index eb0176db0..f455c992d 100644 --- a/blips/blip-0001.mediawiki +++ b/blips/blip-0001.mediawiki @@ -126,9 +126,7 @@ The Category header (only for Standards Track bLIPs) documents which aspect of L The Author header lists the names and email addresses of all the authors/owners of the bLIP. The format of the Author header value must be: -
-Random J. User 
-
+ Random J. User If there are multiple authors, each should be on a separate line following RFC 2822 continuation line conventions. From 0d306e2fbbdc4bf0a9d712130a1b9ab672393009 Mon Sep 17 00:00:00 2001 From: Ryan Gentry <41025545+ryanthegentry@users.noreply.github.com> Date: Wed, 23 Jun 2021 12:29:38 -0500 Subject: [PATCH 07/16] formatting --- blips/blip-0001.mediawiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/blips/blip-0001.mediawiki b/blips/blip-0001.mediawiki index f455c992d..be4ecf5c4 100644 --- a/blips/blip-0001.mediawiki +++ b/blips/blip-0001.mediawiki @@ -126,8 +126,8 @@ The Category header (only for Standards Track bLIPs) documents which aspect of L The Author header lists the names and email addresses of all the authors/owners of the bLIP. The format of the Author header value must be: - Random J. User - + Random J. User + If there are multiple authors, each should be on a separate line following RFC 2822 continuation line conventions. While a bLIP is in private discussions (usually during the initial Draft phase), a Discussions-To header will indicate the mailing list or URL where the bLIP is being discussed. No Discussions-To header is necessary if the bLIP is being discussed privately with the author, or on the bitcoin email mailing lists. From ed9d73ac621672ac6b11ff6ff0a1327ae2881f97 Mon Sep 17 00:00:00 2001 From: Ryan Gentry <41025545+ryanthegentry@users.noreply.github.com> Date: Wed, 23 Jun 2021 12:30:59 -0500 Subject: [PATCH 08/16] formatting --- blips/blip-0001.mediawiki | 16 +++++----------- 1 file changed, 5 insertions(+), 11 deletions(-) diff --git a/blips/blip-0001.mediawiki b/blips/blip-0001.mediawiki index be4ecf5c4..f285e7c96 100644 --- a/blips/blip-0001.mediawiki +++ b/blips/blip-0001.mediawiki @@ -169,32 +169,26 @@ bLIPs may include auxiliary files such as diagrams. Auxiliary files should be in New bLIPs may be accepted with the following licenses. Each new bLIP must identify at least one acceptable license in its preamble. The License header in the preamble must be placed after the Created header. Each license must be referenced by their respective abbreviation given below. For example, a preamble might include the following License header: - -
+ 
    License: BSD-2-Clause
              GNU-All-Permissive
-
- + In this case, the bLIP text is fully licensed under both the OSI-approved BSD 2-clause license as well as the GNU All-Permissive License, and anyone may modify and redistribute the text provided they comply with the terms of *either* license. In other words, the license list is an "OR choice", not an "AND also" requirement. It is also possible to license source code differently from the bLIP text. An optional License-Code header is placed after the License header. Again, each license must be referenced by their respective abbreviation given below. For example, a preamble specifying the optional License-Code header might look like: - -
+ 
    License: BSD-2-Clause
              GNU-All-Permissive
    License-Code: GPL-2.0+
-
- -In this case, the code in the bLIP is not available under the BSD or All-Permissive licenses, but only under the terms of the GNU General Public License (GPL), version 2 or newer. If the code were to be available under *only* version 2 exactly, the "+" symbol should be removed from the license abbreviation. For a later version (eg, GPL 3.0), you would increase the version number (and retain or remove the "+" depending on intent). -
+In this case, the code in the bLIP is not available under the BSD or All-Permissive licenses, but only under the terms of the GNU General Public License (GPL), version 2 or newer. If the code were to be available under *only* version 2 exactly, the "+" symbol should be removed from the license abbreviation. For a later version (eg, GPL 3.0), you would increase the version number (and retain or remove the "+" depending on intent).
+ 
    License-Code: GPL-2.0   # This refers to GPL v2.0 *only*, no later license versions are acceptable.
    License-Code: GPL-2.0+  # This refers to GPL v2.0 *or later*.
    License-Code: GPL-3.0   # This refers to GPL v3.0 *only*, no later license versions are acceptable.
    License-Code: GPL-3.0+  # This refers to GPL v3.0 *or later*.
-
In the event that the licensing for the text or code is too complicated to express with a simple list of alternatives, the list should instead be replaced with the single term "Complex". In all cases, details of the licensing terms must be provided in the Copyright section of the bLIP. From 76bd6facf3bda282eb1971bde257951e37542455 Mon Sep 17 00:00:00 2001 From: Ryan Gentry <41025545+ryanthegentry@users.noreply.github.com> Date: Tue, 29 Jun 2021 12:29:05 -0500 Subject: [PATCH 09/16] Update blip-0001.mediawiki --- blips/blip-0001.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/blips/blip-0001.mediawiki b/blips/blip-0001.mediawiki index f285e7c96..745021c69 100644 --- a/blips/blip-0001.mediawiki +++ b/blips/blip-0001.mediawiki @@ -64,7 +64,7 @@ The current bLIP editors are: * Laolu Osuntokun (@roasbeef) * Lisa Neigut (@niftynei) * Matt Corrallo (@TheBlueMatt) -* *ideally plus some app layer volunteers* +* *these are just folks I've messaged about the idea, ideally would add some app layer volunteers too?* ====bLIP Editor Responsibilities & Workflow==== From c91f4aa367d006c110ce1606cf9182c021b3c219 Mon Sep 17 00:00:00 2001 From: Ryan Gentry <41025545+ryanthegentry@users.noreply.github.com> Date: Tue, 29 Jun 2021 12:30:13 -0500 Subject: [PATCH 10/16] Update blip-0001.mediawiki --- blips/blip-0001.mediawiki | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/blips/blip-0001.mediawiki b/blips/blip-0001.mediawiki index 745021c69..832469cfa 100644 --- a/blips/blip-0001.mediawiki +++ b/blips/blip-0001.mediawiki @@ -60,11 +60,11 @@ If you are interested in assuming ownership of a bLIP, send a message asking to The current bLIP editors are: -* Bastien Teinturier (@t-bast) -* Laolu Osuntokun (@roasbeef) -* Lisa Neigut (@niftynei) -* Matt Corrallo (@TheBlueMatt) -* *these are just folks I've messaged about the idea, ideally would add some app layer volunteers too?* +* ACINQ volunteer? +* c-lightning volunteer? +* lnd volunteer? +* rust-lightning volunteer? +* ideally would add some app layer volunteers too* ====bLIP Editor Responsibilities & Workflow==== From 99b1b58cbf8c5ab30f284d74bbe8502e82cded60 Mon Sep 17 00:00:00 2001 From: Ryan Gentry <41025545+ryanthegentry@users.noreply.github.com> Date: Thu, 29 Jul 2021 15:19:55 -0500 Subject: [PATCH 11/16] Adjusted bLIP editors to be BOLT editors. --- blips/blip-0001.mediawiki | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/blips/blip-0001.mediawiki b/blips/blip-0001.mediawiki index 832469cfa..8ef7d7a6c 100644 --- a/blips/blip-0001.mediawiki +++ b/blips/blip-0001.mediawiki @@ -58,13 +58,7 @@ If you are interested in assuming ownership of a bLIP, send a message asking to ====bLIP Editors==== -The current bLIP editors are: - -* ACINQ volunteer? -* c-lightning volunteer? -* lnd volunteer? -* rust-lightning volunteer? -* ideally would add some app layer volunteers too* +The current BOLT editors are the bLIP editors. ====bLIP Editor Responsibilities & Workflow==== From 611fee5bbab9008562c7f9fc78282297ec36ed26 Mon Sep 17 00:00:00 2001 From: Ryan Gentry Date: Fri, 13 Aug 2021 11:07:53 -0500 Subject: [PATCH 12/16] Updated to Markdown, removed Types, simplified Licensing, added Feature Bit/Message Type/TLV to Rationale, added Status diagram. --- blips/blip-0001/blip-0001-1.png | Bin 0 -> 10389 bytes 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 blips/blip-0001/blip-0001-1.png diff --git a/blips/blip-0001/blip-0001-1.png b/blips/blip-0001/blip-0001-1.png new file mode 100644 index 0000000000000000000000000000000000000000..b53279901180a4cb13c1905e053790b290703692 GIT binary patch literal 10389 zcmb7qc{tQ<+yAtnlADNW5t1d@T1c`ck}XPxv4*j4Wz90klC5HtCA;j)kdcuQlS(GC zWgQIe3Ne;Mb~W7E2> zehUWMjRV*9`ZE%ht6?+?vovcA@{+iGF`)NnE-CO`4}t^AKlhYPP1 z94DNAyjpy7`seY7S z@Pv1Va(3r(`BX+jfBk5~syuPUESpiWh91zuTt`hUglq@4B+4acZ;erJgzf$1cT#!j zGj5~E4t7(2mWzJ$Xy+w8ORr;F9R41Ef63f;ugPC^wwiKnmt z!P7le`ifVjVjZ@oh0Y0V+~eb*tIl$DhLUz`J^Id)!SX>FDkXqZL4 zgV7RqcZu%Y>d&6S{qNuUUqvbS&6httYcFQ`eRGM!St&={yT>No!OL51$~ z^A(QWFWkFwuHfh6q#N(D{KYE}gV}s?*>`!OZA$yu>A#Q3I)Ask|97NfcIp}9irJx8 zPVfB_!flCG#Nhq+c!_V;MgtM6i8@mER%ZGXthd`rjmij2& zzx@*~{pC*bDhhSuVXSJ|;)|Q~vF#2_#Z#&V-nQjQg-(hTek7Pa$8$Jwx7J)36YCRd zVB;2zx|(&Mk-k72lQe(b)&BfK3%58z!YM%zCq#T%Rkr3j*4QAd>=w96b~uDozi1pi z`&e%D$m4J8cGP|>VzpJg(i>}5+i^&+?Av2?!Q4(GS<@e09jWKO6~{}HeZH!1>v520 zeU71TmRL3r6gIv;wRn6?c7)Hhbk$ zzXxC_csH|m_yV02f}lq1>qKE4fiw7Pb$A>y z?mblS{=p&G=AZCQ!^7 ziO(u{b5YZ8u^C=(sIS!b__&;ub^S4s-q#}CZ1~wJ5zO2ek+@%8FkSDwz_oZjx8bOR zM?FVI4Qp9$Pl;v+g^?0BZm#i|Fo0@#<8<&y`nqcv^)pYTN=RpF5a?;mxhaHyUMzY;Ew|k7DP4GJkxQUNEfZ zHjICa^rK>Hp*ggDLaDH*A6l((8L&TEtCK8oFU2ajj`F}@7Vk>_f;FiUENnEbaYo8L z)Z|C^(h}fO=7W8eR$~pcnX>&0Ckh)Y8)>Z+?;gF1ppB(&uZj4OOAsI>uC(%*lxUKDGU?+QOW(HHR1>hN9cO9(8Ahk(qa&D?9*8>m z6Bx#F_O`2}gZ1mbA0D55hrOSD*{2lUPu!f4)@qY7!+-v2#t;PS)otJ*yUJ!4zJPFJ z@3shmDN`jRcrAN-Q?$@hE4*VsVgB{0x#a_xcI6_ck=IoW>D5`X*9V?pM(0d#$x{KG zbCuHCh?gYGnf|Hvba-{;Qp3ls(;;QLr5R=Q-NxqkB2Va)Zf5GDj4LhYf*Dk+VT$S; zoZoQ3G7y`|`pI0h41I`fo3QIl|O^RcEZy!kcB?mp+eZ ziN+P?^3+oqGnWr-rmru;Iq3pVMfLG3l?|(=rc>Ni*=WJC`7^QHpIi~IocmfM4A|T( zQNkfZM2F6-e$%pT>{qeW^dx?6edQ@_AtU{>$v&f}i|Ct-A{E9b&qkY5_m!gI$mYj3 z3P%iQ2FiSt3%y0JK86Q$-Z>aWhGUejVfs{b>^5t8#!3m+?;oZL+|DksZ%-2r;_9zW zE30fwt6(z!tbc#DG(PF8w&aDO!v36b_{;UzeYJF}t)-Mz$>6nlO83fet%uwvMfz-Y z9@> zS6o#0&is0lIvTXxo{F1UD_%ZziSH^rAgND6uB3vii5SyyR4dA~C(PWdT~?%-W)`7T z8O@mGMowJcpGC+!?TH#!}kpHT2MX`^buEl`yzTkE#sT-jbe zS?gXJ8;0M`d|j?3bX^Y(9|*sX>2vwyakkLA;&es$xukNJD}&JDtMZ zBtAsd8m`P)PRP8Ka7BaQ_{w8l+p^leJr*yq7fB3mNLuJAiqAA|(vaLYgtu$ssb}Pm z^${f+BdHElR>TT&2O!1OOdW!`m|I_5O7Q<^6k|?_)Wc%MCz7A znhXc&HpjVMrVHX)1aPz{r^&D!j{F%DY@r`|t4*r@b7Rvwig(sF4uJX-hgs&LG1`0n ztvglu>fB=sV#pC?fF}sepQ}$b(Kl+^L)ubgikoG!rm{muTc>^PF0U}=JVL5Jl={pN zi^L+l15L24HUN{59nz&A6zp0L)6v~8H1;o)m=U5~=Q+rEbEe}S!z|sjbrbfd>F=Y< zr7Es$=tVZF)1)ra5~tuQ2D$@>DNR3XX+9E9Mf47=)Lu>`1>9Vrux@UYtm#d?5nQb{ zMnyJ`M8!x_G@=(wbGC{WPiL2AY@aWdrW4Y0d_H+r*k}wVPI$C;9dcb^i!CpVWL-ro z-TKD}nqoLYdmifW8%g1l`$UN2{8xOO>eIIRBDOme7EHFWx;#kt!pYCdxJ98jv$0wk zi2LM!_(> zmzMF&dEGSv)pU}G%k5|@{)>>?u;Kh?t6Ff1h?Tw$?IVm|7O{2>2&;ZuZe;H8C(CFd zahiG7O9*Nh;SIl34EYql+>xei854hwQ_jVd)AU=G*NEE`p+%65L_2LHb(IodGb5bp zJL{aIuM6W^tA{3+T@6sewL?52gd-ecxN^{8f(-bB`m5~`lHQ`v%{GxhJ zJvq+*#$lvSzVV3=5Csf#o|=4%3ANzL(-%hMo(1EK^Qk9Ui^@)*&OjhOP8RkpL(`Q zs=rC2*2zcr*sD`P+4tBUJ(_By&&PfAHNo_GV`eOKl%F|Iu=XEch33@?g=Q^fHYrf6 zN^qq~Qk<^)x|ft6JNV2c$v9lz*l%y}TKyREs9TRK6HN)ZwQ9k-xgu~HciFE7taGtZ zp^wV{8g;@hJ-J*b1DOP&!A1G!96!voaZTd1kJyzaRJtyT-~am|vlNRl#n+*yaLSkx z{*pq81Nhyi|B`jo*`vAnOFj5yihFoKZ@gCco?|kO2?+EtB`iTEOfi~f@6^ztRKrpH z#=VJIQgR$J=L*q$z-YrYkKzR!&s&Cua^KPG!F>+)4&gE70yqK)x4@S_zqH1Zu^vHvI=|^Y$n4T_Za*nM@0UM+;sp-J8ue#_eyuF&xQ-pM&PVKfbG;sjy?K)Jzg-dAK)38}7;0+MRP= z*qSobH-*qi(L{&!-72(wcF?6OwnIT!Q~ja`K&v`=aZF!t%z%ZTMRLpZf--MOr^{F) z8vCelh*O%liEAcw7}nrRjEwG8N;_>ev3{!H`lOEdVQ!4HX#2W9(DD$Syd7=YE>~W% zKk2G0Q&J&k@5mTUh5qK4H;XjR*?-`f=MwiyOkYNM(@1$n>80*x5z13%nEM(8QoZ^b zH0pY%JerF>Af|MF25_jjJm6C*s?Gj3#@yjfy z=c*&vFL%}DCmW)#7-sy)gi>4n zdg&AUCGfcoKZZ%2=emuM%DAGy>VrYitX&wU#3R37{=2R{9eZr}Ign7rADelhg3vqC z3Bk5RKOQMcmG}He9p^us`}rxHg#YQRQy9`^K*t?6rneiOw)v@jrK-DruUo#Oh=BnFb<0*W-0JlnATiX^{zwVoq}~2Uz}VDzJfD($sr~J2 zN6rcmycb3(vQA$<;Ejq6n&t+pPR$WOt{U|2!(Bi-D@>|v=7EH974^V{2bOS{14(KV z1ax^ae>iY;)@eBEuM=r`?rm$-fzBta7^Z(rkI^Hb+ma>m4S;b&R{k@aBqc%mbW!%u z>XQ=+AIq(3oReJ0xB|+kwCSs2m+lvlW_6x+$!OI3S1+SkDpL0l`F#|7ef>P44IdBqIKlEu zQPUlxGDM9Oi>WhEIjG4J$i!Qy_w#ZgTS3M-s=NF~{io`h!dcAZ*%ZZ%D>8-&K4pP` z0=sggJ#qQ?=%_nj%T9eN!JGGoYr(bq;7jXOxzo4uqa~vyb{4M&3J77YLY(*5m3|p` zPk$+htN;0q)y)hfyCb09JWuhP<+loAhpQd*UuB``t93xMcz#KQi|oBx1}PhWW;cV-ax)|j-N&%ij}_{r&-%4zaC8oP5Km+(owP)~@2_-c zrlDsCtIqlGU-l*u&I&;C7ECaml@lq%i3~d{h+DK^g`|zOFFMl5vI5#8FzS2glnq$0CSu_rJ}YcYGLt0p<#Gbou>>BxBe5{M!r%#y4x>q%=+!AO*Vr z`q5o+Bl9xC{awU_`$*rlupu_NC-dxu*DoauYqdz8L)7$6MB{fX<$Gl91drR zg-g$aJnYV%3S5AIS}G%g+1A3BY*%sj?{^n}&K9P-duF3ok>2$Yc&(=*7d6XgbZUd! zjm#=7mCCHJ9mmZ3UpW~m71r&JS<_-l_YI7>hq(k$!+BIVg%pSzEUHL<;ixh{5yyWb8?MS4>N{o zr=`%0GdKV)UVE4iMoUrZ{rvROWUAb_&)mKX6y2RKc6veb|1Z>yB?;nw2e5=db>IKQ z+EC~XtWFaJgaE_g(JI@P)Ri&>)>G09@7)~B?WGaN<0EPM>Mp>!M`DI$2+84vZcYB0 z`TdcsaNiZ`fFF?ToRbCVAcuNQ@S&PAin0Pq6}C5*DdSDyl)v9c*|vhJK9AO`$8c5v zsH*^8GXI`kMVD^U{K~0kHkFn8%y;MB;=g&MEgz9~?^sFI{V-DNn}r|6Zn)*~akzza zQ_r2V`-=&@jwQ(ILaZ4MrS*uUeL&o(^gEA)$@plkoI zOG+ksmFzxHVbKj76cNb}V?<9=R{De8xU!tmVmx zB+Y}k2%PL$~bXE z`OB>$f)CMas^bUk`2`2l4L}9!!CDlt*vzQrB)e2LTr40t=OE5w7*+>O;1LQ7Z+c84 z$NZ;GK>Ho)8i<9w^FUs_u|a;vN9`>!#Ey*Ad2!8jjm!L*aSW5xWZiX?2H-qg_7Vmm z##m}!nX%dim~#`IQd&*`hHW+Sadvt?JLy2|Y`RC|bMNH6D}G9IuX3sYq5CmhwptG~kqOGi6{aU|{m8k+>tU=VZEvuA=bs zMDlb`QGMV-!$78ItJuY)0U#G1rYuaPSmD2QRVjg87k5&^NnhQ>TYXPEsyfnS+a}sl zI-mG|h(2`ji0*=M>20z9H1*AY0#7Uyc+!HjZ-MO0U9$X`Ik)<)VxHSdBRl+Ty873h zu-ef8@j~+;ezM%?{r9r&BZD)^*GscYnNcM=Vfnv+SR0$%2a{ym_mtNqbVyH*@?9BZ zN~yH>yk%W)UV&gBY=C`tQgG{Znwswq@u5By9~0nxl@2^n^zU-Hd*e*GN*vs-VBj{5(i;9EJ}er6!{# zIOqV`MP)J);_4=|6#>jx02H$6S6S&byvXPPNH}{#c>}e!{w==6b-Udo*w%18e>Y~r z<_T$c6+5&v?!J?r3~(((T_gd0>xWe1`q$!6ykocEwP4xW3CY?KP7C<#sbRd^aOza; zSO67!POwbV&Us6xy+lm@guEx}-8taL?X52J+U;>ATHn8EAgJ};(_iQ7rufAD`jHNG zmBg(fyi;r*6d%@@8#*_pvKOFTs1_;bfeN=3mhO8$?#r?`Y)V>7(`XIAwMA%YA|-d4 z!hFrsT%N|s3$lJth9arjMXS#%r?vNwe0+R7?}aJB+i7h)oPCJO!gv4eWMc2r#}QdP z`Adn-D8VxSb6{`oj-CDI)W7?&X7D7{cC(U=3&Pp)N~@_5NGJ6ehATq*7(SfcK=mh& zWNE}6t`fFH`D6r`-UNz%Ui{*1YSn6rfy+BTJw@qzeV14E^Pp+Js*)$i1?2WOwEig4 z)K|SF-}g-=d~&JRYaSF-Zh)`Bt%5NB(PLlB&x{L$qWW2`l@JC6VnvxY9+-(T@nOXt z^ilPdH-t(^d?hXq`klV`#*26v$4#@zjohh}E!O3#)3IUXDK&qH;o{k=1JdN?rhObsO-# z*TzCTeCVBTn|U!zHvBNmwx%Bdze}ax+>l)*B-90> zTTb{5K4QM|F1FlM{~Op+4fuszhVp>tY$xwO;`|J@0Zu7@BR2%rD!o@G0bSZ19RL&} z&p@nG)34_Xjdb_G2K)A7fmSu6GexGE&Fykyt}XD*gK+b^SH5(1tNLgF+8-AVX(gHK-Gn?`aC-KB1&f1G%+~G1-xsZg7K>R~mQa9NU4MnXXkR*g%n(pi^w+@^Z7f zQ`uz#?@n=E!MhA}^t%Y8G2==qEAi4uoKPEdmH zq>k5hP(BJoz(XnknK{=oZsuIgiLCivnqg`k{svG}yz&-9HvIuX&oQ0vuah$LP)o4y z=1~A8NT3x`uAsOn-qmS$QEySf6|qm>oRt76u9-_ykrl@z88{y%n);>7d1NJ%VnO<6hE5|Q*m+ZBoD#KM zQk8KYZx$cAfE`<7m| zz1Wt!$qv3ay2~?VjR(*o80@?@>g4hjXwG-&75Mq@Ux?E|umAfOX91mdk-)?v5AaC* zICHyr+`Vzbehp|ve1;65I(gf*KD!4|jc{hR)~Z`bpzI73>K%us1SU`$;|j7+3y^-h z)-hIxE%L5CHg62t&~=7OnB2YXLj=c45Pt1xvJ`M$WdXmMz{YQrSNH8v8HnO z6zX}^IQQWgMq^)_;~>ov7OKmIg!cXYhMbBttaLVe{qR8WasSbki!bIc@0Ud4KD0^z z5~U${s0>oXd;vFPZK#BkzZB@y|2ZXK#y@%r%Wk%?zW8k}b*3LneaLov5-?0>is&n7 zRf35W!L_H$)t(0$-(7Hk<0A4OiAlH34RlDC&(KHmx`Wl&i+TX65y?aAptnl*f9Cu* z7uhi`R2#%S&vP~b5;(j7BI7-<1s;zK`1Qkj7@YP^nP{%3wcn8HIiG+w2cxW|`pTcP_xA$<+>`pB0W1C9E2O`chb38DV4?D$GTO`jL6w zE|$>+kEB%#LK+Oi_NkSNqz2v*4Jc|YARfeb_z6n3GsJ4I1HgjvN z7X_7{j&>ak0QvigWn>uIwJk|J>UYbrJK|Il2oTKI=SCY8F5l6)g_~>DlxrKt?h~TLa$W82;|fS=O;zkRSjAYc&j;@(To!ilBcI&7M5~m&)iW z@&*#BRLIsQbovE4_O;p-aoK0aM2Sm8_tMurhu+PD>Iw}Pz&>DkS;Qpf#5tP?Hs+on z95}tDw&Ql5c_e0ddqXKt2T+LW*p=4>rh@~5u!R#}-v3L>39opkNEZLxI2{Yd)(j}K zMMJ=f?w1vT2*ARSnZIX6iW9lM@!ORlAq8~!|LW;~{N Date: Fri, 13 Aug 2021 11:08:36 -0500 Subject: [PATCH 13/16] Updated to Markdown, removed Types, simplified Licensing, added Feature Bit/Message Type/TLV to Rationale, added Status diagram. --- blips/blip-0001.md | 287 ++++++++++++++++++++++++++++++++++++++ blips/blip-0001.mediawiki | 236 ------------------------------- 2 files changed, 287 insertions(+), 236 deletions(-) create mode 100644 blips/blip-0001.md delete mode 100644 blips/blip-0001.mediawiki diff --git a/blips/blip-0001.md b/blips/blip-0001.md new file mode 100644 index 000000000..37f827a86 --- /dev/null +++ b/blips/blip-0001.md @@ -0,0 +1,287 @@ +``` +bLIP: 1 +Title: bLIP process +Status: Active +Author: Ryan Gentry +Created: 2021-05-21 +License: CC0 +``` + +# Abstract + +bLIP stands for Bitcoin Lightning Improvement Proposal. A bLIP is a design document +providing information to the Lightning community, or describing a new feature for +the Lightning Network. The bLIP should provide a concise technical specification of +the feature and a rationale for the feature. The bLIP author is responsible for +building consensus within the community and documenting dissenting opinions. + +# Copyright + +This bLIP is licensed under the CC0 license. + +# Rationale + +As the Lightning community has grown, new features, standards, and protocols have +been developed outside of the BOLT specification process: particularly at the +application level that isn’t described within the core BOLT documents. This is great! +But in the spirit of interoperability, documenting features, standards, and protocols +in a single location with a standard format will make it easy on future adopters. + +In particular, there are three scarce sets of identifiers used in Lightning Network +protocol development that benefit from central organization and documentation to +avoid potential clashes: + +* **Feature Bits** are used to designate that a given node supports a given feature, and +are publicly broadcasted on the Lightning Network. Feature Bits are first introduced as +optional with *odd* bits, and when upgraded to compulsory are switched to *even* bits, +so a new feature proposed in a bLIP should start with an *odd* bit. Feature Bits are +assigned and specified in [Bolt #9] +(https://github.com/lightningnetwork/lightning-rfc/blob/master/09-features.md). +* **Message Types** are used to indicate how to interpret the `payload` feature of a +Lightning message. Types `32768`-`65535` are set aside for experimental and +application-specific messages, which are best suited to be documented in a bLIP. +Message Types are assigned and specified in [Bolt #1] +(https://github.com/lightningnetwork/lightning-rfc/blob/master/01-messaging.md). +* **Type-Length-Values (TLVs)** are used to allow for the backwards-compatible addition +of new fields to existing message types. `type` determines how the contents of `value` +should be decoded, so specifying how to actually perform that decoding is a +great use case for a bLIP. TLVs are not assigned anywhere, but specified in [Bolt #1] +(https://github.com/lightningnetwork/lightning-rfc/blob/master/01-messaging.md). + +bLIPs will serve as the primary mechanism for proposing new features for the Lightning +Network protocol, documenting their design, and avoiding collisions of these scarce +identifiers (as some proposals may request one or more). Hopefully, they will provide +an avenue for developers to quickly get feedback on their ideas outside of the main BOLT +process. Because the bLIPs are maintained as text files in a versioned repository, +their revision history is the historical record of the feature proposal. + +It is highly recommended that a single bLIP contain a single key proposal or new idea. +More focused bLIPs will tend to be more successful. If in doubt, a bLIP should be +split into several well-focused ones. + +For Lightning developers, bLIPs are a convenient way to track the progress of their +implementation. Ideally, each implementation editor would list the bLIPs they have +implemented. This will give end users a convenient way to know the current status of +a given implementation or library. + +# bLIP Workflow + +The bLIP process begins with a new idea for Lightning. Each potential bLIP must have +a champion -- someone who writes the bLIP using the style and format described below, +shepherds the discussions in the appropriate forums, and attempts to build community +consensus around the idea. The bLIP champion (a.k.a. Author) should first attempt to +ascertain whether the idea is bLIP-able. The first step should be to search past +discussions to see if an idea has been considered before, and if so, what issues arose +in its progression. Such discussion generally happens on the [Lightning development +mailing list](https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev), or +in the #lightning-dev IRC channel. + +Once the champion has asked the Lightning community as to whether an idea has any +chance of acceptance, a draft bLIP should be presented to the [Lightning development +mailing list](https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev). This +gives the author a chance to flesh out the draft bLIP to make it properly formatted, +of high quality, and to address additional concerns about the proposal. Following a +discussion, the proposal should be submitted to the [bLIPs folder of the lightning-rfc +repository](https://github.com/lightningnetwork/lightning-rfc) as a pull request. This +draft must be written in bLIP style as described below, and its bLIP number will be +the PR number automatically assigned by Github (or, if preferred by the author, the +Issue # if there was discussion in the Issues section of this repository about this bLIP). + +When the bLIP draft is complete, the lightning-rfc editors will check the requested +Feature Bit, Message Type, and/or TLV assignments for collisions. If there are no +issues, the lightning-rfc editors will merge the pull request into the [bLIPs folder +of the lightning-rfc repository](https://github.com/lightningnetwork/lightning-rfc). +The editors will not unreasonably reject a bLIP. Reasons for rejecting bLIPs include +duplication of effort, disregard for formatting rules, being too unfocused or too +broad, being technically unsound, not providing proper motivation or addressing +backwards compatibility, or not in keeping with the Bitcoin and Lightning Network +philosophy. For a bLIP to be accepted it must meet certain minimum criteria. It +must be a clear and complete description of the proposed enhancement. The enhancement must +represent a net improvement. The proposed implementation, if applicable, must be solid +and must not complicate the protocol unduly. + +The bLIP author may update the draft as necessary in the git repository. Updates to +drafts should also be submitted by the author as pull requests. + +## Transferring bLIP Ownership + +It occasionally becomes necessary to transfer ownership of bLIPs to a new champion. In +general, we'd like to retain the original author as a co-author of the transferred bLIP, +but that's really up to the original author. A good reason to transfer ownership is +because the original author no longer has the time or interest in updating it or +following through with the bLIP process, or has fallen off the face of the 'net (i.e. is +unreachable or not responding to email). A bad reason to transfer ownership is because +you don't agree with the direction of the bLIP. We try to build consensus around a bLIP, +but if that's not possible, you can always submit a competing bLIP. + +If you are interested in assuming ownership of a bLIP, send a message asking to take over, +addressed to both the original author and the bLIP editor. If the original author doesn't +respond to email in a timely manner, the bLIP editor will make a unilateral decision (it's +not like such decisions can't be reversed). + +### bLIP Editors + +The current BOLT editors are the bLIP editors. + +### bLIP Editor Responsibilities & Workflow + +For each new bLIP submission, the editors do the following: + +* Read the bLIP to check if it is ready: sound and complete. The ideas must make technical +sense, even if they don't seem likely to get to final status. +* The title should accurately describe the content. +* The bLIP draft must have been sent to the lightning-dev mailing list for discussion. +* Motivation and backward compatibility (when applicable) must be addressed. +* Licensing terms must be acceptable for bLIPs. + +If the bLIP isn't ready, the editor will send it back to the author for revision, with +specific instructions. + +Once the bLIP is ready for the repository, the bLIP editor will: + +* Assign a bLIP number (generally the PR number or, if preferred by the author, the Issue # +if there was discussion in the Issues section of this repository about this bLIP) +* Check the requested Feature Bit, Message Type, and/or TLV assignments for collisions. +* Merge the corresponding pull request +* Send a message back to the bLIP author with the next steps. + +The bLIP editors are intended to fulfill administrative and editorial responsibilities. +They do not pass judgement on bLIPs. The bLIP editors monitor bLIP changes, and update bLIP +headers as appropriate. + +## What belongs in a successful bLIP? + +bLIPs should be written in Markdown format. + +Each bLIP should have the following parts: + +* **Preamble** -- Headers containing metadata about the bLIP (see below). +* **Abstract** -- A short (~200 word) description of the technical issue being addressed. +* **Copyright** -- The bLIP must be explicitly licensed under acceptable copyright terms (see below). +* **Specification** -- The technical specification should describe the syntax and semantics +of any new feature. The specification should be detailed enough to allow competing, +interoperable implementations for any of the current Lightning implementations. +* **Motivation** -- The motivation is critical for bLIPs that want to change the Lightning +protocol. It should clearly explain why the existing protocol is inadequate to address +the problem that the bLIP solves. +* **Rationale** -- The rationale fleshes out the specification by describing what motivated +the design and why particular design decisions were made. It should describe alternate +designs that were considered and related work. The rationale should provide evidence of +consensus within the community and discuss important objections or concerns raised +during discussion. +* **Backwards Compatibility** -- All bLIPs that introduce backwards incompatibilities must +include a section describing these incompatibilities and their severity. The bLIP must +explain how the author proposes to deal with these incompatibilities. +* **Reference Implementation** -- The reference implementation must be completed before any +bLIP is given status "Final", but it need not be completed before the bLIP is accepted. It +is better to finish the specification and rationale first and reach consensus on it before +writing code. The final implementation must include test code and documentation appropriate +for the Lightning protocol. + +### bLIP Header Preamble + +Each bLIP must begin with an RFC 822 style header preamble. The headers must appear in the +following order. Headers marked with "*" are optional and are described below. All other +headers are required. + +``` +bLIP: bLIP number, this is determined by the PR or Issue number +Title: bLIP title +Author: list of the author's or authors' name(s) and/or username(s), or name(s) and +email(s). Details are below. +* Discussions-To: a url pointing to the official discussions thread +Status: Draft, Active, Proposed, Deferred, Rejected, Withdrawn, Final, Replaced, Obsolete +Created: date created on, in ISO 8601 (yyyy-mm-dd) format +* Post-History: dates of postings to lightning-dev mailing list, or link to thread in + mailing list archive +License: abbreviation for approved license(s) +* License-Code: abbreviation for code under different approved license(s) +* Requires: bLIP number(s) +* Replaces: bLIP number +* Superseded-By: bLIP number +``` + +The Author header lists the names and email addresses of all the authors/owners of the bLIP. +The format of the Author header value must be: + +`Random J. User ` + +If there are multiple authors, each should be on a separate line following RFC 2822 +continuation line conventions. + +While a bLIP is in private discussions (usually during the initial Draft phase), a +Discussions-To header will indicate the mailing list or URL where the bLIP is being discussed. +No Discussions-To header is necessary if the bLIP is being discussed privately with the author, +or on the bitcoin email mailing lists. + +The Created header records the date that the bLIP was assigned a number, while Post-History +is used to record when new versions of the bLIP are posted to bitcoin mailing lists. Dates +should be in yyyy-mm-dd format, e.g. 2001-08-14. Post-History is permitted to be a link to a +specific thread in a mailing list archive. + +bLIPs may have a Requires header, indicating the bLIP numbers that this bLIP depends on. + +bLIPs may also have a Superseded-By header indicating that a bLIP has been rendered +obsolete by a later document; the value is the number of the bLIP that replaces the +current document. The newer bLIP must have a Replaces header containing the number of the +bLIP that it rendered obsolete. + +### bLIP status field + +The typical paths of the status of bLIPs are as follows: + +![](blip-0001/blip-0001-1.png) + +* **Draft** - The first formally tracked stage of a bLIP in development. A bLIP is merged by +a bLIP Editor into the proposals folder of the lightning-rfc repository when properly formatted. + +* **Deferred** - The bLIP editor may also change the status to Deferred when no progress is being +made on the bLIP. + +* **Withdrawn** - Champions of a bLIP may decide on their own to change the status between Draft, +Deferred, or Withdrawn. + +* **Rejected** - bLIPs should be changed from Draft status to Rejected status, upon request by any +person, if they have not made progress in three years. Such a bLIP may be changed to Draft +status if the champion provides revisions that meaningfully address public criticism of the +proposal, or to Proposed status if it meets the criteria required as described in the previous +paragraph. + +* **Proposed** - a bLIP may only change status from Draft (or Rejected) to Proposed, when the author +deems it is complete, has a working implementation (where applicable), and has community plans +to progress it to the Final status. + +* **Final / Active** - a Proposed bLIP may progress to Final only when specific criteria reflecting +real-world adoption has occurred. This is different for each bLIP depending on the nature of +its proposed changes, which will be expanded on below. Evaluation of this status change should +be objectively verifiable, and/or be discussed on the development mailing list. A bLIP may change +status from Draft to Active when it achieves rough consensus on the mailing list. Such a proposal +is said to have rough consensus if it has been open to discussion on the development mailing list +for at least one month, and no person maintains any unaddressed substantiated objections to it. +Addressed or obstructive objections may be ignored/overruled by general agreement that they have +been sufficiently addressed, but clear reasoning must be given in such circumstances. + +* **Replaced or Obsolete** - when a Final bLIP is no longer relevant, its status may be changed to +Replaced or Obsolete (which is equivalent to Replaced). This change must also be objectively +verifiable and/or discussed. + +### Auxiliary Files + +bLIPs may include auxiliary files such as diagrams. Auxiliary files should be included in a +subdirectory for that bLIP, or must be named bLIP-XXXX-Y.ext, where "XXXX" is the bLIP number, +"Y" is a serial number (starting at 1), and "ext" is replaced by the actual file extension +(e.g. "png"). + +## Licensing + +All bLIPs must be licensed under CC-BY or CC0. + +# History + +This document was derived heavily from [Bitcoin's BIP-0002] +(https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki) written by Luke Jr. which +in turn was derived from [Python's PEP-0001](https://www.python.org/dev/peps/). In many +places text was simply copied and modified. Although the PEP-0001 text was written by Barry +Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the +Bitcoin Lightning Improvement Process, and should not be bothered with technical questions +specific to the Lightning Network or the bLIP. Please direct all comments to the bLIP editors. diff --git a/blips/blip-0001.mediawiki b/blips/blip-0001.mediawiki deleted file mode 100644 index 8ef7d7a6c..000000000 --- a/blips/blip-0001.mediawiki +++ /dev/null @@ -1,236 +0,0 @@ -
-bLIP: 1
-Title: bLIP process
-Status: Active
-Type: Process
-Author: Ryan Gentry , *ideally plus one person from each client team*
-Created: 2021-05-21
-License: BSD-2-Clause, OPL
-
- -==Abstract== - -bLIP stands for Bitcoin Lightning Improvement Proposal. A bLIP is a design document providing information to the Lightning community, or describing a new feature for the Lightning Network or its processes or environment. The bLIP should provide a concise technical specification of the feature and a rationale for the feature. The bLIP author is responsible for building consensus within the community and documenting dissenting opinions. - -==Copyright== - -This bLIP is dual-licensed under the Open Publication License and BSD 2-clause license. - -==Rationale== - -As the Lightning community has grown, new features, standards, and protocols have been developed outside of the BOLT specification process: particularly at the application, forwarding, and routing level that isn’t described within the core BOLT documents. This is great! But in the spirit of interoperability, documenting features, standards, and protocols in a single location with a standard format will make it easy on future adopters. - -bLIPs will serve as the primary mechanism for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into the Lightning Network. Hopefully, they will provide an avenue for developers to quickly get feedback on their ideas outside of the main BOLT process. Because the bLIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal. - -For Lightning developers, bLIPs are a convenient way to track the progress of their implementation. Ideally, each implementation editor would list the bLIPs they have implemented. This will give end users a convenient way to know the current status of a given implementation or library. - -==bLIP Types== - -There are three kinds of bLIPs: - -* A Standards Track bLIP describes any change that affects most or all Lightning implementations, such as—a change to the network protocol, a change in HTLC types or funding transaction rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Lightning. Standards Track bLIPs consist of three parts—a design document, an implementation, and (if warranted) an update to the Basics of Lightning Technology (BOLT) specification. Furthermore, Standards Track bLIPs can be broken down into the following categories: -** Core: improvements requiring changes to the BOLTs, as well as changes that are not necessarily critical but may be relevant to “protocol dev” discussions, and routing node strategy changes. -** Routing/Pathfinding: includes improvements around the routing protocol, as well as proposed improvements to the onion routing protocol specification ([https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md BOLT #4]). -** Networking: includes improvements around the gossip protocol, as well as proposed improvements to network protocol specifications ([https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md BOLT #7]). -** Lightning Request for Comments (LRC): application-level standards and conventions. -* A Process bLIP describes a process surrounding Lightning, or proposes a change to (or an event in) a process. Process bLIPs are like Standards Track bLIPs but apply to areas other than the Lightning protocol itself. They may propose an implementation, but not to the BOLT specification; they often require community consensus; unlike Informational bLIPs, they are more than recommendations, and users are strongly encouraged to adopt them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Lightning development. Any meta-bLIP is also considered a Process bLIP. -* An Informational bLIP describes a Lightning design issue, or provides general guidelines or information to the Lightning community, but does not propose a new feature. Informational bLIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementers are free to ignore Informational bLIPs or follow their advice. - -It is highly recommended that a single bLIP contain a single key proposal or new idea. More focused bLIPs will tend to be more successful. If in doubt, a bLIP should be split into several well-focused ones. - -A change that affects multiple clients, or defines a standard for multiple apps to use, requires a bLIP, but a change to one client does not. - -==bLIP Workflow== - -The bLIP process begins with a new idea for Lightning. Each potential bLIP must have a champion -- someone who writes the bLIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The bLIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is bLIP-able. The first step should be to search past discussions to see if an idea has been considered before, and if so, what issues arose in its progression. Such discussion generally happens on the [https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev Lightning development mailing list], or in the ##lightning-dev IRC channel. - -Once the champion has asked the Lightning community as to whether an idea has any chance of acceptance, a draft bLIP should be presented to the [https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev Lightning development mailing list]. This gives the author a chance to flesh out the draft bLIP to make it properly formatted, of high quality, and to address additional concerns about the proposal. Following a discussion, the proposal should be submitted to the [https://github.com/lightningnetwork/lightning-rfc bLIP folder of the lightning-rfc repository] as a pull request. This draft must be written in bLIP style as described below, and its bLIP number will be the PR number automatically assigned by Github (or, if preferred by the author, the Issue # if there was discussion in the Issues section of this repository about this bLIP). - -When the bLIP draft is complete, the lightning-rfc editors will label it as Standards Track, Informational, or Process, and merge the pull request into the proposals folder in the lightning-rfc repository. The editors will not unreasonably reject a bLIP. Reasons for rejecting bLIPs include duplication of effort, disregard for formatting rules, being too unfocused or too broad, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Bitcoin and Lightning Network philosophy. For a bLIP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly. - -The bLIP author may update the draft as necessary in the git repository. Updates to drafts should also be submitted by the author as pull requests. - -====Transferring bLIP Ownership==== - -It occasionally becomes necessary to transfer ownership of bLIPs to a new champion. In general, we'd like to retain the original author as a co-author of the transferred bLIP, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the bLIP process, or has fallen off the face of the 'net (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the bLIP. We try to build consensus around a bLIP, but if that's not possible, you can always submit a competing bLIP. - -If you are interested in assuming ownership of a bLIP, send a message asking to take over, addressed to both the original author and the bLIP editor. If the original author doesn't respond to email in a timely manner, the bLIP editor will make a unilateral decision (it's not like such decisions can't be reversed). - -====bLIP Editors==== - -The current BOLT editors are the bLIP editors. - -====bLIP Editor Responsibilities & Workflow==== - -For each new bLIP submission, the editors do the following: - -* Read the bLIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to get to final status. -* The title should accurately describe the content. -* The bLIP draft must have been sent to the lightning-dev mailing list for discussion. -* Motivation and backward compatibility (when applicable) must be addressed. -* Licensing terms must be acceptable for bLIPs. - -If the bLIP isn't ready, the editor will send it back to the author for revision, with specific instructions. - -Once the bLIP is ready for the repository, the bLIP editor will: - -* Assign a bLIP number (generally the PR number or, if preferred by the author, the Issue # if there was discussion in the Issues section of this repository about this bLIP) -* Merge the corresponding pull request -* Send a message back to the bLIP author with the next steps. - -The bLIP editors are intended to fulfill administrative and editorial responsibilities. They do not pass judgement on bLIPs. The bLIP editors monitor bLIP changes, and update bLIP headers as appropriate. - -==What belongs in a successful bLIP?== - -bLIPs should be written in mediawiki format. - -Each bLIP should have the following parts: - -* Preamble -- Headers containing metadata about the bLIP (see below). -* Abstract -- A short (~200 word) description of the technical issue being addressed. -* Copyright -- The bLIP must be explicitly licensed under acceptable copyright terms (see below). -* Specification -- The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Lightning implementations. -* Motivation -- The motivation is critical for bLIPs that want to change the Lightning protocol. It should clearly explain why the existing protocol is inadequate to address the problem that the bLIP solves. -* Rationale -- The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work. The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion. -* Backwards compatibility -- All bLIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The bLIP must explain how the author proposes to deal with these incompatibilities. -* Reference implementation -- The reference implementation must be completed before any bLIP is given status "Final", but it need not be completed before the bLIP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code. The final implementation must include test code and documentation appropriate for the Lightning protocol. - -====bLIP Header Preamble==== - -Each bLIP must begin with an RFC 822 style header preamble. The headers must appear in the following order. Headers marked with "*" are optional and are described below. All other headers are required. - -
-bLIP: bLIP number, this is determined by the bLIP editor
-Title: bLIP title
-Author: list of the author's or authors' name(s) and/or username(s), or name(s) and email(s). Details are below.
-* Discussions-To: a url pointing to the official discussions thread
-Status: Draft, Active, Proposed, Deferred, Rejected, Withdrawn, Final, Replaced, Obsolete
-Type: Standards Track, Informational, Process
-Category: Core, Networking, Routing, Interface, or LRC (fill out for Standards Track bLIPs only)
-Created: date created on, in ISO 8601 (yyyy-mm-dd) format
-* Post-History: dates of postings to lightning-dev mailing list, or link to thread in mailing list archive
-  License: abbreviation for approved license(s)
-* License-Code: abbreviation for code under different approved license(s)
-* Requires: bLIP number(s)
-* Replaces: bLIP number
-* Superseded-By: bLIP number
-
- -The Category header (only for Standards Track bLIPs) documents which aspect of Lightning the bLIP applies to. - -The Author header lists the names and email addresses of all the authors/owners of the bLIP. The format of the Author header value must be: - - Random J. User - -If there are multiple authors, each should be on a separate line following RFC 2822 continuation line conventions. - -While a bLIP is in private discussions (usually during the initial Draft phase), a Discussions-To header will indicate the mailing list or URL where the bLIP is being discussed. No Discussions-To header is necessary if the bLIP is being discussed privately with the author, or on the bitcoin email mailing lists. - -The Type header specifies the type of bLIP: Standards Track, Informational, or Process. - -The Created header records the date that the bLIP was assigned a number, while Post-History is used to record when new versions of the bLIP are posted to bitcoin mailing lists. Dates should be in yyyy-mm-dd format, e.g. 2001-08-14. Post-History is permitted to be a link to a specific thread in a mailing list archive. - -bLIPs may have a Requires header, indicating the bLIP numbers that this bLIP depends on. - -bLIPs may also have a Superseded-By header indicating that a bLIP has been rendered obsolete by a later document; the value is the number of the bLIP that replaces the current document. The newer bLIP must have a Replaces header containing the number of the bLIP that it rendered obsolete. - -====bLIP status field==== - -The typical paths of the status of bLIPs are as follows: - -flowchart.img - -* Draft - The first formally tracked stage of a bLIP in development. A bLIP is merged by a bLIP Editor into the proposals folder of the lightning-rfc repository when properly formatted. - -* Deferred - The bLIP editor may also change the status to Deferred when no progress is being made on the bLIP. - -* Withdrawn - Champions of a bLIP may decide on their own to change the status between Draft, Deferred, or Withdrawn. - -* Rejected - bLIPs should be changed from Draft status to Rejected status, upon request by any person, if they have not made progress in three years. Such a bLIP may be changed to Draft status if the champion provides revisions that meaningfully address public criticism of the proposal, or to Proposed status if it meets the criteria required as described in the previous paragraph. - -* Proposed - a bLIP may only change status from Draft (or Rejected) to Proposed, when the author deems it is complete, has a working implementation (where applicable), and has community plans to progress it to the Final status. - -* Final / Active - a Proposed bLIP may progress to Final only when specific criteria reflecting real-world adoption has occurred. This is different for each bLIP depending on the nature of its proposed changes, which will be expanded on below. Evaluation of this status change should be objectively verifiable, and/or be discussed on the development mailing list. A process bLIP may change status from Draft to Active when it achieves rough consensus on the mailing list. Such a proposal is said to have rough consensus if it has been open to discussion on the development mailing list for at least one month, and no person maintains any unaddressed substantiated objections to it. Addressed or obstructive objections may be ignored/overruled by general agreement that they have been sufficiently addressed, but clear reasoning must be given in such circumstances. - -* Replaced or Obsolete - when a Final bLIP is no longer relevant, its status may be changed to Replaced or Obsolete (which is equivalent to Replaced). This change must also be objectively verifiable and/or discussed. - -====Auxiliary Files==== - -bLIPs may include auxiliary files such as diagrams. Auxiliary files should be included in a subdirectory for that bLIP, or must be named bLIP-XXXX-Y.ext, where "XXXX" is the bLIP number, "Y" is a serial number (starting at 1), and "ext" is replaced by the actual file extension (e.g. "png"). - -==Licensing== - -New bLIPs may be accepted with the following licenses. Each new bLIP must identify at least one acceptable license in its preamble. The License header in the preamble must be placed after the Created header. Each license must be referenced by their respective abbreviation given below. - -For example, a preamble might include the following License header: - - License: BSD-2-Clause - GNU-All-Permissive - -In this case, the bLIP text is fully licensed under both the OSI-approved BSD 2-clause license as well as the GNU All-Permissive License, and anyone may modify and redistribute the text provided they comply with the terms of *either* license. In other words, the license list is an "OR choice", not an "AND also" requirement. - -It is also possible to license source code differently from the bLIP text. An optional License-Code header is placed after the License header. Again, each license must be referenced by their respective abbreviation given below. - -For example, a preamble specifying the optional License-Code header might look like: - - License: BSD-2-Clause - GNU-All-Permissive - License-Code: GPL-2.0+ - -In this case, the code in the bLIP is not available under the BSD or All-Permissive licenses, but only under the terms of the GNU General Public License (GPL), version 2 or newer. If the code were to be available under *only* version 2 exactly, the "+" symbol should be removed from the license abbreviation. For a later version (eg, GPL 3.0), you would increase the version number (and retain or remove the "+" depending on intent). - - License-Code: GPL-2.0 # This refers to GPL v2.0 *only*, no later license versions are acceptable. - License-Code: GPL-2.0+ # This refers to GPL v2.0 *or later*. - License-Code: GPL-3.0 # This refers to GPL v3.0 *only*, no later license versions are acceptable. - License-Code: GPL-3.0+ # This refers to GPL v3.0 *or later*. - -In the event that the licensing for the text or code is too complicated to express with a simple list of alternatives, the list should instead be replaced with the single term "Complex". In all cases, details of the licensing terms must be provided in the Copyright section of the bLIP. - -bLIPs are not required to be *exclusively* licensed under approved terms, and may also be licensed under unacceptable licenses *in addition to* at least one acceptable license. In this case, only the acceptable license(s) should be listed in the License and License-Code headers. - -====Recommended licenses==== - -* BSD-2-Clause: [https://opensource.org/licenses/BSD-2-Clause OSI-approved BSD 2-clause license] -* BSD-3-Clause: [https://opensource.org/licenses/BSD-3-Clause OSI-approved BSD 3-clause license] -* CC0-1.0: [https://creativecommons.org/publicdomain/zero/1.0/ Creative Commons CC0 1.0 Universal] -* GNU-All-Permissive: [http://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html GNU All-Permissive License] - -In addition, it is recommended that literal code included in the bLIP be dual-licensed under the same license terms as the project it modifies. For example, literal code intended for a Lightning client would ideally be dual-licensed under the MIT license terms as well as one of the above with the rest of the bLIP text. - -====Not recommended, but acceptable licenses==== - -* Apache-2.0: [http://www.apache.org/licenses/LICENSE-2.0 Apache License, version 2.0] -* BSL-1.0: [http://www.boost.org/LICENSE_1_0.txt Boost Software License, version 1.0] -* CC-BY-4.0: [https://creativecommons.org/licenses/by/4.0/ Creative Commons Attribution 4.0 International] -* CC-BY-SA-4.0: [https://creativecommons.org/licenses/by-sa/4.0/ Creative Commons Attribution-ShareAlike 4.0 International] -* MIT: [https://opensource.org/licenses/MIT Expat/MIT/X11 license] -* AGPL-3.0+: [http://www.gnu.org/licenses/agpl-3.0.en.html GNU Affero General Public License (AGPL), version 3 or newer] -* FDL-1.3: [http://www.gnu.org/licenses/fdl-1.3.en.html GNU Free Documentation License, version 1.3] -* GPL-2.0+: [http://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html GNU General Public License (GPL), version 2 or newer] -* LGPL-2.1+: [http://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html GNU Lesser General Public License (LGPL), version 2.1 or newer] - -====Not acceptable licenses==== - -All licenses not explicitly included in the above lists are not acceptable terms for a Bitcoin Lightning Improvement Proposal unless a later bLIP extends this one to add them. However, bLIPs predating the acceptance of this bLIP were allowed under other terms, and should use these abbreviation when no other license is granted: - -* OPL: [http://opencontent.org/openpub/ Open Publication License, version 1.0] -* PD: Released into the public domain - -====Rationale==== - -Why is OPL insufficient? -* The OPL is generally regarded as obsolete, and not a license suitable for new publications. -Many are unfamiliar with the OPL terms, and may just prefer to use the public domain rather than license under uncertain terms. -* The OPL license terms allowed for the author to prevent publication and derived works, which was widely considered inappropriate for Bitcoin standards. -* Public domain is not universally recognised as a legitimate action, thus it is inadvisable. - -Why are there software licenses included? -* Some bLIPs may include literal code in the bLIP itself which may not be available under the exact license terms of the bLIP. -* Despite this, not all software licenses would be acceptable for content included in bLIPs. - -Why is Public Domain no longer acceptable for new bLIPs? -* In some jurisdictions, public domain is not recognised as a legitimate legal action, leaving the bLIP simply copyrighted with no redistribution or modification allowed at all. - -==History== - -This document was derived heavily from [https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki Bitcoin's BIP-0002] written by Luke Jr. which in turn was derived from [https://www.python.org/dev/peps/ Python's PEP-0001]. In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Bitcoin Lightning Improvement Process, and should not be bothered with technical questions specific to the Lightning Network or the bLIP. Please direct all comments to the bLIP editors. From bd916eb7df62e7e6ed82e5214d7dbe9d2e22810e Mon Sep 17 00:00:00 2001 From: Ryan Gentry Date: Fri, 13 Aug 2021 11:14:09 -0500 Subject: [PATCH 14/16] Updated hyperlinks and Post-History --- blips/blip-0001.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/blips/blip-0001.md b/blips/blip-0001.md index 37f827a86..d3c1ce455 100644 --- a/blips/blip-0001.md +++ b/blips/blip-0001.md @@ -4,6 +4,8 @@ Title: bLIP process Status: Active Author: Ryan Gentry Created: 2021-05-21 +Post-History: 2021-06-30: https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-June/003086.html + [lightning-dev] bLIPs: A proposal for community-driven app layer and protocol extension standardization License: CC0 ``` @@ -35,18 +37,18 @@ avoid potential clashes: are publicly broadcasted on the Lightning Network. Feature Bits are first introduced as optional with *odd* bits, and when upgraded to compulsory are switched to *even* bits, so a new feature proposed in a bLIP should start with an *odd* bit. Feature Bits are -assigned and specified in [Bolt #9] -(https://github.com/lightningnetwork/lightning-rfc/blob/master/09-features.md). +assigned and specified in [Bolt + #9](https://github.com/lightningnetwork/lightning-rfc/blob/master/09-features.md). * **Message Types** are used to indicate how to interpret the `payload` feature of a Lightning message. Types `32768`-`65535` are set aside for experimental and application-specific messages, which are best suited to be documented in a bLIP. -Message Types are assigned and specified in [Bolt #1] -(https://github.com/lightningnetwork/lightning-rfc/blob/master/01-messaging.md). +Message Types are assigned and specified in [Bolt + #1](https://github.com/lightningnetwork/lightning-rfc/blob/master/01-messaging.md). * **Type-Length-Values (TLVs)** are used to allow for the backwards-compatible addition of new fields to existing message types. `type` determines how the contents of `value` should be decoded, so specifying how to actually perform that decoding is a -great use case for a bLIP. TLVs are not assigned anywhere, but specified in [Bolt #1] -(https://github.com/lightningnetwork/lightning-rfc/blob/master/01-messaging.md). +great use case for a bLIP. TLVs are not assigned anywhere, but specified in [Bolt + #1](https://github.com/lightningnetwork/lightning-rfc/blob/master/01-messaging.md). bLIPs will serve as the primary mechanism for proposing new features for the Lightning Network protocol, documenting their design, and avoiding collisions of these scarce From 7e8d099154ab7d66f1c35a4842dabcc4e60f2dc9 Mon Sep 17 00:00:00 2001 From: Ryan Gentry Date: Fri, 13 Aug 2021 11:15:13 -0500 Subject: [PATCH 15/16] ...updated another link... --- blips/blip-0001.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/blips/blip-0001.md b/blips/blip-0001.md index d3c1ce455..999dae352 100644 --- a/blips/blip-0001.md +++ b/blips/blip-0001.md @@ -280,9 +280,9 @@ All bLIPs must be licensed under CC-BY or CC0. # History -This document was derived heavily from [Bitcoin's BIP-0002] -(https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki) written by Luke Jr. which -in turn was derived from [Python's PEP-0001](https://www.python.org/dev/peps/). In many +This document was derived heavily from [Bitcoin's + BIP-0002](https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki) written by Luke Jr. +which in turn was derived from [Python's PEP-0001](https://www.python.org/dev/peps/). In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Bitcoin Lightning Improvement Process, and should not be bothered with technical questions From f4552c1c760627e0bd8c4ff590eb33e033b0e98a Mon Sep 17 00:00:00 2001 From: Ryan Gentry Date: Tue, 31 Aug 2021 11:25:43 -0500 Subject: [PATCH 16/16] Updated with notes from 8/16 lightning-dev chat + additional comments --- blips/blip-0001.md | 55 ++++++++++++++++++++++++++++------------------ 1 file changed, 34 insertions(+), 21 deletions(-) diff --git a/blips/blip-0001.md b/blips/blip-0001.md index 999dae352..ba8def587 100644 --- a/blips/blip-0001.md +++ b/blips/blip-0001.md @@ -16,6 +16,8 @@ providing information to the Lightning community, or describing a new feature fo the Lightning Network. The bLIP should provide a concise technical specification of the feature and a rationale for the feature. The bLIP author is responsible for building consensus within the community and documenting dissenting opinions. +Importantly, if a feature is intended to become universal or near universal, it must +be a BOLT. # Copyright @@ -29,14 +31,13 @@ application level that isn’t described within the core BOLT documents. This is But in the spirit of interoperability, documenting features, standards, and protocols in a single location with a standard format will make it easy on future adopters. -In particular, there are three scarce sets of identifiers used in Lightning Network -protocol development that benefit from central organization and documentation to -avoid potential clashes: +In particular, there are (at least) three scarce sets of identifiers used in Lightning +Network protocol development that benefit from central organization and documentation +to avoid potential clashes: * **Feature Bits** are used to designate that a given node supports a given feature, and -are publicly broadcasted on the Lightning Network. Feature Bits are first introduced as -optional with *odd* bits, and when upgraded to compulsory are switched to *even* bits, -so a new feature proposed in a bLIP should start with an *odd* bit. Feature Bits are +are publicly broadcasted on the Lightning Network. Optional Feature Bits are assigned +*odd* bits, while compulsory Feature Bits are assigned *even* bits. Feature Bits are assigned and specified in [Bolt #9](https://github.com/lightningnetwork/lightning-rfc/blob/master/09-features.md). * **Message Types** are used to indicate how to interpret the `payload` feature of a @@ -45,10 +46,18 @@ application-specific messages, which are best suited to be documented in a bLIP. Message Types are assigned and specified in [Bolt #1](https://github.com/lightningnetwork/lightning-rfc/blob/master/01-messaging.md). * **Type-Length-Values (TLVs)** are used to allow for the backwards-compatible addition -of new fields to existing message types. `type` determines how the contents of `value` -should be decoded, so specifying how to actually perform that decoding is a -great use case for a bLIP. TLVs are not assigned anywhere, but specified in [Bolt - #1](https://github.com/lightningnetwork/lightning-rfc/blob/master/01-messaging.md). +of new fields to existing message types (as described in in [Bolt + #1](https://github.com/lightningnetwork/lightning-rfc/blob/master/01-messaging.md)). +bLIPs may introduce new TLV fields to existing messages, using `type`s greater than `509`. + +Potentially more scarce sets of identifiers exist (e.g. [BOLT + #4](https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md#failure-messages) +onion failure messages, [BOLT + #7](https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md#the-channel_update-message) `channel_update` `channel_flags` and `message_flags`, and [BOLT + #11](https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md#tagged-fields) +invoice tagged fields) in the Lightning Network protocol. If/when bLIPs are made that +require these identifiers, further specification of how and where to assign and allocate +them can be accomplished. bLIPs will serve as the primary mechanism for proposing new features for the Lightning Network protocol, documenting their design, and avoiding collisions of these scarce @@ -76,7 +85,10 @@ ascertain whether the idea is bLIP-able. The first step should be to search past discussions to see if an idea has been considered before, and if so, what issues arose in its progression. Such discussion generally happens on the [Lightning development mailing list](https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev), or -in the #lightning-dev IRC channel. +in the #lightning-dev IRC channel. Additionally, the champion should check the [Bitcoin +Improvement Proposal (BIP) repository](https://github.com/bitcoin/bips) and the +[Discrete Log Contract (DLC) specification](https://github.com/discreetlogcontracts/dlcspecs) +to avoid duplication of proposals. Once the champion has asked the Lightning community as to whether an idea has any chance of acceptance, a draft bLIP should be presented to the [Lightning development @@ -123,7 +135,14 @@ not like such decisions can't be reversed). ### bLIP Editors -The current BOLT editors are the bLIP editors. +The current BOLT editors are the bLIP editors, currently: + +* Bastien Teinturier (@t-bast) +* Christian Decker (@cdecker) +* Lisa Neigut (@niftynei) +* Matt Corallo (@TheBlueMatt) +* Olaoluwa Osuntokun (@roasbeef) +* Rusty Russell (@rustyrussell) ### bLIP Editor Responsibilities & Workflow @@ -160,9 +179,6 @@ Each bLIP should have the following parts: * **Preamble** -- Headers containing metadata about the bLIP (see below). * **Abstract** -- A short (~200 word) description of the technical issue being addressed. * **Copyright** -- The bLIP must be explicitly licensed under acceptable copyright terms (see below). -* **Specification** -- The technical specification should describe the syntax and semantics -of any new feature. The specification should be detailed enough to allow competing, -interoperable implementations for any of the current Lightning implementations. * **Motivation** -- The motivation is critical for bLIPs that want to change the Lightning protocol. It should clearly explain why the existing protocol is inadequate to address the problem that the bLIP solves. @@ -171,6 +187,9 @@ the design and why particular design decisions were made. It should describe alt designs that were considered and related work. The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion. +* **Specification** -- The technical specification should describe the syntax and semantics +of any new feature. The specification should be detailed enough to allow competing, +interoperable implementations for any of the current Lightning implementations. * **Backwards Compatibility** -- All bLIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The bLIP must explain how the author proposes to deal with these incompatibilities. @@ -236,23 +255,18 @@ The typical paths of the status of bLIPs are as follows: * **Draft** - The first formally tracked stage of a bLIP in development. A bLIP is merged by a bLIP Editor into the proposals folder of the lightning-rfc repository when properly formatted. - * **Deferred** - The bLIP editor may also change the status to Deferred when no progress is being made on the bLIP. - * **Withdrawn** - Champions of a bLIP may decide on their own to change the status between Draft, Deferred, or Withdrawn. - * **Rejected** - bLIPs should be changed from Draft status to Rejected status, upon request by any person, if they have not made progress in three years. Such a bLIP may be changed to Draft status if the champion provides revisions that meaningfully address public criticism of the proposal, or to Proposed status if it meets the criteria required as described in the previous paragraph. - * **Proposed** - a bLIP may only change status from Draft (or Rejected) to Proposed, when the author deems it is complete, has a working implementation (where applicable), and has community plans to progress it to the Final status. - * **Final / Active** - a Proposed bLIP may progress to Final only when specific criteria reflecting real-world adoption has occurred. This is different for each bLIP depending on the nature of its proposed changes, which will be expanded on below. Evaluation of this status change should @@ -262,7 +276,6 @@ is said to have rough consensus if it has been open to discussion on the develop for at least one month, and no person maintains any unaddressed substantiated objections to it. Addressed or obstructive objections may be ignored/overruled by general agreement that they have been sufficiently addressed, but clear reasoning must be given in such circumstances. - * **Replaced or Obsolete** - when a Final bLIP is no longer relevant, its status may be changed to Replaced or Obsolete (which is equivalent to Replaced). This change must also be objectively verifiable and/or discussed.