<p>First of all to state the obvious the BIP editors have merge permissions on the BIP repo. So ignoring the existing BIP process, for a new BIP to be added or a BIP to be changed it needs to be merged by one of the current BIP editors.</p>
<p>However, clearly we don't want the BIP editors to have effective veto power on all ideas that could get implemented in Bitcoin. Hence the <a href="https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki" rel="nofollow noreferrer">BIP 2</a> process describes what a BIP editor should do when assessing whether to allocate a proposed BIP a BIP number or not.</p>
<blockquote>
<p>For each new BIP that comes in an editor does the following:</p>
<p>Read the BIP to check if it is ready: sound and complete. The ideas
must make technical sense, even if they don't seem likely to be
accepted. The title should accurately describe the content. The BIP
draft must have been sent to the Bitcoin development mailing list for
discussion. Motivation and backward compatibility (when applicable)
must be addressed. The defined Layer header must be correctly assigned
for the given specification. Licensing terms must be acceptable for
BIPs. If the BIP isn't ready, the editor will send it back to the
author for revision, with specific instructions. Once the BIP is ready
for the repository it should be submitted as a &quot;pull request&quot; to the
BIPs git repository where it may get further feedback.</p>
<p>The BIP editor will:</p>
<p>Assign a BIP number in the pull request. Merge the pull request when
it is ready. List the BIP in README.mediawiki</p>
</blockquote>
<p>If those steps have been followed and it meets the bar set by the BIP 2 process the BIP editor should allocate a BIP number even if they themselves think it is a bad idea. Being allocated a BIP number does not mean it has been endorsed by the BIP editor merging it and it certainly doesn't necessarily mean it has been endorsed by the broader community.</p>
<p>The rationale for this is we don't want the BIP editors to be gatekeepers but we also don't want the BIPs repo filled with thousands/millions of BIPs containing ideas that have been repeatedly widely rejected by the community. As a thought experiment consider thousands of BIPs with slightly different changes to the block reward schedule or differing ways for the BIP author to seize funds from Bitcoin addresses. This work from the BIP editors allows a reasonable trade-off to be met between exploration of ideas that the BIP editors don't necessarily agree with and an effective denial of service (DoS) attack on the BIPs repo.</p>
<p>With regards to ongoing maintenance of a BIP, the BIP author (or champion) currently has pretty wide latitude to make changes to their BIP once they have been allocated a BIP number, again to avoid the BIP editors being gatekeepers over how the idea or proposal evolves. However, we also want to avoid independent readers of the BIP receiving an entirely biased, inaccurate or low quality perspective on the merits of the evolving proposal. Hence BIP 2 currently has a comments system where reviewers can submit comments to the BIP that are viewable to the readers of that BIP. The system hasn't worked particularly well, not many people have submitted high quality comments, the comments aren't particularly accessible and it has generally been quite unwieldy. There have been <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019469.html" rel="nofollow noreferrer">discussions</a> to replace the comments system with the ability for BIP editors to post links to bitcoin-dev mailing list posts with well reasoned technical criticisms of the BIP at the bottom of the BIP so readers can easily access viewpoints counter to the viewpoints of the BIP author/champion. At the time of writing though this has not been included in a BIP process update.</p>

CC BY-SA 4.0
2022-02-11T14:29:32.213Z
2022-02-12T09:44:46.867Z
2022-02-12T09:44:46.867Z
Michael Folkson
<p>Under the existing BIP process (<a href="https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki" rel="nofollow noreferrer">BIP 2</a>) what ability do the BIP editors have to prevent bad ideas being BIPed and/or BIPs becoming especially low quality or biased?</p>

<bip>
Under the existing BIP process what ability do the BIP editors have to prevent bad ideas being BIPed and/or low quality BIPs?
Michael Folkson
# Under the existing BIP process what ability do the BIP editors have to prevent bad ideas being BIPed and/or low quality BIPs?

(Asked by: username_0 on 2022-02-11)

Under the existing BIP process ([BIP 2](https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki)) what ability do the BIP editors have to prevent bad ideas being BIPed and/or BIPs becoming especially low quality or biased?

**Tags:** bip


---

## 1 answers

### Answer by username_0 on 2022-02-11. Score: 1 | Accepted answer

First of all to state the obvious the BIP editors have merge permissions on the BIP repo. So ignoring the existing BIP process, for a new BIP to be added or a BIP to be changed it needs to be merged by one of the current BIP editors.

However, clearly we don't want the BIP editors to have effective veto power on all ideas that could get implemented in Bitcoin. Hence the [BIP 2](https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki) process describes what a BIP editor should do when assessing whether to allocate a proposed BIP a BIP number or not.

> For each new BIP that comes in an editor does the following:
>
> Read the BIP to check if it is ready: sound and complete. The ideas
> must make technical sense, even if they don't seem likely to be
> accepted. The title should accurately describe the content. The BIP
> draft must have been sent to the Bitcoin development mailing list for
> discussion. Motivation and backward compatibility (when applicable)
> must be addressed. The defined Layer header must be correctly assigned
> for the given specification. Licensing terms must be acceptable for
> BIPs. If the BIP isn't ready, the editor will send it back to the
> author for revision, with specific instructions. Once the BIP is ready
> for the repository it should be submitted as a "pull request" to the
> BIPs git repository where it may get further feedback.
>
> The BIP editor will:
>
> Assign a BIP number in the pull request. Merge the pull request when
> it is ready. List the BIP in README.mediawiki

If those steps have been followed and it meets the bar set by the BIP 2 process the BIP editor should allocate a BIP number even if they themselves think it is a bad idea. Being allocated a BIP number does not mean it has been endorsed by the BIP editor merging it and it certainly doesn't necessarily mean it has been endorsed by the broader community.

The rationale for this is we don't want the BIP editors to be gatekeepers but we also don't want the BIPs repo filled with thousands/millions of BIPs containing ideas that have been repeatedly widely rejected by the community. As a thought experiment consider thousands of BIPs with slightly different changes to the block reward schedule or differing ways for the BIP author to seize funds from Bitcoin addresses. This work from the BIP editors allows a reasonable trade-off to be met between exploration of ideas that the BIP editors don't necessarily agree with and an effective denial of service (DoS) attack on the BIPs repo.

With regards to ongoing maintenance of a BIP, the BIP author (or champion) currently has pretty wide latitude to make changes to their BIP once they have been allocated a BIP number, again to avoid the BIP editors being gatekeepers over how the idea or proposal evolves. However, we also want to avoid independent readers of the BIP receiving an entirely biased, inaccurate or low quality perspective on the merits of the evolving proposal. Hence BIP 2 currently has a comments system where reviewers can submit comments to the BIP that are viewable to the readers of that BIP. The system hasn't worked particularly well, not many people have submitted high quality comments, the comments aren't particularly accessible and it has generally been quite unwieldy. There have been [discussions](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019469.html) to replace the comments system with the ability for BIP editors to post links to bitcoin-dev mailing list posts with well reasoned technical criticisms of the BIP at the bottom of the BIP so readers can easily access viewpoints counter to the viewpoints of the BIP author/champion. At the time of writing though this has not been included in a BIP process update.


---

