Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id F1137C0037 for ; Thu, 18 Jan 2024 15:50:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id BF1E383E96 for ; Thu, 18 Jan 2024 15:50:33 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org BF1E383E96 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyjdSh92r7-B for ; Thu, 18 Jan 2024 15:50:32 +0000 (UTC) X-Greylist: delayed 553 seconds by postgrey-1.37 at util1.osuosl.org; Thu, 18 Jan 2024 15:50:32 UTC DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org DA36083E46 Received: from smtpauth.rollernet.us (smtpauth.rollernet.us [208.79.240.5]) by smtp1.osuosl.org (Postfix) with ESMTPS id DA36083E46 for ; Thu, 18 Jan 2024 15:50:32 +0000 (UTC) Received: from smtpauth.rollernet.us (localhost [127.0.0.1]) by smtpauth.rollernet.us (Postfix) with ESMTP id 8A23B280085F; Thu, 18 Jan 2024 07:41:15 -0800 (PST) Received: from webmail.rollernet.us (webmail.rollernet.us [IPv6:2607:fe70:0:14::a]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by smtpauth.rollernet.us (Postfix) with ESMTPSA; Thu, 18 Jan 2024 07:41:14 -0800 (PST) MIME-Version: 1.0 Date: Thu, 18 Jan 2024 05:41:14 -1000 From: "David A. Harding" To: Anthony Towns , Bitcoin Protocol Discussion In-Reply-To: References: User-Agent: Roundcube Webmail/1.4.15 Message-ID: <6f3ce219d7df09c80e8063579555de06@dtrt.org> X-Sender: dave@dtrt.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rollernet-Abuse: Contact abuse@rollernet.us to report. Abuse policy: http://www.rollernet.us/policy X-Rollernet-Submit: Submit ID 37ed.65a9469a.b9460.0 Subject: Re: [bitcoin-dev] BIP process friction X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2024 15:50:34 -0000 On 2024-01-16 16:42, Anthony Towns via bitcoin-dev wrote: > I'm switching inquisition over to having a dedicated "IANA"-ish > thing that's independent of BIP process nonsense. It's at: > > * https://github.com/bitcoin-inquisition/binana > > If people want to use it for bitcoin-related proposals that don't have > anything to do with inquisition, that's fine Thank you for doing this! Question: is there a recommended way to produce a shorter identifier for inline use in reading material? For example, for proposal BIN-2024-0001-000, I'm thinking: - BIN24-1 (references whatever the current version of the proposal is) - BIN24-1.0 (references revision 0) I think that doesn't look too bad even if there are over 100 proposals a year, with some of them getting into over a hundred revisions: - BIN24-123 - BIN24-123.123 Rationale: - Using "BIN" for both full-length and shortened versions makes it explicit which document set we're talking about - Eliminating the first dash losslessly saves space and reduces visual clutter - Shortening a four-digit year to two digits works for the next 75 years. Adding more digits as necessary after that won't produce any ambiguity - Although I'd like to eliminate the second dash, and it wouldn't introduce any ambiguity in machine parsing for the next 175 years, I think it would lead to people interpreting numbers incorrectly. E.g., "BIN241" would be read "BIN two-hundred fourty-one" instead of a more desirable "BIN twenty-four dash one" - Eliminating prefix zeroes in the proposal and revision numbers losslessly saves space and reduces visual clutter - A decimal point between the proposal number and revision number creates less visual clutter than the third dash and still conveys the intended meaning - Overall, for the typical case I'd expect---BIN proposals numbered 1-99 with no mention of revision---this produces strings only one or two or characters longer than a typical modern BIP number in shortened format, e.g. BIN24-12 versus BIP123. Thoughts? -Dave