path: root/c0/a4c028133606c701870fb06e7d46aab087999f

Delivery-date: Wed, 03 Apr 2024 13:08:53 -0700
Received: from mail-qt1-f186.google.com ([209.85.160.186])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBAABBTHOW2YAMGQEOEUP4FQ@googlegroups.com>)
	id 1rs6ui-0006Cj-2K
	for bitcoindev@gnusha.org; Wed, 03 Apr 2024 13:08:53 -0700
Received: by mail-qt1-f186.google.com with SMTP id d75a77b69052e-427b56e96a6sf2415691cf.3
        for <bitcoindev@gnusha.org>; Wed, 03 Apr 2024 13:08:51 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1712174926; cv=pass;
        d=google.com; s=arc-20160816;
        b=Yla3UqOGux1kDItLnt9y8JA943TYrGnehFX5GnWQ8Rg1t4YKMkEJ3NYq4vrMsoeIMA
         IhLO39i8m0dO0mlW9ciTLc1eZz02PS1YT/Tr8laA4UaDQOOhFGP+6YBtz03fVHlG9w8M
         rMM6nt43lOtnWa8VpAjlD7v6e6J7Z3Wugt9kMKgt+M9yVQmetQyHulWjRSNjMgcZ4uSU
         cf8uYiMsDY7r1KXYgWvWPdQLa/99M/2xzR5/5F5dn0QeipCAkzkoDLi/kv09Iom/PX9O
         EkrFsgihTDef0C46/KGcd3oqZBhuZo9+p8v2ysqZLDLdxy1cHwqoaArvmApl6eoi+l3a
         9LEA==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:mime-version:feedback-id:references
         :in-reply-to:message-id:subject:cc:from:to:date:sender
         :dkim-signature;
        bh=LZt14QxUaHhfYragV1Wznmht6UPNTjBrlSrr3retTGk=;
        fh=i/Q223aUbB0Z2XS8slS0YoIjU1RfveGi/wShoh4wf9s=;
        b=RG9JPgB4+WBnKIGSvrZgQWFSvC3MxQyFvhd5vLjRpjKMT7UZajTJlh9LxY8Sqiyn04
         cPK6yBFI7jm8R5UhwNnx2WGodW1hZidv3ar4HdvG/BjFRsbkbP6egbrjnUI4gPW0Ca90
         fYBcMDOZ3DSbnPt4B5OcHIFyTrp30gp+ku+jR+2OJN7zOq0pIahMnRMmBZ9Gb08hxgFI
         V6x1BuQYyiX1nAFtM+CK1XP1fbs9eD4Zz3T6SXhpYJ0zX04+l6Dh4BlAmDeQQTa8/MqU
         FwhiaK5shRLShNpMasRLwnhmwzkVCoUBhNcjbLftZK3EoofHlxhAft1Brx/D2yqPlNKm
         SBmw==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@wuille.net header.s=protonmail3 header.b=rDGB8cSX;
       spf=pass (google.com: domain of bitcoin-dev@wuille.net designates 185.70.43.23 as permitted sender) smtp.mailfrom=bitcoin-dev@wuille.net;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=wuille.net
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1712174926; x=1712779726; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:mime-version:feedback-id:references:in-reply-to
         :message-id:subject:cc:from:to:date:sender:from:to:cc:subject:date
         :message-id:reply-to;
        bh=LZt14QxUaHhfYragV1Wznmht6UPNTjBrlSrr3retTGk=;
        b=Dvb6ihg+oja8DZGtiyAVYMmnGs+b8jhNdhPYJnIsWSA+szB5K2+4WClb8FIovVKZYx
         OI/rE7wmS7O1M3ov6h4tkv946DnIsq29k/en8GWL/jHuj7fhXI8nHt4ch3wRiYxO6rOu
         Fwl2hbM9FyyYJ4NfLAAiYAujzmVsjzlGa4lJ+dL873sXWm/SKLZLotlQxT+fatNCzG0W
         hjiHU283VBCEGYsnthQ8yPzHuqoqgFwPTiBsJws9LLcU/QuIOqtnw/ZJuWaTYJOkInkI
         Tx4UmUB2Lhk8ltY+igPetAyWVXYITRdjHNnL/DgHaUVLycyoJVzIv1dUHxa8iW4cGBrU
         HgOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1712174926; x=1712779726;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:mime-version:feedback-id:references:in-reply-to
         :message-id:subject:cc:from:to:date:x-beenthere:x-gm-message-state
         :sender:from:to:cc:subject:date:message-id:reply-to;
        bh=LZt14QxUaHhfYragV1Wznmht6UPNTjBrlSrr3retTGk=;
        b=IGHoP4y2QF+XjrToFF/VTRXoYfN+N6/+6m3Lvj1deeKArmgSx8NXtHBv0OuCNqlcUx
         Yi0w6rOzwkXU4DTn/nwYMq/Kd6gc1EYYmA2AJCMCeHzwaF+59a8EjB9UZqOPgFFgOrer
         84IfisuWbDPMN1IyFMk65FztYYkNrJhKwvHOtv6U9nWEYulp01J/q4vOTzLEdbz+ol5q
         uVha8t4wjedwH4mSTaJ3+LyhhqbV+7ZmYMGzBSNruhPZFyWVWOpJKrhMPuzdC5C2F8Np
         5bAI33MA8i2jbryN1r7dDXJQ1wCdff0H0ygrniUhEwV7CNI9JVYmUEsIwLQvygm5MMdA
         chrA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCUsmIP41RUjyBRa7fQ4K2Fj72ym7156gPDjGXJOxmAN+d5RClz+m9jNYIMTyJdxKunlsPBg4V6GNpVE1g/z1KNJ4ptS3aM=
