From: "David A. Harding" <dave@dtrt•org>
To: Anthony Towns <aj@erisian•com.au>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP process friction
Date: Thu, 18 Jan 2024 05:41:14 -1000 [thread overview]
Message-ID: <6f3ce219d7df09c80e8063579555de06@dtrt.org> (raw)
In-Reply-To: <Zac+rMC/c+qTmSxY@erisian.com.au>
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
next prev parent reply other threads:[~2024-01-18 15:50 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-17 2:42 Anthony Towns
2024-01-17 6:55 ` Christopher Allen
2024-01-17 16:45 ` Luke Dashjr
2024-01-17 17:29 ` Michael Folkson
2024-01-18 18:00 ` Peter Todd
2024-01-19 19:27 ` Michael Folkson
2024-01-18 15:41 ` David A. Harding [this message]
2024-01-19 0:46 ` Anthony Towns
2024-01-19 2:33 ` Karl-Johan Alm
2024-01-18 16:47 ` alicexbt
2024-01-18 17:42 ` Peter Todd
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=6f3ce219d7df09c80e8063579555de06@dtrt.org \
--to=dave@dtrt$(echo .)org \
--cc=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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