bip versioning #1675

pull RandyMcMillan wants to merge 2 commits into bitcoin:master from bitcoincore-dev:1999/864206/541012/758dfc9/9f58824-bip-0085-versioning changing 4 files +875 −363
  1. RandyMcMillan commented at 1:18 am on October 5, 2024: contributor
  2. bip-0085@v2
        * Add new maintainer (author unreachable)
        * Swap chain code and private key bytes in application 32' for consistentcy with BIP-32 (major change)
        * Correct derived entropy for application 128169' test vector (major change)
        * Clarify big endian serialization
        * Add the Portuguese language (9') to application 39'
        * Add dice application 89101'
        * Clarify Testnet support for XPRV application 32'
        * Minor grammar, format, clarity improvements
    caf4daaffa
  3. bip-0085.mediawiki:versioning
    We preserve the original bip-0085 proposal
    as bip-0085/bip-0085@v1.mediawiki and add the
    bip-0085/bip-0085@v2.mediawiki revision
    f9964aa325
  4. RandyMcMillan commented at 1:20 am on October 5, 2024: contributor

    A way to structure major changes to BIPs while preserving original commit content for easy reference.

    The bip-0085.mediawiki file includes commit hash and message, enabling developers to use a git show or git checkout to access the original commit.

    https://github.com/bitcoincore-dev/bips/blob/1999/864206/541012/758dfc9/9f58824-bip-0085-versioning/bip-0085.mediawiki

  5. jonatack commented at 2:10 pm on October 5, 2024: member

    This proposal would appear to require an update to the process. According to BIP 2: “It is highly recommended that a single BIP contain a single key proposal or new idea. The more focused the BIP, the more successful it tends to be. If in doubt, split your BIP into several well-focused ones.”

    BIP85 will also be updated to Final status, given its adoption.

  6. jonatack commented at 2:14 pm on October 5, 2024: member

    Therefore, if a separate version is truly needed alongside an existing one, it should probably be a separate BIP.

    For instance, BIP 78 (Payjoin) and future BIP 77 (Payjoin v2).

  7. RandyMcMillan commented at 4:57 pm on October 5, 2024: contributor

    With all that said…

    I think you are missing the point…

    How to handle and document a BIP that may have been originally implemented/deployed with a bug?

    Simply amending the BIP proposal and burying the original flawed implementation isn’t enough - at a minimum - a Change log that explicitly references the original flawed specification should be easily referenced.

    We also know forced pushes do happen!

    I repeat!

    We also know forced pushes do happen! Which could clobber the referenced original commit!

    So preserving the original proposal verbatim is critical.

    This is why a structure like this may be a way forward.

  8. RandyMcMillan renamed this:
    bip-0085 versioning
    bip versioning
    on Oct 5, 2024
  9. RandyMcMillan commented at 5:21 pm on October 5, 2024: contributor
    Note: We have plenty of bips that use external links to reference implementations that get clobbered or go stale for some other reason - this should be avoided.
  10. jonatack commented at 5:31 pm on October 5, 2024: member

    Yes, I’m in favor of changelogs, and the current process update proposal at https://github.com/murchandamus/bips/pull/2 adds them.

    We have plenty of bips that use external links to reference implementations that get clobbered or go stale

    Please don’t hesitate to open a pull to update or remove stale links.

  11. RandyMcMillan closed this on Oct 6, 2024


github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bips. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-12-06 22:10 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me