X-Gm-Message-State: AOJu0YzgPunUZ5JTF6eZ2ouU+yUHPS5RJKNSnjQdmAbrrCW+S+17yFb3
	ionrKBuj5E+Wmh1KPEaaYectM0ynLk5Ep9NH95/hHA36MCgkxKqD
X-Google-Smtp-Source: AGHT+IEyvjCuVkOlcHhNzDszSlxkvTFxBW7Fv4dtWy0O+8eJorJX9jIdEY6wHdwUOzMy/WbszDeHgg==
X-Received: by 2002:a05:622a:1817:b0:431:3da3:ec92 with SMTP id t23-20020a05622a181700b004313da3ec92mr473891qtc.11.1712174925316;
        Wed, 03 Apr 2024 13:08:45 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a05:622a:1a1f:b0:434:4c30:f0eb with SMTP id
 f31-20020a05622a1a1f00b004344c30f0ebls388569qtb.1.-pod-prod-07-us; Wed, 03
 Apr 2024 13:08:44 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCXpT2brtEfISrhGtOWNTUObckcjXb46LyS8JdYWwIxdjVinmgKwkSdb7FjAnuG0kcGnYxR8hgeVgZW2sC/gto6wozE4b8i6OIu00NM=
X-Received: by 2002:ac8:7d41:0:b0:431:80cc:a3b1 with SMTP id h1-20020ac87d41000000b0043180cca3b1mr1416qtb.11.1712174923864;
        Wed, 03 Apr 2024 13:08:43 -0700 (PDT)
Received: by 2002:a05:620a:470b:b0:78b:c6cb:86d4 with SMTP id af79cd13be357-78d3f22ea60ms85a;
        Wed, 3 Apr 2024 12:44:11 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCUSb4qgUXV/VA2e8lHpE3DeWqwieArw8pH3j/UtD9NGGZL2IOmDvAGYvayj+2iVLFumqqoeX47ZoG1TJGmb8nXY/D/qoEs1Rm+AP2I=
