Delivery-date: Tue, 02 Apr 2024 06:57:56 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of crypto@timruffing.de designates 2001:67c:2050:0:465::102 as permitted sender) client-ip=2001:67c:2050:0:465::102;
Message-ID: <59fa94cea6f70e02b1ce0da07ae230670730171c.camel@timruffing.de>
Subject: [bitcoindev] Time for an update to BIP2?
From: Tim Ruffing <crypto@timruffing.de>
To: Matt Corallo <lf-lists@mattcorallo.com>, Brandon Black
	 <freedom@reardencode.com>
Cc: Murch <murch@murch.one>, bitcoindev@googlegroups.com
Date: Tue, 02 Apr 2024 15:17:40 +0200
In-Reply-To: <9ebd08b0-7680-4896-aad3-1c225b764bcb@mattcorallo.com>
References: <2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com>
	 <e4048607-64b7-4772-b74e-4566a4b50bc0n@googlegroups.com>
	 <9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org>
	 <42e6c1d1d39d811e2fe7c4c5ce6e09c705bd3dbb.camel@timruffing.de>
	 <d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com>
	 <52a0d792-d99f-4360-ba34-0b12de183fef@murch.one>
	 <f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com>
	 <ZgWRu32FXzqqg69V@console>
	 <9ebd08b0-7680-4896-aad3-1c225b764bcb@mattcorallo.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

(Changing the subject line as this is mostly orthogonal to adding BIP
editors.)

On Thu, 2024-03-28 at 16:04 -0400, Matt Corallo wrote:
> BIP editors=20
> are not responsible for opining on the merit of a proposal. Their job
> is to assign numbers and=20
> occasionally suggest copy edits to ensure the documents are of high
> quality and readability.

As I said my previous email, this is what I'd prefer, but the current
BIP2, Section "BIP workflow" says this:

"The BIP editors will not unreasonably reject a BIP. Reasons for
rejecting BIPs 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 philosophy. For a BIP 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."

This is a lot of criteria for a simple editorial rule, hm? How could
any editor judge if an enhancement represents a net improvement without
opining on its merit? What's the Bitcoin philosophy?=20


By the way, Section "BIP Editor Responsibilities & Workflow" says this:

"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.=C2=A0
- [...]"

Note how this is is (seemingly?) in conflict with the paragraph cited
further above. What is "acceptance"? Acceptance by the editor, by the
community (whoever that is), or by anyone else?

BIP2 has other problems (a lot of which date back to BIP1):
 * It recommends licensing BIPs under BSD-2 or BSD-3, which are
   software licenses. It's not even clear if they're applicable to
   plain text. (The CC0 recommendation makes much more sense.)
 * The Comments-URI thing is outdated and everyone seems to ignore it.
   Comments-Summary is even weirder.
 * "Informational BIPs do not necessarily represent a Bitcoin community
   consensus or recommendation". Aha, does this imply that Standards
   Track BIPs need to represent a Bitcoin community consensus or
   recommendation?
 * Ever tried to write pseudocode or LaTeX in mediawiki format? It's
   more than annoying, believe me.

Moreover, the entire "BIP status field" section is an attempt at
formalizing and describing the process of changing Bitcoin. That leads
to statements like these that specify when a BIP should be "Final"=20

 * "A soft-fork BIP strictly requires a clear miner majority expressed
   by blockchain voting (eg, using BIP 9)." That statement is highly
   controversial. The point is that it simply doesn't belong in BIP2.
 * "API/RPC and application layer BIPs must be implemented by at least
   two independent and compatible software applications." same here
 * Peer services BIPs should be observed to be adopted by at least 1%
   of public listening nodes for one month. =C2=A0

The problems are similar to the Comments-Summary field whose purpose is
to represent a community judgment of the BIP. It can have these values:
 * No comments yet.
 * Unanimously Recommended for implementation
 * Unanimously Discourage for implementation
 * Mostly Recommended for implementation, with some Discouragement
 * Mostly Discouraged for implementation, with some Recommendation

There's a reason why noone really uses this. Like the Status field, it
requires that someone (the editor? BIP2 doesn't specify this) makes a
judgement that looks somewhat authoritative, because it will end up in
the BIP header/metadata.=20

I think we should simply drop anything that requires an examination of
the meat of the BIP, e.g., the Status and Comments-* fields, and the
requirement to check the meat of a BIP. Instead, we should work on a
new process BIP that merely describes a simple process of publishing
BIPs, in which the editors focus on purely formal and editorial issues
(e.g., formatting, license, readability, filtering spam, ...). It's
great when they guide BIP authors by providing feedback on the
presentation of an idea, or even on the idea itself, but they shouldn't
be required to make decisions based on the technical or philosophical
merit of a BIP.

I ask everyone to read BIP2 carefully before replying here:
https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki

Best,
Tim

--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/=
bitcoindev/59fa94cea6f70e02b1ce0da07ae230670730171c.camel%40timruffing.de.