Re: [bitcoin-dev] BIP extensions

From: Federico Berrone <me@federicociro•com>
To: Karl-Johan Alm via bitcoin-dev
	<bitcoin-dev@lists•linuxfoundation.org>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP extensions
Date: Wed, 15 Sep 2021 07:47:57 +0200	[thread overview]
Message-ID: <10670b5b-2c3f-61d0-c2e4-0d496d14f2cd@federicociro.com> (raw)
In-Reply-To: <CALJw2w7f2JfskLQPwEBsKTqpJBo+qccP-y6oAX5EEzJ3vo0Grw@mail.gmail.com>

[-- Attachment #1.1.1: Type: text/plain, Size: 3107 bytes --]

Hi Karl-Johan,
I fully agree with your proposal. In order to de-clutter BIPs and make a 
more understandable proposal, we can add the additional information in a 
separate piece. Also, this would maintain the original proposal without 
any modifications, showing the original spirit of it.
Let me know how can I help you with your proposal.

Regards,
Federico Berrone.

P/D: This is my first participation in the bitcoin-dev list, sorry if I 
am breaking any rule, I would be glad to know if that is the case.

El 15/09/2021 a las 8:14, Karl-Johan Alm via bitcoin-dev escribió:
> 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.)
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3191 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]