X-Received: by 2002:a05:6512:21a7:b0:516:afb5:6a71 with SMTP id c7-20020a05651221a700b00516afb56a71mr274617lft.67.1712173449962;
        Wed, 03 Apr 2024 12:44:09 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1712173449; cv=none;
        d=google.com; s=arc-20160816;
        b=ce7uguPaeSyfVLPRtsn8yf91TMdSIZ24UrWekQ+UNTT5eAq6b4TbbT18vL+BxrPfw+
         OVxPTFtiljtiEm0Y76/qal7HzC3OM6prEs07IG06TA/dE+E/jFKD5BsbVaNvn9xRpkdn
         Fzev22eh90K82q7s3CgpS3wWmT9QMaq27u/Cp5nxKQxlfa+j5MO2aaKqA8nqTbLvu4RV
         7Kt+P/cxr+ze8q35YOs63sKUk1qSqJS1gkVV3jQYv59vHu984uaJlOFp6C8RheJSN5Mi
         Pf82XkddCXe/TATQA3XrV84BBDTO/KV1E1Wj18ggpUWuIVK/k1ObZb3TL9ka4bF52Nbc
         v8Yg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=mime-version:feedback-id:references:in-reply-to:message-id:subject
         :cc:from:to:date:dkim-signature;
        bh=CyPRGaCG2+DNqQI2wNwYGB3pn79n6nB+pjC+34ypE2U=;
        fh=yJAZLHmrwyEhV+hWI2VIrxfKqH9xSOPMbomqVVc56Lo=;
        b=my/mSbKzTgtXJwiUglg4BCCY3hqgHJMuQJoSCnzrH4AYMGJCAliz/mjrIvvmtkIxkL
         B2f3sw1f7drkQnBeYo9OoCvuYzDBrxcWYM25Dt/5YVM1TGomRU6/9HEy1t+2N0AJ88Tu
         x5d4Nh21EQwwVLoi3bY/BlayAVJeThUIkqN+Nw7JfeK71t7yglmgH+LygNBPyzCKLWj1
         pl55fMW3c2X+oCWEtB5h/gUg+diTfRSnObOjDjKZJH9F2u+hDQq0U76oILvPAI2qtgEY
         bmRfMz5ETE1pYp9bShvRYcZa10KMiknH0e9dYXfSpZOd7Cz24DEy+gxDe11JT2EewmTP
         9inQ==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@wuille.net header.s=protonmail3 header.b=rDGB8cSX;
       spf=pass (google.com: domain of bitcoin-dev@wuille.net designates 185.70.43.23 as permitted sender) smtp.mailfrom=bitcoin-dev@wuille.net;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=wuille.net
Received: from mail-4323.proton.ch (mail-4323.proton.ch. [185.70.43.23])
        by gmr-mx.google.com with ESMTPS id d26-20020aa7ce1a000000b0056e143a691csi4945edv.1.2024.04.03.12.44.09
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Wed, 03 Apr 2024 12:44:09 -0700 (PDT)
Received-SPF: pass (google.com: domain of bitcoin-dev@wuille.net designates 185.70.43.23 as permitted sender) client-ip=185.70.43.23;
Date: Wed, 03 Apr 2024 19:44:00 +0000
To: Tim Ruffing <crypto@timruffing.de>
From: Pieter Wuille <bitcoin-dev@wuille.net>
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?
Message-ID: <4pVUOTuyyAbTJB_rTGNWS_TuR39NS5OoJvaSCyqjezAg265kPnCjXvqohFmWQ5ITb7XFZCJie-uV1AG3pVCI5H54dDuFP4OyomC9yiWDot0=@wuille.net>
In-Reply-To: <59fa94cea6f70e02b1ce0da07ae230670730171c.camel@timruffing.de>
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> <59fa94cea6f70e02b1ce0da07ae230670730171c.camel@timruffing.de>
Feedback-ID: 19463299:user:proton
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="b1_2sH74SEKCQpL8NcK5rhkFajFW7ZvZXlzjmVI60YTtE"
X-Original-Sender: bitcoin-dev@wuille.net
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@wuille.net header.s=protonmail3 header.b=rDGB8cSX;       spf=pass
 (google.com: domain of bitcoin-dev@wuille.net designates 185.70.43.23 as
 permitted sender) smtp.mailfrom=bitcoin-dev@wuille.net;       dmarc=pass
 (p=NONE sp=NONE dis=NONE) header.from=wuille.net
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.7 (/)

This is a multi-part message in MIME format.

--b1_2sH74SEKCQpL8NcK5rhkFajFW7ZvZXlzjmVI60YTtE
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thank you for splitting off this discussion. I believe that lots of comment=
ators who see problems with the BIPs process fail to distinguish between th=
e editor being overloaded, and unclarity or disagreement about what the edi=
tor'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 t=
he process does involve a lot more than that. Discussion about what the pro=
cess 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 wr=
ote:

> 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, rece=
ived 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 soft=
ware 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/disagre=
ement 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 li=
mits (whether spelled out or not) will exist regardless (nobody would consi=
der including the HTTP spec in scope for a BIP, I think?). One suggestion I=
 have seen (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-Oc=
tober/022072.html) is limiting to "extremely widespread standards used by t=
he entire Bitcoin community", but I feel that suffers from a "no true Scots=
man" fallacy (who gets to define what the "Bitcoin community" is, in a tech=
nology that to me seems designed for distrusting parties?), but would also =
under reasonable interpretations exclude several very useful BIPs today (so=
me 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 tha=
t's a desirable situation.

I also don't think scope should be tied to specific technologies (e.g. it s=
houldn't just be about on-chain transactions, as e.g. that would exclude ad=
dress formats), but if not that, what scoping is useful? And to me, restric=
ting to technology that supports the bitcoin currency is fairly clear, reas=
onable, and avoids a circular definition. As an example, that would exclude=
 OpenTimestamps from scope (which was suggested in https://lists.linuxfound=
ation.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 stand=
ard is a good idea, or even whether it falls within the "Bitcoin philosophy=
", without disagreeing whether it is at all related to bitcoin (the currenc=
y).

