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
Subject: [bitcoindev] Time for an update to BIP2?
Date: Tue, 02 Apr 2024 15:17:40 +0200 [thread overview]
Message-ID: <59fa94cea6f70e02b1ce0da07ae230670730171c.camel@timruffing.de> (raw)
In-Reply-To: <9ebd08b0-7680-4896-aad3-1c225b764bcb@mattcorallo.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
> are not responsible for opining on the merit of a proposal. Their job
> is to assign numbers and
> 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?
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.
- [...]"
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"
* "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.
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.
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
--
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 email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/59fa94cea6f70e02b1ce0da07ae230670730171c.camel%40timruffing.de.
next prev parent reply other threads:[~2024-04-02 13:57 UTC|newest]
Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-27 18:53 [bitcoindev] Adding New BIP Editors 'Ava Chow' via Bitcoin Development Mailing List
2024-02-27 20:11 ` [bitcoindev] " 'Léo Haf' via Bitcoin Development Mailing List
2024-02-27 22:40 ` Luke Dashjr
2024-02-27 22:57 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-02-27 23:26 ` Steve Lee
2024-02-28 11:12 ` bitcoin-dev-ml.void867 via Bitcoin Development Mailing List
2024-02-28 16:31 ` Tim Ruffing
2024-03-07 20:56 ` Antoine Riard
2024-03-14 11:56 ` Chris Stewart
2024-03-27 21:25 ` Murch
2024-03-27 23:36 ` Keagan McClelland
2024-03-27 23:39 ` John C. Vernaleo
2024-03-28 13:02 ` Murch
2024-03-28 16:09 ` /dev /fd0
2024-03-28 20:04 ` Matt Corallo
2024-03-28 20:31 ` Antoine Riard
2024-03-28 20:59 ` John C. Vernaleo
2024-03-28 21:19 ` Matt Corallo
2024-03-29 2:34 ` Michael Folkson
2024-03-29 5:24 ` /dev /fd0
2024-03-29 21:08 ` Antoine Riard
2024-03-30 11:51 ` Michael Folkson
2024-03-30 20:01 ` Antoine Riard
2024-03-31 16:01 ` Michael Folkson
2024-04-01 20:14 ` Antoine Riard
2024-04-07 10:11 ` Ali Sherief
2024-04-01 21:13 ` David A. Harding
2024-04-01 23:55 ` /dev /fd0
2024-04-02 0:37 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-02 13:49 ` /dev /fd0
2024-04-02 14:28 ` Luke Dashjr
2024-04-02 15:13 ` Gloria Zhao
2024-04-02 15:39 ` Luke Dashjr
2024-04-03 15:03 ` Murch
2024-04-02 8:18 ` Michael Folkson
2024-04-02 14:24 ` nvk
2024-04-11 14:22 ` Sergi Delgado Segura
2024-04-15 17:50 ` Matt Corallo
2024-04-16 12:34 ` Tim Ruffing
2024-04-16 13:32 ` NVK
2024-04-16 17:08 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-17 23:58 ` 'nsvrn' via Bitcoin Development Mailing List
2024-04-19 22:32 ` Olaoluwa Osuntokun
2024-04-20 19:14 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-20 19:48 ` NVK
2024-04-20 19:59 ` Michael Folkson
2024-04-20 20:59 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-20 20:46 ` Steve Lee
2024-04-20 21:08 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-20 21:11 ` Steve Lee
2024-04-20 21:37 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-20 22:03 ` Steve Lee
2024-04-20 22:47 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-22 2:44 ` Steve Lee
2024-04-20 22:21 ` Michael Folkson
2024-04-20 23:05 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-21 11:43 ` Michael Folkson
2024-04-21 16:39 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-21 17:57 ` Michael Folkson
2024-04-21 18:47 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-21 19:18 ` Michael Folkson
2024-04-21 20:48 ` Antoine Riard
2024-04-21 23:01 ` Matt Corallo
2024-04-22 0:06 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-22 4:28 ` Ali Sherief
2024-04-23 22:15 ` Anthony Towns
2024-04-25 6:42 ` Antoine Riard
2024-03-29 22:17 ` Keagan McClelland
2024-03-30 4:04 ` Peter Todd
2024-04-01 18:42 ` Jonas Nick
2024-03-27 23:54 ` Matt Corallo
2024-03-28 15:50 ` Brandon Black
2024-03-28 19:42 ` Antoine Riard
2024-03-28 20:04 ` Matt Corallo
2024-04-02 13:17 ` Tim Ruffing [this message]
2024-04-03 19:44 ` [bitcoindev] Time for an update to BIP2? Pieter Wuille
2024-04-04 5:00 ` Anthony Towns
2024-04-04 9:09 ` Niklas Goegge
2024-04-04 12:58 ` [bitcoindev] Adding New BIP Editors 0xB10C
2024-05-13 18:33 ` [bitcoindev] Time for an update to BIP2? Murch
2024-04-01 18:41 ` [bitcoindev] Re: Adding New BIP Editors Murch
2024-03-31 17:01 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-01 6:21 ` /dev /fd0
2024-04-01 11:58 ` Michael Folkson
2024-04-03 16:58 ` Juan Galt
2024-04-03 17:24 ` Vasil Dimov
2024-04-03 18:34 ` 'Fabian' via Bitcoin Development Mailing List
2024-03-07 22:39 ` Keagan McClelland
2024-02-27 21:33 ` [bitcoindev] " 'Antoine Poinsot' via Bitcoin Development Mailing List
2024-02-27 21:48 ` Greg Tonoski
2024-02-27 23:10 ` [bitcoindev] " /dev /fd0
2024-02-28 4:22 ` /dev /fd0
2024-03-09 10:46 ` Michael Folkson
2024-03-10 17:27 ` Bitcoin Error Log
2024-03-11 16:48 ` Jon A
2024-04-05 19:18 ` Larry Ruane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=59fa94cea6f70e02b1ce0da07ae230670730171c.camel@timruffing.de \
--to=crypto@timruffing$(echo .)de \
--cc=bitcoindev@googlegroups.com \
--cc=freedom@reardencode$(echo .)com \
--cc=lf-lists@mattcorallo$(echo .)com \
--cc=murch@murch$(echo .)one \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox