From: Karl-Johan Alm <karl@dglab•com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] BIP extensions
Date: Wed, 15 Sep 2021 15:14:31 +0900 [thread overview]
Message-ID: <CALJw2w7f2JfskLQPwEBsKTqpJBo+qccP-y6oAX5EEzJ3vo0Grw@mail.gmail.com> (raw)
BIPs are proposals.
They begin as ideas, are formulated and discussed on this list, and
assuming no glaring flaws are observed, turned into pull requests to
the bips repository, assigned a BIP number by the editors, and merged.
It is then organically incorporated into the various entities that
exist in the Bitcoin space. At this point, it is not merely a
proposal, but a standard. As entities place their weight behind a BIP,
it makes less and less sense to consider its author the "maintainer"
of the BIP, with rights to modify it at their whim. Someone may have
agreed to the proposal in its original form, but they may disagree
with it if it is altered from under their feet.
BIPs are modified for primarily three reasons:
1. Because of spelling errors, or to otherwise improve on their
description without changing what is actually proposed.
2. To improve the proposal in some way, e.g. after discussion or after
getting feedback on the proposed approach.
3. To add missing content, such as activation strategy.
I propose that changes of the second and third type, unless they are
absolutely free from contention, are done as BIP extensions.
BIP extensions are separate BIPs that extend on or an existing BIP.
BIP extensions do not require the approval of the extended-upon BIP's
author, and are considered independent proposals entirely. A BIP that
extends on BIP XXX is referred to as BIP-XXX-Y, e.g. BIP-123-1, and
their introductory section must include the wording "
This BIP extends on (link: BIP-XXX).
".
By making extensions to BIPs, rather than modifying them long after
review, we are giving the community
1. the assurance that a BIP will mostly remain in its form forever,
except if an obvious win is discovered,
2. the ability to judge modifications to BIPs, such as activation
parameters, on their merits alone, and
3. the path to propose modifications to BIPs even if their authors
have gone inactive and cease to provide feedback, as is the case for
many BIPs today, as BIP extensions do not require the approval of the
extended-upon BIP.
(Apologies if this has been proposed already. If so, feel free to
ignore this message, and sorry to have wasted your time.)
next reply other threads:[~2021-09-15 6:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-15 6:14 Karl-Johan Alm [this message]
2021-09-15 5:47 ` Federico Berrone
2021-09-15 10:18 ` Karl-Johan Alm
2021-09-15 14:34 ` Anthony Towns
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=CALJw2w7f2JfskLQPwEBsKTqpJBo+qccP-y6oAX5EEzJ3vo0Grw@mail.gmail.com \
--to=karl@dglab$(echo .)com \
--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