> 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=E2=80=8B trying to gue=
ss 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 excl=
uding 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 ri=
d 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 re=
commendations. 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 auth=
or'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 us=
ed, and the BIP2 status fields don't seem to be doing much better. If we as=
sume 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 simplifie=
d 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 f=
ield 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 e=
xception? I feel that for those, an "Accepted" status may actually make sen=
se, because they actually require the ecosystem to have agreement about. Bu=
t even then, it could be restricted to be an after-the-fact piece of eviden=
ce (whatever its activation rules are, they are met), rather than a judgeme=
nt of community perception.

Regarding the "at least two independent and compatible software application=
s", I don't think this is a bad principle: good standards should be impleme=
ntable 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 condit=
ion 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 oug=
ht 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 ma=
ke.

--
Pieter

--=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/4pVUOTuyyAbTJB_rTGNWS_TuR39NS5OoJvaSCyqjezAg265kPnCjXvqohFmWQ5IT=
b7XFZCJie-uV1AG3pVCI5H54dDuFP4OyomC9yiWDot0%3D%40wuille.net.

--b1_2sH74SEKCQpL8NcK5rhkFajFW7ZvZXlzjmVI60YTtE
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div style=3D"font-family: Arial, sans-serif; font-size: 14px;"><p></p><div=
 style=3D"font-family: Arial, sans-serif; font-size: 14px;"><p>Thank you fo=
r splitting off this discussion. I believe that lots of=20
commentators who see problems with the BIPs process fail to distinguish=20
between the editor being overloaded, and unclarity or disagreement about
 what the editor's job is supposed to be in the first place.<br><br>
In particular, I've seen some comments akin to "assigning numbers=20
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=
=20
what the process is supposed to be should be separate from a discussion=20
about who will facilitate that process.<br><br>
More comments inline below.</p><blockquote><p></p></blockquote><br></div>
<div class=3D"protonmail_signature_block protonmail_signature_block-empty" =
style=3D"font-family: Arial, sans-serif; font-size: 14px;">
    <div class=3D"protonmail_signature_block-user protonmail_signature_bloc=
k-empty">
       =20
            </div>
   =20
            <div class=3D"protonmail_signature_block-proton protonmail_sign=
ature_block-empty">On Tuesday, April 2nd, 2024 at 9:17 AM, Tim Ruffing <a h=
ref=3D"mailto:crypto@timruffing.de">crypto@timruffing.de</a> wrote:</div></=
div><p></p>
<p></p><blockquote><p>
BIP2, Section "BIP workflow" says this:</p>
<p>"The BIP editors will not unreasonably reject a BIP. Reasons for<br>
rejecting BIPs include duplication of effort, disregard for formatting<br>
rules, being too unfocused or too broad, being technically unsound, not<br>
providing proper motivation or addressing backwards compatibility, or<br>
not in keeping with the Bitcoin philosophy. For a BIP to be accepted it<br>
must meet certain minimum criteria. It must be a clear and complete<br>
description of the proposed enhancement. The enhancement must represent<br>
a net improvement. The proposed implementation, if applicable, must be<br>
solid and must not complicate the protocol unduly."</p>
<p>This is a lot of criteria for a simple editorial rule, hm? How could<br>
any editor judge if an enhancement represents a net improvement without<br>
opining on its merit? What's the Bitcoin philosophy?</p>
</blockquote><p>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:</p><p></p><ul data-editing-info=3D"{&q=
uot;orderedStyleType&quot;:1,&quot;unorderedStyleType&quot;:1}"><li style=
=3D"list-style-type: disc;"><span>Formatting: contains necessary sections/h=
eaders, license, ...</span></li><li style=3D"list-style-type: disc;"><span>=
Editorial qualities: proper English, organized, ...<br></span></li><li styl=
e=3D"list-style-type: disc;"><span>Discussion: must have been presented on =
the ML or other common fora, received interest/discussion, ...</span></li><=
li style=3D"list-style-type: disc;"><span>Need for standardization: not eve=
ry idea is worth publishing; if it isn't likely to affect multiple projects=
/pieces of software, it can just be software documentation instead.</span><=
/li><li style=3D"list-style-type: disc;"><span>Scope: related to technology=
 that supports the bitcoin currency.</span></li></ul><div><br></div><div>Th=
