public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Karl-Johan Alm <karl@dglab.com>
To: Federico Berrone <me@federicociro.com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP extensions
Date: Wed, 15 Sep 2021 19:18:41 +0900	[thread overview]
Message-ID: <CALJw2w4v5weerSGBCj0v=QB=0uG7YmkOtEs_kXrPydoS-_hibw@mail.gmail.com> (raw)
In-Reply-To: <10670b5b-2c3f-61d0-c2e4-0d496d14f2cd@federicociro.com>

Hi Frederico,

Welcome to the bitcoin-dev list. :)

Michael Folkson is currently pushing for a revision to BIP 2, which is
discussed in the "BIP process meeting" thread here. You could help out
by participating in that process. There's a wiki page with ideas for
this in [1] and the current plan is to modify [2] or some other pull
request to reflect what everyone decides.

[1] https://github.com/bitcoin/bips/wiki/BIP-Process-wishlist
[2] https://github.com/bitcoin/bips/pull/1015

-Kalle.

On Wed, 15 Sept 2021 at 17:29, Federico Berrone via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


  reply	other threads:[~2021-09-15 10:28 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-15  6:14 [bitcoin-dev] BIP extensions Karl-Johan Alm
2021-09-15  5:47 ` Federico Berrone
2021-09-15 10:18   ` Karl-Johan Alm [this message]
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='CALJw2w4v5weerSGBCj0v=QB=0uG7YmkOtEs_kXrPydoS-_hibw@mail.gmail.com' \
    --to=karl@dglab.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=me@federicociro.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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