MIME-Version: 1.0
Date: Thu, 18 Jan 2024 05:41:14 -1000
From: "David A. Harding" <dave@dtrt.org>
To: Anthony Towns <aj@erisian.com.au>, Bitcoin Protocol Discussion
 <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <Zac+rMC/c+qTmSxY@erisian.com.au>
References: <Zac+rMC/c+qTmSxY@erisian.com.au>
User-Agent: Roundcube Webmail/1.4.15
Message-ID: <6f3ce219d7df09c80e8063579555de06@dtrt.org>
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [bitcoin-dev] BIP process friction
Precedence: list

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