From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 (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 From: Pieter Wuille Cc: Matt Corallo , Brandon Black , Murch , 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> <9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org> <42e6c1d1d39d811e2fe7c4c5ce6e09c705bd3dbb.camel@timruffing.de> <52a0d792-d99f-4360-ba34-0b12de183fef@murch.one> <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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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

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.

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.

More comments inline below.


=20
=20
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/h= eaders, license, ...
  • = Editorial qualities: proper English, organized, ...
  • Discussion: must have been presented on = the ML or other common fora, received interest/discussion, ...
    • <= li style=3D"list-style-type: disc;">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.<= /li>
  • Scope: related to technology= that supports the bitcoin currency.

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 (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-= October/022072.html) is limiting to "extremely widespread standards use= d 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?), 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.

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 https://lists.linuxfoundat= ion.org/pipermail/bitcoin-dev/2023-October/022077.html). 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.

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).


By the w= ay, 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 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.


BIP2 has other problems (a lot of which date back to BIP1):
<= /p>

* 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, a= nd 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 rep= resenting community consensus or recommendations. But perhaps they can docu= ment 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 "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.

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?

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.

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.


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:
* 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
<= /p>

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 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.

--
Pieter



--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitco= indev/4pVUOTuyyAbTJB_rTGNWS_TuR39NS5OoJvaSCyqjezAg265kPnCjXvqohFmWQ5ITb7XFZ= CJie-uV1AG3pVCI5H54dDuFP4OyomC9yiWDot0%3D%40wuille.net.
--b1_2sH74SEKCQpL8NcK5rhkFajFW7ZvZXlzjmVI60YTtE--