is last one may be controversial, but I feel that some of the discussion th=
e past months about the process has shown that there is unclarity/disagreem=
ent here, and it would be good to have some guideline written out here. I t=
hink scope will inevitably be somewhat of a grey zone, but I feel some limi=
ts (whether spelled out or not) will exist regardless (nobody would conside=
r including the HTTP spec in scope for a BIP, I think?). One suggestion I h=
ave seen (<span><a target=3D"_blank" rel=3D"noreferrer nofollow noopener" h=
ref=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October=
/022072.html">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-=
October/022072.html</a>) is limiting to "extremely widespread standards use=
d by the entire Bitcoin community", but I feel that suffers from a "no true=
 Scotsman" </span>fallacy (who gets to define what the "Bitcoin community" =
is, in a technology that to me seems designed for distrusting parties?), bu=
t would also under reasonable interpretations exclude several very useful B=
IPs today (some wallet standards are useful for some software and not other=
s) and likely contribute to process friction (where do they move to?). I do=
n't think that's a desirable situation.<br></div><div><br></div><div>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 t=
o technology that supports the bitcoin currency is fairly clear, reasonable=
, and avoids a circular definition. As an example, that would exclude OpenT=
imestamps from scope (which was suggested in <span><a target=3D"_blank" rel=
=3D"noreferrer nofollow noopener" href=3D"https://lists.linuxfoundation.org=
/pipermail/bitcoin-dev/2023-October/022077.html">https://lists.linuxfoundat=
ion.org/pipermail/bitcoin-dev/2023-October/022077.html</a>). I see that as =
an unrelated application which happens to make use of the Bitcoin blockchai=
n, which on itself is one of the technologies that supports bitcoin - but i=
s an indirection too far to be in scope.<br></span></div><div><span><br></s=
pan></div><div><span>Note that however none of the criteria I list above ar=
e quality assessments; I think it is essential that BIP editors can accept =
BIPs they themselves find abhorrent. People can strongly disagree about whe=
ther a proposed standard is a good idea, or even whether it falls within th=
e "Bitcoin philosophy", without disagreeing whether it is at all related to=
 bitcoin (the currency).<br></span></div><p><br></p><blockquote><p>By the w=
ay, Section "BIP Editor Responsibilities &amp; Workflow" says this:</p>
<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<br=
>
must make technical sense, even if they don't seem likely to be<br>
accepted.<br>
- [...]"</p>
<p>Note how this is is (seemingly?) in conflict with the paragraph cited<br=
>
further above. What is "acceptance"? Acceptance by the editor, by the<br>
community (whoever that is), or by anyone else?</p>
</blockquote><p>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, <b>without</b>=
=E2=80=8B trying to guess whether the community is likely to accept the ide=
a. "sound and complete" is perhaps too vague as a criterion, but I'm in sup=
port of explicitly excluding guessing of acceptance.<br></p><p><br></p><blo=
ckquote><p>BIP2 has other problems (a lot of which date back to BIP1):<br><=
/p><p>
* It recommends licensing BIPs under BSD-2 or BSD-3, which are<br>
software licenses. It's not even clear if they're applicable to<br></p><p>
plain text. (The CC0 recommendation makes much more sense.)</p></blockquote=
><p>No strong opinion about this, but that sounds reasonable.</p><p><br></p=
><blockquote><p>
* The Comments-URI thing is outdated and everyone seems to ignore it.<br></=
p><p>
Comments-Summary is even weirder.</p></blockquote><p>Agreed. It's unused, a=
nd sometimes misinterpreted. I think we should get rid of it.</p><p><br></p=
><blockquote><p>
* "Informational BIPs do not necessarily represent a Bitcoin community<br>
consensus or recommendation". Aha, does this imply that Standards<br>
Track BIPs need to represent a Bitcoin community consensus or<br></p><p>
recommendation?</p></blockquote><p>Indeed. I don't think BIPs should be rep=
resenting community consensus or recommendations. But perhaps they can docu=
ment individual pieces of evidence of acceptance; see further?</p><p><br></=
p><blockquote><p>
* Ever tried to write pseudocode or LaTeX in mediawiki format? It's<br></p>=
<p>
more than annoying, believe me.</p></blockquote><p>I'd like permitting BIPs=
 to be written in markdown.</p><p><br></p><blockquote>
