Karl-Johan Alm [ARCHIVE] on Nostr: 📅 Original date posted:2021-09-15 📝 Original message:Hi Frederico, Welcome to ...
📅 Original date posted:2021-09-15
📝 Original message: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 at 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 at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
📝 Original message: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 at 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 at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev