Wednesday’s second BIP process meeting was announced previously here [0].
A conversation log of the meeting is available here [1].
A summary of the first BIP process meeting is here [2].
The following is a summary of what was discussed.
1) The limits or possible downsides of pursuing maximal decentralization. Understandably there is a desire for greater decentralization as a central repo introduces bottlenecks and the need for maintainers or editors in the case of BIPs (prayank). However, zero filters creates a Ethereum style bewildering number of BIPs of varying quality that all need to be stored and maintained. The option of being able to store a BIP in any repo doesn’t appear to offer material upside (michaelfolkson). It still needs to get a BIP number from the BIP editors and if the alternative repo is deleted or the BIP champion becomes unresponsive there is the problem of changing the location of where the BIP is stored. It is much easier to monitor a single repo rather than an infinite number of repos that contain BIPs.
2) Past motivations for introducing alternative parallel processes to the BIPs (e.g. BOLTs, SLIPs). Anyone is free to set up a repo, add documentation to that repo or even set up a parallel process to the BIPs. However, if as a community we’d like to prevent unnecessary splintering it is good to understand why certain documents that should be BIPed aren’t being BIPed. Obviously not every document needs or should be BIPed. There are many docs that aren’t BIPs that are hugely valuable. One historical concern that was raised (ChristopherA) was regarding why BIP 48 didn’t happen and whether it was because it was coming from the wallet community and not a Bitcoin Core proposal. luke-jr said after the meeting that from recollection the reason it didn’t happen was merely that it was never written [3]. It was also discussed afterwards whether there was/is a rationale for Lightning BOLTs not being BIPs and whether they should be BIPs in future.
3) Kalle Alm’s proposal for BIP extensions [4] was discussed. Participants seemed to be in favor of the proposal though further clarity on when they would and wouldn’t be used was requested. A BIP extension for the bech32m update (BIP 350) to bech32 (BIP 173) seems like it would have been a good use case though further discussion is probably needed on whether they should be used for soft fork activation parameters. It was suggested that using dates and/or short extension names would be superior to extension numbers as numbers suggest an ordering (ChristopherA). The extension 2 may also be perceived as somehow replacing extension 1.
Thanks to the participants of both BIP process meetings. Further discussion is welcome on the #bitcoin-dev Libera IRC channel and hopefully we will see progress in the coming weeks and months on a proposed BIP 3 [5] update.
[0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019412.html
[1]: https://gist.github.com/michaelfolkson/84000ee3fe45c034ac12a7a54ff5fcdd
[2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019469.html
[3]: https://github.com/bitcoin/bips/pull/253
[4]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019457.html
[5]: https://github.com/bitcoin/bips/pull/1015
--
Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3