<p>Moreover, the entire "BIP status field" section is an attempt at<br>
formalizing and describing the process of changing Bitcoin. That leads<br>
to statements like these that specify when a BIP should be "Final"</p>
<p>* "A soft-fork BIP strictly requires a clear miner majority expressed<br=
>
by blockchain voting (eg, using BIP 9)." That statement is highly<br>
controversial. The point is that it simply doesn't belong in BIP2.<br>
* "API/RPC and application layer BIPs must be implemented by at least<br>
two independent and compatible software applications." same here<br>
* Peer services BIPs should be observed to be adopted by at least 1%<br></p=
><p>
of public listening nodes for one month.</p></blockquote><p><br></p><p>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 "Wit=
hdrawn" make sense to me for any kind of standard. In Draft stage more subs=
tantial changes could be permitted, but would convey the idea isn't yet int=
ended 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 nou=
ght, but perhaps it's still worth trying with a significantly simplified as=
sortment of statuses.<br></p><p>Things like "Active / Final" and "Rejected"=
 relate to community acceptance, and I agree those don't belong in BIPs. In=
stead, could we perhaps have a field that indicates objective evidence of a=
cceptance, such as listing which software projects have implemented/adopted=
 it?</p><p>As far as judging consensus goes, perhaps actual consensus chang=
es are an exception? I feel that for those, an "Accepted" status may actual=
ly make sense, because they actually require the ecosystem to have agreemen=
t about. But even then, it could be restricted to be an after-the-fact piec=
e of evidence (whatever its activation rules are, they are met), rather tha=
n a judgement of community perception.<br></p><p>Regarding the "at least tw=
o 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 su=
re 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 stan=
dardization" rule I suggest above.</p><p><br></p><blockquote>
<p>The problems are similar to the Comments-Summary field whose purpose is<=
br>
to represent a community judgment of the BIP. It can have these values:<br>
* No comments yet.<br>
* Unanimously Recommended for implementation<br>
* Unanimously Discourage for implementation<br>
* Mostly Recommended for implementation, with some Discouragement<br>
* Mostly Discouraged for implementation, with some Recommendation</p>
<p>There's a reason why noone really uses this. Like the Status field, it<b=
r>
requires that someone (the editor? BIP2 doesn't specify this) makes a<br>
judgement that looks somewhat authoritative, because it will end up in<br><=
/p><p>
the BIP header/metadata.</p></blockquote><p>Agreed.</p><p><br></p><blockquo=
te>
<p>I think we should simply drop anything that requires an examination of<b=
r>
the meat of the BIP, e.g., the Status and Comments-* fields, and the<br>
requirement to check the meat of a BIP. Instead, we should work on a<br>
new process BIP that merely describes a simple process of publishing<br>
BIPs, in which the editors focus on purely formal and editorial issues<br>
(e.g., formatting, license, readability, filtering spam, ...). It's<br>
great when they guide BIP authors by providing feedback on the<br>
presentation of an idea, or even on the idea itself, but they shouldn't<br>
be required to make decisions based on the technical or philosophical<br></=
p><p>
merit of a BIP</p></blockquote><p>I think my view is somewhat more restrict=
ive than yours, e.g. that BIPs ought to satisfy some scope and need for sta=
ndardization criteria, but I agree that as written in BIP2 today, Editors h=
ave too many judgement calls to make.</p><p></p><div>--</div><div>Pieter</d=
iv><div><br></div><p></p><p><br></p><div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/4pVUOTuyyAbTJB_rTGNWS_TuR39NS5OoJvaSCyqjezAg265kPnCjX=
vqohFmWQ5ITb7XFZCJie-uV1AG3pVCI5H54dDuFP4OyomC9yiWDot0%3D%40wuille.net?utm_=
medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitco=
indev/4pVUOTuyyAbTJB_rTGNWS_TuR39NS5OoJvaSCyqjezAg265kPnCjXvqohFmWQ5ITb7XFZ=
CJie-uV1AG3pVCI5H54dDuFP4OyomC9yiWDot0%3D%40wuille.net</a>.<br />

--b1_2sH74SEKCQpL8NcK5rhkFajFW7ZvZXlzjmVI60YTtE--