From: Michael Folkson <michaelfolkson@protonmail•com>
To: "bitcoin-dev@lists•linuxfoundation.org"
<bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] Wednesday’s second BIP process meeting
Date: Sun, 03 Oct 2021 18:22:12 +0000 [thread overview]
Message-ID: <R0G3u0C82WnrfMMhzmcHsSC1h4HpX_dYVxpkmO4Optg4q5BYxoEpuzXc0BwmohnarqWuRnQDYUbCRPpHc3gOnUzcAqyE9M3YtBoj1BKR-sI=@protonmail.com> (raw)
[-- 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 --]
next reply other threads:[~2021-10-03 18:22 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-03 18:22 Michael Folkson [this message]
2021-10-06 4:02 Prayank
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='R0G3u0C82WnrfMMhzmcHsSC1h4HpX_dYVxpkmO4Optg4q5BYxoEpuzXc0BwmohnarqWuRnQDYUbCRPpHc3gOnUzcAqyE9M3YtBoj1BKR-sI=@protonmail.com' \
--to=michaelfolkson@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox