Re: [bitcoin-dev] BIP extensions

Re: [bitcoin-dev] BIP extensions

[Federico Berrone]

[-- 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 --]

[bitcoin-dev] BIP extensions

[Karl-Johan Alm]

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.)

Re: [bitcoin-dev] BIP extensions

[Karl-Johan Alm]

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

Re: [bitcoin-dev] BIP extensions

[Anthony Towns]

On Wed, Sep 15, 2021 at 03:14:31PM +0900, Karl-Johan Alm via bitcoin-dev wrote:
> BIPs are proposals.

> 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.

Thinking of BIPs that have reach "Final" status as a "standard" might
be reasonable, but I'd be pretty careful about even going that far,
let alone further.

But as you said, "BIPs are proposals". If your conclusion is somehow
that a BIP "is not merely a proposal", you're reached a contradiction,
which means you've made a logic error somewhere in between...

> 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.

> 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.

If you were proposing this just for BIPs that are marked final, then
sure, maybe, I guess -- though why mark them final if you still want
to add missing content or make further improvements? But if you want to
apply it as soon as a BIP number is assigned or text is merged into the
repo, I think that just means requesting number assignment gets delayed
until the end of the development process rather than near the beginning,
which doesn't sound particularly helpful.

That's essentially how the lightning BOLTs are set up -- you only get to
publish a BOLT after you've got support from multiple implementations
[0]; but that has meant they don't have published docs for the various
things individual teams have implemented, making interoperability harder
rather than easier. There's been talk about creating bLIPs [1] to remedy
this lack.

> BIP extensions are separate BIPs that extend on or an existing BIP.

So as an alternative, how about more clearly separating out draft BIPs
from those in Active/Final state? ie:

 * brand new BIP draft comes in from its authors/champions/whatever
 * number xxx gets assigned, it becomes "Draft BIP xxx"
 * authors modify it as they see fit
 * once the authors are happy with the text, they can move it
   to Final status, at which point it is no longer a draft and is
   just "BIP xxx", and doesn't get modified anymore
 * go to step 1

(I'm doubtful that it's very useful to have an "Active" state as distinct
from "Final"; that just gives the editors an excuse to play favourites
by deciding whose objections count and whose don't (or perhaps which
implementations count and which ones don't). It's currently only used for
BIPs about the BIP process, which makes it seem particularly pointless...)

> By making extensions to BIPs, rather than modifying them long after
> review, we are giving the community [...]

As described, I think you would be giving people an easy way to actively
obstruct the BIP process by making it harder to "improve the proposal"
and "add missing content", and encouraging contentiousness as a result.

For adding on to BIPs that have reached Final status, I think just
assigning completely new numbers is fine, as occurred with bech32 and
bech32m (BIPs 173 and 350).

Even beyond that, having BIP maintainers exercising judgement by trying
to reserve/assign "pretty" numbers (like "BIP 3" for the new BIP process)
seems like a mistake to me. If it were up to me, I'd make the setup be
something like:

 * new BIP? make a PR, putting the text into
   "drafts/bip-authorname-description.mediawiki" (with corresponding
   directory for images etc). Have the word "Draft" appear in the "BIP:
   xxx" header as well as in the Status: header.

 * if that passes CI and isn't incoherent, it gets merged

 * only after the draft is already merged is a BIP number assigned.
   the number is chosen by a script, and the BIP maintainers rename it
   to "drafts/bip-xxx.mediawiki" in a followup commit including internal
   links to bip-authorname-description/foo.png and add it to the README
   (automatically at the same time as the merge, ideally)

 * when a BIP becomes Final, it gets moved from drafts/ into
   the main directory [2], and to avoid breaking external links,
   drafts/bip-xxx.mediawiki is changed to just have a link to the
   main doc.

 * likewise when a BIP becomes rejected/deprecated/whatever, it's moved
   into historical/ and drafts/bip-xxx.mediawiki and bip-xxx.mediawiki
   are updated with a link to the new location

 * otherwise, don't allow any modifications to bips outside of
   drafts/, with the possible exception of adding additional info in
   Acknowledgements or See also section or similar, adding Superseded-By:
   links, and updating additional tables that are deliberately designed
   to be updated, eg bip-0009/assignments.mediawiki

It's better to remove incentives to introduce friction rather than
add more.

Cheers,
aj

[0] https://github.com/lightningnetwork/lightning-rfc/blob/master/CONTRIBUTING.md

[1] https://github.com/ryanthegentry/lightning-rfc/blob/blip-0001/blips/blip-0001.md

[2] Maybe moving the files between directories is too much, but I think
    having "drafts/" in the URL is likely to help ensure people referring
    to draft BIPs actually realise they're drafts, and thus subject to
    large changes, cf
    https://twitter.com/BobMcElrath/status/1281606259863629824

    Likewise, people probably might not want to implement/deploy BIPs
    marked "draft", which is a good reason for the authors to mark them
    final, which in turn might help ensure they're actually complete
    and finished before they're deployed, all of which seems like a
    good thing.