[bitcoin-dev] Wednesday’s second BIP process meeting

[bitcoin-dev] Wednesday’s second BIP process meeting

[Michael Folkson]

[-- Attachment #1: Type: text/plain, Size: 3461 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 6546 bytes --]

Re: [bitcoin-dev] Wednesday’s second BIP process meeting

[Prayank]

[-- Attachment #1: Type: text/plain, Size: 1780 bytes --]

Good morning Michael,

Thanks for sharing the summary about BIP process meeting. 

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

1.I want to avoid mentioning projects that are not decentralized however the thing you mentioned is a feature not a bug. Neither anyone needs "quality" certificates from anyone nor approval. People are free to propose anything as improvement for Bitcoin. What gets implemented is a different thing. Also BIP number doesn't make something legit, BIPs can have any names. Example: If I ever create draft a proposal to improve Bitcoin, it will be in my own repository and with a unique name.

2.I am surprised that few influential developers that wanted to improve BIP process earlier by making it more decentralized were not present in either meeting. Also no follow up here on mailing list. So decentralization was only required when you had some issues with Luke Dashjr? Few things are so obvious that even a newbie who starts researching about Bitcoin from today can observe such things.

I tried my best to ask more people to participate in the meeting by tweeting, requested Christopher to attend the meeting and share his thoughts. Thanks everyone who was part of this meeting.


-- 
Prayank

A3B1 E430 2298 178F

[-- Attachment #2: Type: text/html, Size: 2268 bytes --]