bip versioning #1675

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

    ---

Contributors
RandyMcMillan jonatack