Update the BIP Process #2
Conversation
add clarifying note about the current opcode
murchandamus
force-pushed
the
2024-05-update-process
branch
from
bf9aa75
to
30f1b8d
Compare
murchandamus
force-pushed
the
2024-05-update-process
branch
4 times, most recently
from
180c832
to
f9017d4
Compare
murchandamus
force-pushed
the
2024-05-update-process
branch
from
52469d0
to
0dceb9c
Compare
There was a problem hiding this comment.
First (somewhat superfical) pass, didn't yet compare to BIP 2 or go deeper on the changes.
The "Changes from BIP-2" section is an excellent idea (didn't verify it yet).
Edits:
- I like the statuses simplification
- I dislike the "champions" usage, prefer "authors"
- Would be good to use one single format, e.g. BIP2 vs BIP 2 vs BIP-2, in this BIP.
bip-update-process.md
Outdated
| ## Rationale | ||
|
|
||
| [^astroturfing]: **What does it mean to be focused on Bitcoin the currency?** | ||
| Proposals to astroturf on the Bitcoin network to store data, bootstrap their own consensus mechanism, or facilitate |
There was a problem hiding this comment.
I want to get rid of that underspecified requirement. Happy to add one or multiple concrete criteria that can be evaluated more objectively.
murchandamus
force-pushed
the
2024-05-update-process
branch
from
d4cfee5
to
b3bf8a1
Compare
|
I should now have addressed all the feedback |
murchandamus
force-pushed
the
2024-05-update-process
branch
3 times, most recently
from
905571a
to
1f3e27b
Compare
|
Regarding scope, here's a different attempt:
Or a variant:
It may be worth discussing this aspect (and other "large" topics) in separate issues. |
What constitutes "in conflict" may need clarifying. |
|
Note that the top-level |
I made updates to the README to match the new process. |
murchandamus
force-pushed
the
2024-05-update-process
branch
2 times, most recently
from
2573a79
to
914b9a8
Compare
Okay, I am convinced that it’s simply the best term for the first status. Let’s go with Draft.
I don’t feel strongly about this. I would read "Active" as shorthand for "in active use"/"still relevant for the Bitcoin community" in this context. On the other hand, "Deployed" kinda sounds odd for an Informational BIP and maybe even a Process BIP. I’ll stick to Active for now.
Also ambivalent on that. "Complete" both sounds too advanced in the sense that something no longer needs changes, and orthogonal in the sense that a Draft could feature all relevant sections and comprehensively address a topic before an author is ready to recommend a proposal for deployment. I have reverted to the term used in BIP 2, and call the status now "Proposed" again. |
- Punctuation in Changes from BIP2 - minor rephrasings - clarify living document
I now only capitalize bitcoin in proper nouns. |
@real-or-random: Thanks for resurfacing that comment. I had lost track of it. I like the gist of this suggestion, but I agree with @jonatack, that "in conflict" may need to be specified further. By itself either seems too inconclusive. What do you think about combining it with the current state of that section like this:
|
|
I should now be caught up with all the review comments. Please let me know if I have overlooked something. |
|
Please excuse if I may be slow to reply, I have some travel coming up. |
Hmm, maybe "In use" would be more obvious? "Complete" would make more sense to me as the final state for a successful Informational BIP than any of "Proposed", "Ready", "Preliminary", "Active", "Deployed" or "In Use", for whatever it's worth. (I guess I think of BIP50 or BIN24-5 as the sort of thing that would be an Informational BIP in this new regime; the rest of the current BIPs marked Informational seem more like they'd be described as Specifications under this proposal)
I included the chatgpt snippet to explain why I don't think that's really the right impression to take from the phrase "complete proposal". Not sure if there's a language barrier there; maybe it would help to think of it akin to a "complete breakfast"; you could still ask for your eggs to be cooked differently, or for an entirely different meal, or decide to add hot sauce to it. But even without that, the "proposed/ready/whatever" status already says the proposal should no longer "need" changes anyway: "Subsequently, the BIP’s content should only be adjusted in minor details," so that doesn't seem that inconsistent to me? Conversely, if you know that a BIP does need changes, doesn't that already disqualify it from being "Proposed" anyway? (If you did want to say "No longer accepts changes", that would be "Status: Immutable" or "Status: Final" or similar to me, but I'm happy this is moving away from that)
If you're expecting review, then a proposal isn't complete until it's had that review, even if there don't end up being any changes as a result of the review. Could also look at is as "what do the authors (or bip editors) think the status is?" rather than some platonically objective statement: if the proposal has all the sections, but the author isn't ready to recommend it (probably a fair description of BIP118 as it stands), then the author calling it a draft even if someone else things it's complete/ready-to-be-proposed should be enough to keep it as Draft. Probably likewise if the BIP editors are of that opinion, even if the author isn't. |
| given in such circumstances. Active Process BIPs may be modified indefinitely as long as a proposed modification | ||
| has rough consensus per the same criteria.[^living-documents] | ||
|
|
||
| ##### Revisions |
There was a problem hiding this comment.
I think this should be bumped up to "###" and moved to just before the "Adoption of Proposals" heading. Possibly also name it as "Changelog" instead of "Revisions" ? (Or rename the "Changelog" section as "Revisions"?)
| __Discussion__: The Discussion header is used to point the audience to relevant discussions of the BIP, e.g. the mailing | ||
| list thread in which the idea for the BIP was discussed, a thread where a new version of the BIP was presented, or | ||
| relevant discussion threads on other platforms. Entries take the format "yyyy-mm-dd: link", e.g. | ||
| `2009-09-09: https://www.mail-archive.com/cryptography@metzdowd.com/msg10142.html`. |
There was a problem hiding this comment.
| `2009-09-09: https://www.mail-archive.com/cryptography@metzdowd.com/msg10142.html`. | |
| `2009-01-09: https://www.mail-archive.com/cryptography@metzdowd.com/msg10142.html`. |
|
|
||
| ## Motivation | ||
|
|
||
| BIP 2 is over eight years old and was written when different concerns were pressing to the bitcoin community. The BIP 2 |
There was a problem hiding this comment.
nit: I'm sure this has been discussed somewhere, but why change the spelling in BIP 2 from "Bitcoin" to "bitcoin"?
There was a problem hiding this comment.
Since this has indeed been discussed above, perhaps it's worth adding a footnote that explains the convention used in this BIP.
| them with the BIP number. | ||
| - The set of acceptable licenses was reduced to the ones previously used. | ||
|
|
||
| ### Updates to existing BIPs should this BIP be activated |
There was a problem hiding this comment.
I think it would be helpful to add a "Revision" field to the header preamble if a BIP already has a Changelog that complies with the semantic versioning inspired scheme specified in this BIP.
|
|
||
| BIPs should be written in mediawiki or markdown[^markdown] format. | ||
|
|
||
| Each BIP must have a _Preamble_, an _Abstract_, a _Copyright_, and a _Backward Compatibility_ section. Authors should |
There was a problem hiding this comment.
What's the reason for the "Backward Compatibility" section being mandatory? In many cases, BIPs propose an idea for which it is not clear what backward compatibility is supposed to mean as there's no existing way of doing things it could be meaningfully compared to. This seems to be a relic from BIP 2's focus on consensus changes.
For example, BIP 340 ("Schnorr Signatures") doesn't have a backward compatibility section. Also, it's not clear what backward compatibility means for BIP 327 ("MuSig2"), so the section ended up being quite artificial, just to meet the mandatory section requirement:
This document proposes a standard for the MuSig2 multi-signature scheme that is compatible with BIP340. MuSig2 is not compatible with ECDSA signatures traditionally used in Bitcoin.
There was a problem hiding this comment.
Was this just a mistake? @murchandamus said that he'll only keep Preamble, Abstract and Copyright after I suggested to keep just these: #2 (comment)
| __Layer__: The Layer header documents which layer of bitcoin the BIP applies to. See [BIP 123](bip-0123.mediawiki) for | ||
| definitions of the various BIP layers. | ||
|
|
||
| __Title__: A short descriptive title. Strongly preferred to be less than 50 characters long. |
There was a problem hiding this comment.
nit: Is there a reason for not just saying "Must be" instead of "Strongly preferred to be"? This would also be more consistent with the "up to 50 characters" wording in the other parts of the BIP.
| The BIPs repository serves as a publication medium and archive for mature proposals. The repository’s visibility | ||
| facilitates the distributed consideration of BIPs by providing an established source to retrieve the latest versions of | ||
| BIPs. The repository transparently records all changes to each BIP and allows any community member to easily retain a | ||
| complete copy of the archive. |
There was a problem hiding this comment.
You write "BIPs repository" but "BIP process". I suggest "BIP repository" instead.
Just some style suggestions (this sentence felt a bit clumsy), feel free to cherry-pick and ignore. Don't worry, I'll calm down with these in later sections of the draft. :P
| The BIPs repository serves as a publication medium and archive for mature proposals. The repository’s visibility | |
| facilitates the distributed consideration of BIPs by providing an established source to retrieve the latest versions of | |
| BIPs. The repository transparently records all changes to each BIP and allows any community member to easily retain a | |
| complete copy of the archive. | |
| The BIPs repository serves as a publication medium and archive for mature proposals. Through its high visibility, it | |
| facilitates community-wide consideration of BIPs and provides a well-established source to retrieve the latest version of | |
| any BIP. The repository records all changes to each BIP transparently and allows any community member to easily retain a | |
| complete copy of the archive. |
edit: I tried to be more verbose about style in the abstract than in the rest of the text, and only then I realized that this paragraph should be moved out of the abstract. Let me keep the style suggestions here nonetheless.
| The BIPs repository does not aim to track acceptance[^acceptance], adoption, or community consensus on BIPs except to | ||
| provide a quick overview of BIP statuses (see [Workflow](#workflow) below) to visitors. |
There was a problem hiding this comment.
| The BIPs repository does not aim to track acceptance[^acceptance], adoption, or community consensus on BIPs except to | |
| provide a quick overview of BIP statuses (see [Workflow](#workflow) below) to visitors. | |
| The BIPs repository is not a tool to track acceptance[^acceptance], adoption, or community consensus on BIPs, beyond | |
| providing a brief overview of BIP statuses (see [Workflow](#workflow) below). |
| This _Bitcoin Improvement Proposal (BIP)_ provides information about the preparation of BIPs and policies relating to | ||
| the publication of BIPs. It replaces BIP 2 with a streamlined process, and may be amended to address the | ||
| evolving needs of the BIP process. |
There was a problem hiding this comment.
I think this is the only paragraph that belongs in the Abstract. The other two paragraphs could be moved to a new subsection "What is the purpose of the BIPs repository?" or "What is the function of the BIPs repository?" (directly above or below "What is the scope of the BIPs repository?")
| BIP 2 is over eight years old and was written when different concerns were pressing to the bitcoin community. The BIP 2 | ||
| process seems to have been fashioned to facilitate the design and activation of protocol changes. In the past years, BIPs |
There was a problem hiding this comment.
s/The BIP 2 process/The BIP process as defined in BIP 2 thus far
| more often describe interoperable features beyond the base protocol. We have had multiple debates about the role of | ||
| BIP Editors, and some aspects of the process specified by BIP 2 that did not seem to achieve the intended goal. This |
There was a problem hiding this comment.
| more often describe interoperable features beyond the base protocol. We have had multiple debates about the role of | |
| BIP Editors, and some aspects of the process specified by BIP 2 that did not seem to achieve the intended goal. This | |
| more often describe interoperable features beyond the base protocol. There had been multiple debates about the role of | |
| BIP Editors, and some aspects of the process specified by BIP 2 that did not seem to achieve the intended goal. This |
(Who is "we"? Well, I know, my suggestion does not answer it, but I think the answer is not relevant in the end, so passive voice is appropriate here. Could also say "The community" instead if you prefer active voice.)
| BIPs that had attained Proposed status, i.e. that had been recommended for adoption, may be moved to Abandoned per | ||
| the author’s announcement to the Bitcoin Development Mailing List after not being opposed within 28 days. To successfully | ||
| oppose the move, at least one of the opposers must become the new BIP author for the BIP to remain Proposed. A BIP | ||
| can also be moved to Abandoned by the community if it has had Proposed status for at least one year, there is no | ||
| evidence of it being in active use, and its authors do not object or fail to respond, unless a new author volunteers | ||
| within four weeks. |
There was a problem hiding this comment.
| BIPs that had attained Proposed status, i.e. that had been recommended for adoption, may be moved to Abandoned per | |
| the author’s announcement to the Bitcoin Development Mailing List after not being opposed within 28 days. To successfully | |
| oppose the move, at least one of the opposers must become the new BIP author for the BIP to remain Proposed. A BIP | |
| can also be moved to Abandoned by the community if it has had Proposed status for at least one year, there is no | |
| evidence of it being in active use, and its authors do not object or fail to respond, unless a new author volunteers | |
| within four weeks. | |
| BIPs that had attained the Proposed status, i.e. that had been recommended for adoption, may be moved to Abandoned per | |
| the author’s announcement to the Bitcoin Development Mailing List after not being opposed within 28 days. To successfully | |
| oppose the move, at least one of the opposers must become the new BIP author for the BIP to remain Proposed. A BIP | |
| can also be moved to Abandoned by the community if it has had Proposed status for at least one year, there is no | |
| evidence of it being in active use, and its authors do not object or fail to respond, unless a new author volunteers | |
| within four weeks. |
28 days or 4 weeks? I know it's the same, but maybe pick one for consistency.
| If someone is interested in assuming ownership of a BIP, they should send an email asking to take over, addressed to the | ||
| original author and the BIP editors. If the author does not respond to email in a timely manner, the BIP editors will | ||
| make a unilateral decision (which may be amended should the original author make a delayed reappearance). |
There was a problem hiding this comment.
Perhaps they should send to the original author and the list? (We use the list for other announcements, so I think it makes sense to use it here too). Perhaps the original author has simply changed their email address, or someone on the list can point out how to reach the original author.
Want to specify a deadline here too?
| #### Recommended licenses | ||
|
|
||
| * BSD-2-Clause: [OSI-approved BSD 2-clause license](https://opensource.org/licenses/BSD-2-Clause) | ||
| * BSD-3-Clause: [OSI-approved BSD 3-clause license](https://opensource.org/licenses/BSD-3-Clause) | ||
| * CC0-1.0: [Creative Commons CC0 1.0 Universal](https://creativecommons.org/publicdomain/zero/1.0/) | ||
| * GNU-All-Permissive: [GNU All-Permissive License](http://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html) | ||
|
|
||
| #### Not recommended, but acceptable licenses[^licenses] | ||
|
|
||
| * CC-BY-4.0: [Creative Commons Attribution 4.0 International](https://creativecommons.org/licenses/by/4.0/) | ||
| * CC-BY-SA-4.0: [Creative Commons Attribution-ShareAlike 4.0 International](https://creativecommons.org/licenses/by-sa/4.0/) | ||
| * MIT: [Expat/MIT/X11 license](https://opensource.org/licenses/MIT) |
There was a problem hiding this comment.
I think there should be either
- no distinction between recommended and not recommended at all,
- or a rationale for why some are recommended and some are not. (A possible rationale could be that even CC-BY(-SA) can be annoying in practice, e.g., if people copy sections/tables from BIPs into source files.)
In any case, I think that the MIT is, for most purposes, virtually equivalent to BSD, and I don't see a reason to recommend one over the other, except maybe license proliferation. (But then, it's strange anyway that BIPs are often BSD but code in the ecosystem is often MIT, so you can make a point for either side...)
| original author and the BIP editors. If the author does not respond to email in a timely manner, the BIP editors will | ||
| make a unilateral decision (which may be amended should the original author make a delayed reappearance). | ||
|
|
||
| ## BIP Licensing |
There was a problem hiding this comment.
I wonder if we should also mandate a section / statement about other IP rights, if applicable. For example, I've seen this in cryptographic "competitions", e.g., CAESAR, whose goal was to find a standard for authenticated encryption:
Intellectual property: Full disclosure of all known patents, patent applications, planned patent applications, and other intellectual-property constraints relevant to use of the cipher. This section must include the following statement: "If any of this information changes, the submitter/submitters will promptly (and within at most one month) announce these changes on the crypto-competitions mailing list." Note that intellectual-property status will be taken into account in cipher evaluation; patented submissions are permitted, but submitters are advised that patenting a cipher is likely to reduce the level of interest in the cipher.
There was a problem hiding this comment.
There could be a recommendation to use the GPLv3 or one of its succedaneous. It’s a bit of burn it with fire approach for patent issues that could grieve the free usage of bitcoin standards…so I don’t know if it’s the soundest piece of advice.
I think it would be worthy to have BIP licensing discussed openly on the mailing list in a thread of its own, rather to have this issue withholding the merge of this update to the BIP process. I guess there would be many stakeholders in the bitcoin ecosystem interested to this discussion and willing to put the ressources if there is a need to improve the current license for the BIP standards, myself included.
| It is also possible to license source code differently from the BIP 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: CC0-1.0 | ||
| License-Code: MIT | ||
|
|
||
| In this case, the code in the BIP is not available under CC0-1.0, but is only available under the terms of the MIT | ||
| License. |
There was a problem hiding this comment.
I suggest adding the recommendation that any source code files (or source directories) should specify their license, as is common in software (e.g., with a license header or a LICENSE/COPYING file). This makes sense because implementations are often copied without the rest of the BIP.
I also suggest making any "test vectors" / known input tests available under CC0 or GNU All Permissive. Everyone wants to copy test vectors in their implementations, so having them under a license different than your code is very annoying.
I also suggest allowing for "License-Code" to be something like "MIT (except where stated otherwise)" for complex cases, e.g., when files are under different licenses. A good example is the test vector thing. Then at least we don't need to bother with the header.
Hm, I think some uncertainty is unavoidable and even desired. The BIP editors have the trust of the community, and need to sometimes take decisions at their discretion. But here's a variant, just a tiny bit more precise: I think "do not oppose" raises the bar for rejecting a BIP a bit, at least more than "in conflict". For example, putting a technology on top of Bitcoin (e.g., colored coins) would be an okay topic for a BIP. The same is true for OpenTimestamps. These are prime examples that we should discuss and try to evaluate the rules against. If you ask me, all of these are fine, but others have disagreed in the past (e.g., @sipa -- please correct me if I'm wrong). |
| * Layer: <Consensus (soft fork) | Consensus (hard fork) | Peer Services | API/RPC | Applications> | ||
| Title: <BIP title, up to 50 characters> | ||
| Author: <list of authors’ names and email addresses> | ||
| Status: <Draft | Proposed | Active | Abandoned> |
There was a problem hiding this comment.
ACK. With respect to the discussion about the different statuses and their naming (and at the risk of glossing over the preceding detailed discussions), ISTM that if the main goal is to simplify and reduce them, then the simplest change and easiest one to switch over to would be what you have here: keep the Draft, Proposed, and Active statuses as-is (without renaming them), and drop the five others in BIP2 (Deferred/Rejected/Withdrawn/Final/Replaced/Obsolete) in favor of Abandoned, provided the finer-grained precision of those five has not added sufficient value to keep them.
|
I don’t have standing objections on this version of the update to the BIP process and I agree with Murch answer to my comments on the ML, that nominating BIP editors could be a new BIP process, of its own. I share real-or-random’s opinion that we could think more about what BIP licensing is the most fruitful long-term for the ecosystem. Apart of the infamous CSW issue, historically there has been other licensing issues in the ecosystem, e.g the old ASICBOOST thing. Though I think we can have this discussion latter, and I don’t believe it’s a strong objection in finalizing this current update to the BIP process. |
I agree, it's reasonable to stick to the currently proposed changes to the licensing section (plus any further feedback and improvements, of course), and postpone the larger discussion about legal stuff including patents. |
|
from @jonatack's request to comment here: I would like an editor/champion field as per bitcoin#1482, clarifying the difference between authorship and helping out / point of contact for edits. |
This BIP proposes a successor to BIP-2 by defining an updated BIP process.