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
_______________________________________________
bitcoin-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
