From: Pieter Wuille <bitcoin-dev@wuille•net>
To: Tim Ruffing <crypto@timruffing•de>
Cc: Matt Corallo <lf-lists@mattcorallo•com>,
Brandon Black <freedom@reardencode•com>, Murch <murch@murch•one>,
bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Time for an update to BIP2?
Date: Wed, 03 Apr 2024 19:44:00 +0000 [thread overview]
Message-ID: <4pVUOTuyyAbTJB_rTGNWS_TuR39NS5OoJvaSCyqjezAg265kPnCjXvqohFmWQ5ITb7XFZCJie-uV1AG3pVCI5H54dDuFP4OyomC9yiWDot0=@wuille.net> (raw)
In-Reply-To: <59fa94cea6f70e02b1ce0da07ae230670730171c.camel@timruffing.de>
[-- Attachment #1: Type: text/plain, Size: 10958 bytes --]
Thank you for splitting off this discussion. I believe that lots of commentators who see problems with the BIPs process fail to distinguish between the editor being overloaded, and unclarity or disagreement about what the editor's job is supposed to be in the first place.
In particular, I've seen some comments akin to "assigning numbers shouldn't take that much work", while the BIP2 sections you highlight do show that the process does involve a lot more than that. Discussion about what the process is supposed to be should be separate from a discussion about who will facilitate that process.
More comments inline below.
>
On Tuesday, April 2nd, 2024 at 9:17 AM, Tim Ruffing crypto@timruffing•de wrote:
> 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?
Good point, this does seem to imply some value judgements. If we're open to making changes to what the criteria for a BIP are supposed to be, I think it ought to include:
- Formatting: contains necessary sections/headers, license, ...
- Editorial qualities: proper English, organized, ...
- Discussion: must have been presented on the ML or other common fora, received interest/discussion, ...
- Need for standardization: not every idea is worth publishing; if it isn't likely to affect multiple projects/pieces of software, it can just be software documentation instead.
- Scope: related to technology that supports the bitcoin currency.
This last one may be controversial, but I feel that some of the discussion the past months about the process has shown that there is unclarity/disagreement here, and it would be good to have some guideline written out here. I think scope will inevitably be somewhat of a grey zone, but I feel some limits (whether spelled out or not) will exist regardless (nobody would consider including the HTTP spec in scope for a BIP, I think?). One suggestion I have seen (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022072.html) is limiting to "extremely widespread standards used by the entire Bitcoin community", but I feel that suffers from a "no true Scotsman" fallacy (who gets to define what the "Bitcoin community" is, in a technology that to me seems designed for distrusting parties?), but would also under reasonable interpretations exclude several very useful BIPs today (some wallet standards are useful for some software and not others) and likely contribute to process friction (where do they move to?). I don't think that's a desirable situation.
I also don't think scope should be tied to specific technologies (e.g. it shouldn't just be about on-chain transactions, as e.g. that would exclude address formats), but if not that, what scoping is useful? And to me, restricting to technology that supports the bitcoin currency is fairly clear, reasonable, and avoids a circular definition. As an example, that would exclude OpenTimestamps from scope (which was suggested in https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022077.html). I see that as an unrelated application which happens to make use of the Bitcoin blockchain, which on itself is one of the technologies that supports bitcoin - but is an indirection too far to be in scope.
Note that however none of the criteria I list above are quality assessments; I think it is essential that BIP editors can accept BIPs they themselves find abhorrent. People can strongly disagree about whether a proposed standard is a good idea, or even whether it falls within the "Bitcoin philosophy", without disagreeing whether it is at all related to bitcoin (the currency).
> 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?
I don't see a problem here; my interpretation is that this is exactly about excluding certain value judgements from what the editor is supposed to do: they must judge soundness and completeness, without trying to guess whether the community is likely to accept the idea. "sound and complete" is perhaps too vague as a criterion, but I'm in support of explicitly excluding guessing of acceptance.
> 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.)
No strong opinion about this, but that sounds reasonable.
> * The Comments-URI thing is outdated and everyone seems to ignore it.
>
> Comments-Summary is even weirder.
Agreed. It's unused, and sometimes misinterpreted. I think we should get rid of it.
> * "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?
Indeed. I don't think BIPs should be representing community consensus or recommendations. But perhaps they can document individual pieces of evidence of acceptance; see further?
> * Ever tried to write pseudocode or LaTeX in mediawiki format? It's
>
> more than annoying, believe me.
I'd like permitting BIPs to be written in markdown.
> 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.
Some forms of Status are useful I think, but they ought to reflect the author's intent, not the community's perception. E.g. "Draft", "Proposed", and "Withdrawn" make sense to me for any kind of standard. In Draft stage more substantial changes could be permitted, but would convey the idea isn't yet intended for adoption. Of course, the BIP1 status fields weren't really used, and the BIP2 status fields don't seem to be doing much better. If we assume that BIP3 status fields aren't going to be used either this is all for nought, but perhaps it's still worth trying with a significantly simplified assortment of statuses.
Things like "Active / Final" and "Rejected" relate to community acceptance, and I agree those don't belong in BIPs. Instead, could we perhaps have a field that indicates objective evidence of acceptance, such as listing which software projects have implemented/adopted it?
As far as judging consensus goes, perhaps actual consensus changes are an exception? I feel that for those, an "Accepted" status may actually make sense, because they actually require the ecosystem to have agreement about. But even then, it could be restricted to be an after-the-fact piece of evidence (whatever its activation rules are, they are met), rather than a judgement of community perception.
Regarding the "at least two independent and compatible software applications", I don't think this is a bad principle: good standards should be implementable by many, and having multiple implementations is an objective way of assessing that. I'm not sure that means being a requirement for its status, but at least an intent to have multiple implementations is a useful condition for the "Need for standardization" rule I suggest above.
> 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.
Agreed.
> 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 think my view is somewhat more restrictive than yours, e.g. that BIPs ought to satisfy some scope and need for standardization criteria, but I agree that as written in BIP2 today, Editors have too many judgement calls to make.
--
Pieter
--
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/4pVUOTuyyAbTJB_rTGNWS_TuR39NS5OoJvaSCyqjezAg265kPnCjXvqohFmWQ5ITb7XFZCJie-uV1AG3pVCI5H54dDuFP4OyomC9yiWDot0%3D%40wuille.net.
[-- Attachment #2: Type: text/html, Size: 13297 bytes --]
next prev parent reply other threads:[~2024-04-03 20:08 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 ` [bitcoindev] Time for an update to BIP2? Tim Ruffing
2024-04-03 19:44 ` Pieter Wuille [this message]
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='4pVUOTuyyAbTJB_rTGNWS_TuR39NS5OoJvaSCyqjezAg265kPnCjXvqohFmWQ5ITb7XFZCJie-uV1AG3pVCI5H54dDuFP4OyomC9yiWDot0=@wuille.net' \
--to=bitcoin-dev@wuille$(echo .)net \
--cc=bitcoindev@googlegroups.com \
--cc=crypto@timruffing$(echo .)de \
--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